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

[Chris Nighswonger]

 Starting a new thread because this is indirectly related to Paul's request.

2010/11/2 Paul Poulain <paul.poulain at biblibre.com>

>  Hello,
>
> I have filed RFCs for all enhancements you can expect from BibLibre in the
> next few months. All of them are sponsored (by Saint-Etienne University),
> and will have to be delivered to the library for a "go live" in May-2011
>
> * You can find them on the wiki (search biblibre rfc for3.4) :
> http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redirs=1&search=biblibre+rfc+for3.4&limit=50&offset=0
> * You can also find them on bugzilla : i've added a saved search, shared
> with everybody, called "Koha 3.4 enhancements".
>
> They are only related to serials and acquisitions.
>
> What's the next step ?
> * read the RFCs
> * comment them (on the wiki or on bugzilla)
> * we will probably propose/organise an IRC meeting to discuss & get any
> feedback for all those incoming developments. None of them (except the solR
> one) has started, so if you want to give us an advice, add something, ...
> it's now or it may be too late ;-)
>
>
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).

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 would also suggest that we implement a policy that states in some
agreeable 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.

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.

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.

This is a discussion we need to have. I would encourage everyone to invest
time (the operative term here is 'invest') in this discussion.

Kind Regards,
Chris Nighswonger
Koha 3.2.x Release Maintainer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101102/6e3a9d42/attachment-0001.htm>