[Koha-devel] A Discussion on A Policy Setting Forth Standards of Code Submission, etc. [WAS: RFCs for 3.4 from BibLibre (serials & acquisitions)]

[Paul Poulain]

Le 02/11/2010 16:24, Chris Nighswonger a écrit :
> As a vendor-neutral voice, I would like to encourage everyone who has
> an vested interest in these areas and the best interests of the Koha
> project at heart to actively participate and respond to these RFC's.
> It seems that often there is little dicussion, etc. on RFCs in the
> community. And even when there is discussion, etc. it is often unclear
> if a consensus is reached (at least publicly).
++, ++, and more ++ !
That has been one of the main topic we spoke during the last morning of
the hackfest (the other one being long term management of the project)
Irma & Bob have taken notes, and should sent the minutes here soon.
This meeting was, I hope, the start of a better management of our project.
> Furthermore, I would encourage vendors and others who post RFC's to do
> so with a willingness to adapt, adjust, bend, compromise, and/or
> <your-favorite-term-goes-here> to positions on those RFC's which may
> be different but are clearly the consensus of the community at large.
> Vendors may and often do have the resources to implement "what they
> want," however, this is not in the spirit of cooperation which this
> project so greatly depends upon for its success. Clients of vendors
> should be educated during the RFQ process as to this aspect of open
> source, and their expectations managed accordingly, imho.
I must add that (at least for BibLibre), our customers want to be a part
of an OpenSource community. So if one of our customer ask for something
that is amended (or even rejected), we (BibLibre) are completly OK to
reach him and explain : "well, your idea seems a wrong one, because of
this, and that. So, either you confirm your request, and you already
know the feature won't be a part of "Official Koha", you'll have your
fork, or you update your request to have something useful for
everybody". And i'm 95% sure that our customer(s) will answer : "well,
ok, let's stay community oriented".
The problems occurs for everybody if the "no-go" appears AFTER the dev
has been done ! pain for the dev, pain for the library that has
sponsored something that is not accepted in Koha (& pain for the
community, because maybe, an amended RFC would have been OK).

Sometimes ppl think/argue it's dangerous to trust "a community". But I
always remember the "FLOSS moto" : given enough eyes, all bugs will be
detected. Here it's not a matter of bug, but what may seem a good idea
to a library may in fact not be one, and the community has enough eyes
to see & argue it's a bad idea (& thus convince the original library to
reconsider his request).

Hint: in the RFCs I posted yesterday, I see at least one thing that
could/should be amended. Very easy to amend & will definetly be a better
idea. Let's see if someone find it ;-)
> I would also suggest that we implement a policy that states in some
> agreable way that code/features will not be pushed to master which
> have not passed through a review and consensus process by the
> community and the RM (as the elected head of development by the
> community). No one excepting possibly the RM should presuppose that
> their code is guaranteed inclusion by default.
I think it's better to have a review even for the RM (except for very
small patches/obvious mistakes)
> Secondly, I would suggest that we implement a strong recommendation
> that larger shops submit timely RFC's *prior to* beginning work on
> code and then promote discussion on those RFC's. This recommendation
> should with some lesser strength suggest that everyone submit timely
> RFC's to maximize productivity and usefulness of the resources of all
> concerned.
++
We haven't started working on any of those RFCs (except solR, to have a
proof of concept).
What has really be a problem for us is that we published RFCs for Lyon3
university a long time ago (mail from Nicolas on koha-devel oct, 12,
2009), there has been strictly no reaction/feedback to those RFCs.
Now they are done, and we have rebased them vs head (huge work, and huge
QA to do, and probably a lot of time lost)
Could they be rejected by the community ? hopefully I hope no, but I
frankly don't know what we (BibLibre) could do if it were :-((( (because
the customers are live now !)
I think we (all) failed because Koha 3.2 was 9 months late. Well, in
fact, I think the mistake was not to branch 3.4 immediatly on feature
freeze. That would have been much less pain for us (that are
customer-planning driven) (suggestion below).
> Thirdly, I would suggest a stated policy (and such a policy is
> presently in place practically) which requires all submissions to pass
> through a QA branch and receive at a minimum one sign-off prior to
> being pushed into master. This policy should also assign a certain
> amount of responsibility to the one signing off to avoid "frivolous"
> sign-offs. It should also, perhaps, include a restriction that the
> required sign-off for pushing to master be a disinterested developer
> perhaps from another vendor or the community at large.
OK, except for obvious bugfixes/patches
Another question : some librarians like liz started to test our
branches, mainly the biggest one, and she find the features "awesome".
How could we have librarian being more involved in QA from a functionnal
point of view ? (suggestions below)
> This is a discussion we need to have. I would encourage everyone to
> invest time (the operative term here is 'invest') in this discussion.

SUGGESTIONS TO DISCUSS:
* branch next version when the RM declare feature freeze for a given version
* have a website rebuilded every night (week ?) (from which branch ? a
waiting_librarian_feedback one ?), with all marc21 default values fitted
in (with maybe a few biblios added), the librarians being requested to
test from a functionnal point of view after the techies QA validation

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