>From my perspective (outsider with an investment in Koha success overall)... it sounds like an RFC Wrangler is just what is needed. To build on Nicolas' 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 developed, known to all, and is followed.<div>
<br></div><div>People need to know where to submit requests, how to write useful RFCs and how to submit them. Then 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 work, more comment, minor adjustments, etc.</div>
<div><div><br></div><div>That seems like it resolves the workflow issue, keeps the developers in control, and doesn't add unwanted bureaucracy into the mix.</div><div><br></div><div> Lori<br><br><div class="gmail_quote">
On Tue, Nov 9, 2010 at 8:45 AM, Paul Poulain <span dir="ltr"><<a href="mailto:paul.poulain@biblibre.com">paul.poulain@biblibre.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="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 that<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 Koha<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 to<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<br>
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 your<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,<br>
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<br>
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<br>
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, could 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<br>
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's<br>
the correct term but <a href="http://en.wikipedia.org/wiki/Finite-state_machine" target="_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="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 want to<br>
have a *working* workflow . Maybe a subset could be more efficient with<br>
authority. Maybe a subset reporting to "community" could be better.<br>
Maybe the community can decide everything (but : who is member of "the<br>
community" ?).<br>
<div class="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). The volunteers for this would maintain the RFC list,<br>
> and assign states to things ("needs more info","for discussion","in<br>
> progress","in code","fully incorporated" for example). The community can<br>
> then use that state list to drive the overall agenda. This would make<br>
> sure nothing gets ignored or forgotten. This should have a Senior and<br>
> Junior Wrangler identified, who would help keep things focused - but<br>
> 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="im">> It might be worth trying to get a new volunteer/victim 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 much<br>
> sooner - without stressing out the "sitting" release manager. Call it the<br>
> "prospective release manager" job, maybe? That way you get 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 to<br>
plan the long-term evolutions of Koha !<br>
<font color="#888888"><br>
--<br>
Paul POULAIN<br>
<a href="http://www.biblibre.com" target="_blank">http://www.biblibre.com</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="h5"><br>
_______________________________________________<br>
Koha mailing list <a href="http://koha-community.org" target="_blank">http://koha-community.org</a><br>
<a href="mailto:Koha@lists.katipo.co.nz">Koha@lists.katipo.co.nz</a><br>
<a href="http://lists.katipo.co.nz/mailman/listinfo/koha" target="_blank">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
</div></div></blockquote></div><br></div></div>