Starting a new thread because this is indirectly related to Paul's request.
2010/11/2 Paul Poulain <paul.poul...@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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/