I think this has the potential to create a lot of conflict. I know the guideline saying that one company shouldnt sign off its own patches slows things down, but like Owen I think its an important guideline. While Im sure no one would abuse the process maliciously, I think a lot of mistakes would probably go unnoticed out of a desire to speed along the process. Even if the tester hasnt worked on the development, there is an (unspoken) incentive to pass the patch and be less critical than someone from another organization. I think stability is more important than more features. Of course, some recent patches have shown that even our current process isnt always able to catch all the problems. I think Brooke mentioned that we need more people. Thats probably true. If you think about it, more sign offs will mean even more of a burden on QA, which will mean more and more mistakes get through. Of course, I want to volunteer and do more, but I dont have the time. Where do we stand regarding a patch coming from one company, a different company signing off, and QA coming from the original company? If Bywater and BibLibre add more people to the QA team, and test each others patches, that probably could compensate for higher volumes of patches both needing testing and having been tested. Mind you, I suppose the incentive then becomes to test the other companys patches faster so they test yours faster and maybe the level of criticism lowers again anyway. Maybe we should trust peoples judgement and let more people add sign offs (so long as were also adding eyes to QA, I think). In any case, I think the main point where conflict will come is in the pointing out of abuse. No one likes receiving criticism. I could easily see rifts forming where one or two companies think that theyre acting within the guidelines but other people think theyre abusing the system. I think it would be awkward to point out such abuses in some cases, and heated or tense in other cases. I dont know. Those are my two cents. Im the only one at my company involved in the community, so I dont really have a stake either way. Im just concerned about stability and overworking key individuals. That said, I dont have the time to volunteer at the moment. Ive been too busy to test or contribute patches recently, so I wouldnt put too much weight in my words. I suppose Id like to hear from the QA team and former/present/future Release Managers on the subject. If they think they can handle an influx of patches due to companies signing off their own patches (admittedly via different individuals) and potential interpersonal conflict, then I suppose Im up for it. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Brendan Gallagher Sent: Saturday, 11 October 2014 2:10 AM To: Koha Devel Subject: [Koha-devel] Proposal for a change in guidelines for the sign-off process in the Koha-community Hello All - During the hackfest, there was a discussion on the sign-off process for Koha. In attendance was, Nathan, Chris, Katrin, Paul_P, Jonathan, Arnaud, Joy, Brendan, Tomás, Brooke, Tom, and BobB. Here is what we all agreed upon to send a proposal to the next developers or general meeting Id like to put forward a motion for removal of the guideline that one company shouldnt sign-off on the same company's patches within the community. I am suggesting additional checks be included in the sign-off process to prevent abuse of the proposed guideline, such as the committer and the person signing off must not have collaborated on the development of the patch. We shall review that idea/process every 6 months as an agenda item in the general meeting, to make sure that no abuse of the new privilege has occurred; also note here - that we do not have to wait 6 months to point out abuse of this new privilege. The QA team and Release Team still have the right to ask for more eyes to look at a certain bug at anytime and this should continue. Thank you, Brendan Gallagher