[Koha] Proposal to form Koha Technical Committee

[Paul Poulain]

Le 09/11/2010 22:01, Chris Nighswonger a écrit :
> On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL at critfc.org> wrote:
>   
>> When the Release Manager is chosen and accepts the position, they
understand what they are taking on, don't they?
>>     
> Just to clarify: It is *not* the responsibility of the RM to vet RFCs
> and pursue the critique, correction, and/or amending of them. The RM
> simply wields the final say over what is finally actually pushed.
>   
I fully agree with you. And that's why i'm proposing to have another
structure/team/guy/whatever to work on strategic/long-term things.

To answer MJ question related to that question : I fully agree solR
won't probably be included in 3.4 (not ready enough,...) But do we want
it for 3.6 ?
(to answer your comment : yes we have a contract, but i'm ready, if "the
community" argue & decide it's a wrong idea, to reach the library and
explain the problem. And find a solution) But atm, I have no clear
decision taken, just a global feeling that "ppl think it's a good idea
if we succeed to address the z3950 server problem". Do you think I
should consider this as enough and go my way? I don't think so, because
the customer want his sponsored work to be in official Koha.

Does it mean I just should shut my mouth, candidate to be the RM for 
3.6, and do what I want here in term of strategic decision ? Well, if
ppl think it's how I should do, then I'll do. But that's not how I want
to do it : community matter

> Clearly the RM should:
>
> 1. Be knowledgeable of RFCs which are proposed for the current version.
>   
++
> 2. Lead by example in the matter of participation in the RFC process.
>   
++
> However, to suggest that the RM bares the responsibility for doing the
> leg-work in the RFC process will probably reduce the future candidate
> pool of RM's due to fear of being worked to death.

++

AND (as I already wrote), the RM deals with the next version, and
sometimes things will be for the next-next version. Or the
next-next-next. Or some things are related to long-term so must be
addressed separately (ie : not just in a given version)

> It is, in fact, the responsibility of the author of the RFC (or the
> author's employer) to promote that RFC and keep it before the
> community.
>
> And it is the responsibility of the *community* to vet, critique,
> correct, and/or amend RFCs.
>
> Historically there have been failures on both parts. Things are
> looking up, however.
>

Agreed. (I'm not trying to say I did everything well. But I try to learn
from my mistakes, and I just want Koha to be always more and more
reliable & sustainable & predictible)

>> And if dates slip, well, gee, won't we be getting a better release
due to the extra work?
>>
> Again looking at history, the type of slippage traditionally seen is
> terrible for users, vendors, and clients of vendors. You cannot plan
> around an ever-moving date.
++ and i'm 10000% happy with the time-based release for 3.4 & for
futures versions hopefully.

And, once again, I feel very uncomfortable when chris says : "it's the
decision for 3.4, the 3.6RM will decide how he want to deal with it".
I strongly disagree : it should a community "stable" decision a RM can't
change just because he want to change it. That's a question of being
sustainable & predictible (for both vendors and users)

> People who might be considered crazy (like
> me) and run the cutting edge code probably don't care. But not
> everyone can afford those risks. This is a problem which can be and is
> being addressed.
>   
agreed
>> Again, I think we are slipping into the commercial vendor mode where
more voices are being added for no purpose other than to make noise.
>>     
> I agree with this.
>   
Not sure I understand well what's meaning here. (The fact is that many
new features are developed by sponsored work and commercial vendors, so
we have to deal with that ! )
>> I think adding a SINGLE person to the release team of RFC manager to
make comments and organize RFC's might help the RM, but that's up to the
Release Manager to choose someone they can work with.
>>     
> Really about the best we can get without *active* * community*
> participation is an RFC cheerleader. I'm not sure what there is here
> to manage.
>
> The process/workflow is simple:
>
> 1. Post your RFC on *both* the wiki and both lists.
> 2. Bump the post to the lists if you (as the author) feel that there
> is not enough vetting, etc. going on.
> 3. If you (as the author) are actively promoting your RFC and it is
> not getting enough discussion, feel free to complain loudly;
> otherwise, don't complain.
>   

Well, that's what I do : I complain loudly ;-)

> I think the idea suggested in another thread of having a section of
> the monthly news letter to highlight RFCs is a great idea. Perhaps it
> could especially highlight those with fewer comments/discussion/etc.
>   
++ I think it's a great idea too !

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