I think this has the potential to create a lot of conflict.

 

I know the guideline saying that one company shouldn’t sign off its own patches slows things down, but – like Owen – I think it’s an important guideline. While I’m 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 hasn’t 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 isn’t always able to catch all the problems.

 

I think Brooke mentioned that we need more people. That’s 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 don’t 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 other’s 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 company’s patches faster so they test yours faster and maybe the level of criticism lowers again anyway. Maybe we should trust people’s judgement and let more people add sign offs (so long as we’re 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 they’re acting within the guidelines but other people think they’re 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 don’t know. Those are my two cents. I’m the only one at my company involved in the community, so I don’t really have a stake either way. I’m just concerned about stability and overworking key individuals. That said, I don’t have the time to volunteer at the moment. I’ve been too busy to test or contribute patches recently, so I wouldn’t put too much weight in my words.

 

I suppose I’d 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 I’m 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

I’d like to put forward a motion for removal of the guideline that one company shouldn’t 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