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

[MJ Ray]

Chris Nighswonger wrote:
> 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).

Why is there little discussion?  I think low-comment RFCs are often
posted in large batches.  That is easier for the requestor but means
that the same weekly average of commenter time gets spread between
them all, resulting in a low level of discussion on each one.  The
current wiki isn't the easiest thing to track or edit and wikis are
generally bad places for lengthy discussion.

How might we remedy this?  "RFC Corner" in the newsletter and meetings?
How else?

> [...] Clients of vendors should be educated during
> the RFQ process as to this aspect of open source, and their expectations
> managed accordingly, imho.

Well, we try, but free software vendors can't do this too much because
some suppliers of "open source" disagree that these communities are
good or even necessary.  Community-friendly vendors would probably
lose orders to them if we pushed the point harder because it would
make us look slower.  It needs to be done by vendor-neutral advisory
services like www.oss-watch.ac.uk - anyone want to back one for
Koha-Community.org?

[...]
> 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.

This will almost certainly not happen in some cases, such as where the
ordering librarian wants the feature yesterday or as near as, so work
is expected to start immediately when the order is placed, or in
situations where the ordering librarian is new to FOSS and things like
RFC processes.

Although we don't do it and I hope no-one does, I also suggest there's
a commercial incentive to hold back details in the hope of being paid
twice for the same feature.  If the RFCs ever helped gather orders
(such as I'd like
http://wiki.koha-community.org/wiki/NISO_CORE_protocol to do), then
maybe some commercial incentive would push the other way, but how many
examples of RFC-first development work have there been?  Even when the
RFC appears before coding, the order has already been placed.  The new
Template:RFC doesn't even have an option for an not-yet-ordered RFC.

So while I feel the sentiment is good, I think it would be unrealistic
to make this recommendation strong.  I'd be delighted if we could work
like that, but it's not what clients usually request (or pay for).

> 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. [...]

I feel that this and the "review and consensus process" are both up to
the RMs and should be part of their manifestoes (or not, as the case
may be).  It's a release management matter, not a general policy one.
Do as you will.

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha