[Koha] Proposal to form Koha Technical Committee

[Paul Poulain]

disclaimer : english is not my mother-language. Apologize for any
frenchism, and, please, don't be offended by any term/word/sentence that
may look aggressive: It's a mistake.

Hello world,

I'll try to answer everyone question/comments in this mail.

* about the timing and the discussion : I made this discussion happend.
I started to speak of our problems/questions/doubts/fears/needs/feelings
on koha-devel mailing lists months ago (see "BibLibre strategy for Koha
3.4 and next version" thread, june, 2nd), tried many times to start
(maybe I missed to be clear enough), and was really thinking that
kohacon was THE place to speak of this, because we all would be here.
Frankly, that's the only reason why hdl came (well, he was also happy to
meet ppl, but we are overwhelmed by stuff, so...) Chris was thinking
that we already had too much discussions during the 1st part of the
kohacon, and wanted to help newbies. He organised the conference, so I
let him choose, hoping he would understand how important it was to me.
At the end, he understood and on sunday morning aknowledged to speak of
this. No shadow or hidden or anything bad (frankly speaking MJ, your
suspiciousness is really <<don't know which word to say here. Don't want
to offend, but let me just say it's hard to feel like guilty of
something bad>>)
* about the content of the discussion : what I/BibLibre want(ed) to
point was that WE (the community) HAVE A PROBLEM. Believe me or not, but
we have one, and we must deal with it !

Let me explain what I think by taking some examples:
* on oct, 2009, Nicolas Morin wrote a mail about Lyon3 sponsored new
features on circulation & announcing RFCs. NO-ONE, answered this mail.
NO-ONE argued. We had/have a contract. So we did the job. That's a
problem : all our customers are now live with those features. But we
don't know if they will be accepted in the main trunk, because no-one
said "ok, let's do it, from a strategic/feature/technical point of view,
it's where the Koha project want to go".
* last month, we sent a mail about moving to solR. Another sponsored
work (thanks St Etienne). Some have answered. BUT : no decision has been
taken. I don't mean here saying "ok, BibLibre, we will integrate your
work without looking at how you did it", but no-one has said "OK,
BibLibre, it's where the project want to go, your arguments are fine,
there is only one problem with z3950 server that seems to be solvable.
If it is solved, this streategic decision is taken". We have to go
ahead, and now, if it's not accepted by the community, our only option
will be to fork !
* Last week, I wrote many mails on koha-devel to announce all our
underway RFCs. Maybe you can argue there's something wrong with what I
wrote. The problem is that, once again, no-one has said anything ! So,
what must we do next ?
* Savitra Sirohi wrote detailled RFCs in september. And they look
awesome from a functionnal point of view. hdl asked for some schedules,
got an answer, but I feel it's not enough. We (community) should work
more closely with him to know sooner if/how the coding is going.

As other companies, we have contracts we must fulfill. But : if "the
community" think RFC-X is a wrong idea, then I'm ready to go back to the
customer and say : "well, the community argues it's a bad idea, could we
find a solution that would fit everyone needs" ? In fact, i'm sure the
sponsoring library will accept and we will find a solution (mostly
because 1-I trust the community as "wise". So i think/am sure the
community won't reject something unless it's a bad idea and 2-our
sponsoring libraries understand what is Free Software and won't want to
fork!)

SO: we (BibLibre) don't want a "technical commitee", what we want is to
have a working workflow to manage how things evolve/are improved/...
Our workflow works quite well ... if it goes to the end. But nothing
prevents us from having something falling in a black hole (frenchism
suspected). And we (BibLibre) can't accept/deal with that. Not sure it's
the correct term but http://en.wikipedia.org/wiki/Finite-state_machine
is maybe what I want to express : in our workflow, we can sometimes have
no result to a given starting action.
Something like a technical commitee may fit the need. It may be
something else. It's just that today, the situation is not sustainable !

Our (community) two problems may be summarised by :
* short term problem : our workflow to deal with proposed
contributions/features
* long term problem : the strategic/major orientations of the project

Chris C.: see my comment below (to nicholas rosasco)

David Lang : I hope that you realise the previous lines are the answers
to your answer: announcing is not enough: we did it, and it hasn't
worked. And more than one time.

Nicolas : I really LOVE your mail ! thanks to jump in the discussion:
> How about a halfway step between vesting a subset of the community with
> authority or continuing to try to run everything through a whole
> group....?
Maybe. I don't *want* to have a subset with authority. I just want to
have a *working* workflow . Maybe a subset could be more efficient with
authority. Maybe a subset reporting to "community" could be better.
Maybe the community can decide everything (but : who is member of "the
community" ?).
> an RFC Wrangling Committee, which would meet minimum once a month (just
> to check in) and/or within some set time period of new RFCs coming it (as
> in triggered by).  The volunteers for this would maintain the RFC list,
> and assign states to things ("needs more info","for discussion","in
> progress","in code","fully incorporated" for example).  The community can
> then use that state list to drive the overall agenda.  This would make
> sure nothing gets ignored or forgotten.  This should have a Senior and
> Junior Wrangler identified, who would help keep things focused - but
> would preserve broader community say in things
>   
Sounds like a great idea ! (and I immediatly volunteer to be a member of
this RFC wrangling committee !)
> It might be worth trying to get a new volunteer/victim to be the next
> release manager very much in advance of the release date... that way, the
> general/scheduling discussion can get settled for the next release much
> sooner - without stressing out the "sitting" release manager.  Call it the
> "prospective release manager" job, maybe?  That way you get someone who'll
> be thinking about the long term but who'll have to live with that long
> term in the deliverable sense.
>   
Not sure we need the Koha3.6 RM known today. But definetly, we need to
plan the long-term evolutions of Koha !

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08