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
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
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
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
Le 02/11/2010 16:24, Chris Nighswonger a écrit : 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. 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 ;-) 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). 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