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 _______________________________________________ Koha-devel mailing list [email protected] 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/
