No subject
Wed Nov 11 03:01:06 NZDT 2009
. it sounds like an RFC Wrangler is just what is needed. To build on Nicola=
s' idea.... I see that person (or persons) as someone who wouldn't =
have an investment in any particular development path or particular feature=
but have the limited role of ensuring that an agreed-upon workflow develop=
ed, known to all, and is followed.<div>
<br></div><div>People need to know where to submit requests, how to write u=
seful RFCs and how to submit them. =A0Then when they are properly submitted=
, the RFC Wrangler ensures they are properly vetted by developers and sent =
back to the community or users and/or people who wrote the RFC for more wor=
k, more comment, minor adjustments, etc.</div>
<div><div><br></div><div>That seems like it resolves the workflow issue, ke=
eps the developers in control, and doesn't add unwanted bureaucracy int=
o the mix.</div><div><br></div><div>=A0Lori<br><br><div class=3D"gmail_quot=
e">
On Tue, Nov 9, 2010 at 8:45 AM, Paul Poulain <span dir=3D"ltr"><<a href=
=3D"mailto:paul.poulain at biblibre.com">paul.poulain at biblibre.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">
disclaimer : english is not my mother-language. Apologize for any<br>
frenchism, and, please, don't be offended by any term/word/sentence tha=
t<br>
may look aggressive: It's a mistake.<br>
<br>
Hello world,<br>
<br>
I'll try to answer everyone question/comments in this mail.<br>
<br>
* about the timing and the discussion : I made this discussion happend.<br>
I started to speak of our problems/questions/doubts/fears/needs/feelings<br=
>
on koha-devel mailing lists months ago (see "BibLibre strategy for Koh=
a<br>
3.4 and next version" thread, june, 2nd), tried many times to start<br=
>
(maybe I missed to be clear enough), and was really thinking that<br>
kohacon was THE place to speak of this, because we all would be here.<br>
Frankly, that's the only reason why hdl came (well, he was also happy t=
o<br>
meet ppl, but we are overwhelmed by stuff, so...) Chris was thinking<br>
that we already had too much discussions during the 1st part of the<br>
kohacon, and wanted to help newbies. He organised the conference, so I<br>
let him choose, hoping he would understand how important it was to me.<br>
At the end, he understood and on sunday morning aknowledged to speak of<br>
this. No shadow or hidden or anything bad (frankly speaking MJ, your<br>
suspiciousness is really <<don't know which word to say here. Don=
't want<br>
to offend, but let me just say it's hard to feel like guilty of<br>
something bad>>)<br>
* about the content of the discussion : what I/BibLibre want(ed) to<br>
point was that WE (the community) HAVE A PROBLEM. Believe me or not, but<br=
>
we have one, and we must deal with it !<br>
<br>
Let me explain what I think by taking some examples:<br>
* on oct, 2009, Nicolas Morin wrote a mail about Lyon3 sponsored new<br>
features on circulation & announcing RFCs. NO-ONE, answered this mail.<=
br>
NO-ONE argued. We had/have a contract. So we did the job. That's a<br>
problem : all our customers are now live with those features. But we<br>
don't know if they will be accepted in the main trunk, because no-one<b=
r>
said "ok, let's do it, from a strategic/feature/technical point of=
view,<br>
it's where the Koha project want to go".<br>
* last month, we sent a mail about moving to solR. Another sponsored<br>
work (thanks St Etienne). Some have answered. BUT : no decision has been<br=
>
taken. I don't mean here saying "ok, BibLibre, we will integrate y=
our<br>
work without looking at how you did it", but no-one has said "OK,=
<br>
BibLibre, it's where the project want to go, your arguments are fine,<b=
r>
there is only one problem with z3950 server that seems to be solvable.<br>
If it is solved, this streategic decision is taken". We have to go<br>
ahead, and now, if it's not accepted by the community, our only option<=
br>
will be to fork !<br>
* Last week, I wrote many mails on koha-devel to announce all our<br>
underway RFCs. Maybe you can argue there's something wrong with what I<=
br>
wrote. The problem is that, once again, no-one has said anything ! So,<br>
what must we do next ?<br>
* Savitra Sirohi wrote detailled RFCs in september. And they look<br>
awesome from a functionnal point of view. hdl asked for some schedules,<br>
got an answer, but I feel it's not enough. We (community) should work<b=
r>
more closely with him to know sooner if/how the coding is going.<br>
<br>
As other companies, we have contracts we must fulfill. But : if "the<b=
r>
community" think RFC-X is a wrong idea, then I'm ready to go back =
to the<br>
customer and say : "well, the community argues it's a bad idea, co=
uld we<br>
find a solution that would fit everyone needs" ? In fact, i'm sure=
the<br>
sponsoring library will accept and we will find a solution (mostly<br>
because 1-I trust the community as "wise". So i think/am sure the=
<br>
community won't reject something unless it's a bad idea and 2-our<b=
r>
sponsoring libraries understand what is Free Software and won't want to=
<br>
fork!)<br>
<br>
SO: we (BibLibre) don't want a "technical commitee", what we =
want is to<br>
have a working workflow to manage how things evolve/are improved/...<br>
Our workflow works quite well ... if it goes to the end. But nothing<br>
prevents us from having something falling in a black hole (frenchism<br>
suspected). And we (BibLibre) can't accept/deal with that. Not sure it&=
#39;s<br>
the correct term but <a href=3D"http://en.wikipedia.org/wiki/Finite-state_m=
achine" target=3D"_blank">http://en.wikipedia.org/wiki/Finite-state_machine=
</a><br>
is maybe what I want to express : in our workflow, we can sometimes have<br=
>
no result to a given starting action.<br>
Something like a technical commitee may fit the need. It may be<br>
something else. It's just that today, the situation is not sustainable =
!<br>
<br>
Our (community) two problems may be summarised by :<br>
* short term problem : our workflow to deal with proposed<br>
contributions/features<br>
* long term problem : the strategic/major orientations of the project<br>
<br>
Chris C.: see my comment below (to nicholas rosasco)<br>
<br>
David Lang : I hope that you realise the previous lines are the answers<br>
to your answer: announcing is not enough: we did it, and it hasn't<br>
worked. And more than one time.<br>
<br>
Nicolas : I really LOVE your mail ! thanks to jump in the discussion:<br>
<div class=3D"im">> How about a halfway step between vesting a subset of=
the community with<br>
> authority or continuing to try to run everything through a whole<br>
> group....?<br>
</div>Maybe. I don't *want* to have a subset with authority. I just wan=
t to<br>
have a *working* workflow . Maybe a subset could be more efficient with<br>
authority. Maybe a subset reporting to "community" could be bette=
r.<br>
Maybe the community can decide everything (but : who is member of "the=
<br>
community" ?).<br>
<div class=3D"im">> an RFC Wrangling Committee, which would meet minimum=
once a month (just<br>
> to check in) and/or within some set time period of new RFCs coming it =
(as<br>
> in triggered by). =A0The volunteers for this would maintain the RFC li=
st,<br>
> and assign states to things ("needs more info","for dis=
cussion","in<br>
> progress","in code","fully incorporated" for =
example). =A0The community can<br>
> then use that state list to drive the overall agenda. =A0This would ma=
ke<br>
> sure nothing gets ignored or forgotten. =A0This should have a Senior a=
nd<br>
> Junior Wrangler identified, who would help keep things focused - but<b=
r>
> would preserve broader community say in things<br>
><br>
</div>Sounds like a great idea ! (and I immediatly volunteer to be a member=
of<br>
this RFC wrangling committee !)<br>
<div class=3D"im">> It might be worth trying to get a new volunteer/vict=
im to be the next<br>
> release manager very much in advance of the release date... that way, =
the<br>
> general/scheduling discussion can get settled for the next release muc=
h<br>
> sooner - without stressing out the "sitting" release manager=
. =A0Call it the<br>
> "prospective release manager" job, maybe? =A0That way you ge=
t someone who'll<br>
> be thinking about the long term but who'll have to live with that =
long<br>
> term in the deliverable sense.<br>
><br>
</div>Not sure we need the Koha3.6 RM known today. But definetly, we need t=
o<br>
plan the long-term evolutions of Koha !<br>
<font color=3D"#888888"><br>
--<br>
Paul POULAIN<br>
<a href=3D"http://www.biblibre.com" target=3D"_blank">http://www.biblibre.c=
om</a><br>
Expert en Logiciels Libres pour l'info-doc<br>
Tel : (33) 4 91 81 35 08<br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
Koha mailing list =A0<a href=3D"http://koha-community.org" target=3D"_blank=
">http://koha-community.org</a><br>
<a href=3D"mailto:Koha at lists.katipo.co.nz">Koha at lists.katipo.co.nz</a><br>
<a href=3D"http://lists.katipo.co.nz/mailman/listinfo/koha" target=3D"_blan=
k">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
</div></div></blockquote></div><br></div></div>
--00163646dc3c5a51930494a1fa6d--
More information about the Koha
mailing list