[Koha] Proposal to form Koha Technical Committee

[david at lang.hm]

the problem is that you are asking for a binding decision. open source 
software projects really don't work that way.

if it's useful to a library (or if a library thingks it would be useful), 
there's probably very little that would be rejected based on the 
description (what would show up in an RFC)

when it comes to the implementation, it's primarily a matter of taste, and 
there you have a lot of people who can object to the implementation, and 
they can object at any point up to (or even shortly after) the point where 
it is merged.

the RM makes the final decision on if the code is clean enough for the 
RMto be comfortable shipping it.

you may be targeting a feature at 3.6, but there is no way that you can 
get assurance that it will be accepted into 3.6 this early in the process. 
depending on how the code works, how it's written, and how comfortable the 
RM is that it will work and be supported, it may get into 3.6, or the 3.6 
RM may decide not to accept it at which point you should then try to 
either convince the 3.6 maintainier that he's wrong, or wait for 3.8 and 
try to convince that RM.

I know this is not what you are wanting to hear, but this is one of the 
differences with open source projects, there is not the same commitment to 
prior decisions that you see in closed source projects.

This is especially true when doing time-based releases. If a feature is 
'ready' it will be included, if it's not 'ready' it won't be. 'ready' can 
include a lot more than just 'does the code work', it can include style, 
taste of the implementation, documentation, support concerns (if you are 
submitting something that nobody else thinks is very useful, but the 
community has concerns that you may just drop off the code and disappear 
leaving them to maintain the code the community will be less willing to 
accept the code)


as you develop the feature, maintain communication. as you make design 
decisions let people know about it. as soon as you have something that 
works (however imperfectly and unpolished) publish what you have so people 
can look at it.

there is no point past which you can rule out major redesign requsts. It 
may be that after you have things working someone will notice similarities 
with other code and ask you re refactor things to better share code.

on the other hand, just because someone asks you to make a change doesn't 
mean that you must make that change, even if it's the RM. as the person 
writing the code you have a fair amount of power. you can argue back on 
why you don't want to do so. don't overuse this power, if things get 
heated it's playing a game of chicken with the community, but if the 
request is something that's really a problem for you, push back. If it's a 
matter of not having time in this release, you may be able to negotiate 
'accept this as-is and I willre-write the functionality as you ask and 
have it ready for the next release', this sort of thing requires that you 
have built a reputation with the community so that they can trust you, and 
that the changes that are needed are mostly (if not completely) 
transparent to the users.

in the case of alternate search capibilities, the initial implemenation 
may be a either/or approach where you completely replace the existing 
search. a second cut of the implementation may re-write the search 
interface to be more general and less tuned for either specific search 
option. a third cut of the implementation may refactor both search 
implementations to share a lot of their code and only differ in the 
routines that call the search engine. a fourth cut of the implementation 
may include expanding this to support some additional search options to 
demonstrate that the search interface is now generic enough to be useful 
going forward.

David Lang


On Wed, 10 Nov 2010, Paul Poulain wrote:

> 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 !
>
>