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
One Additional note - I would continue to encourage all those that sign-off on bugs to really add a lot of notes to their sign-offs. The more information on places that you may have been stuck or parts you were not 100% sure on - really really help the QA and RM teams. That is totally one thing that I need to get better at during my sign-offs and testing periods. Thanks, Brendan On Fri, Oct 10, 2014 at 8:10 AM, Brendan Gallagher < info@bywatersolutions.com> wrote:
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
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
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.
See: http://wiki.koha-community.org/wiki/Development_workflow These workflow rules on the wiki already say: Preferably, patch writer and patch signer should not be from the same company or institution. Yes, it is preferred but is not strictly required. And also: If a patch is not passed QA for one month, then it can be QA'd by someone from the same company or institution. I would suggest to make the following change: If a patch has not been signed for one month, it can be signed off by someone from the same company or institution. (Easy to check by QAer.) And to prevent "abuse" of the combination (signoff and QA in the same company): If a patch has not passed QA for one month, then it can be QA'd by someone from the same company or institution UNLESS it is already signed by someone from the same company. (Does this rule need a sort of escape to prevent very specific patches waiting for several months in the SO queue?) Marcel
HI Marcel - I think most everyone that was in attendance thought differently then those guidelines. Some said 3 months others said not at all, etc etc. So I'm just bring this up so that everyone is on the same page and changing the guideline so that there isn't a 1 month "wait" period. (Yes it is evident that communication in the community is lacking) Thanks, Brendan On Mon, Oct 13, 2014 at 12:45 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
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.
See: http://wiki.koha-community.org/wiki/Development_workflow
These workflow rules on the wiki already say:
*Preferably*, patch writer and patch signer should not be from the same company or institution.
Yes, it is preferred but is not strictly required.
And also:
If a patch is not passed QA for one month, then it can be QA'd by someone from the same company or institution.
I would suggest to make the following change:
If a patch has not been signed for one month, it can be signed off by someone from the same company or institution. (Easy to check by QAer.)
And to prevent "abuse" of the combination (signoff and QA in the same company):
If a patch has not passed QA for one month, then it can be QA'd by someone from the same company or institution UNLESS it is already signed by someone from the same company. (Does this rule need a sort of escape to prevent very specific patches waiting for several months in the SO queue?)
Marcel
_______________________________________________ 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/
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
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 think this is a good rule, and I think our current process has proved that by showing that with many different points of view looking at the code more issues can be found which need to be addressed before something is ready. I realize how frustrating it is to have something big and hard to test languish in the QA process, but I think the right solution might be to get more creative about how to help things move along.
From my perspective as a bug tester the biggest thing I can say about it is to have good test plans. I mean really really good test plans. List, explicitly, every possible step that the tester could take to test the patch.
The obvious example here is Bug 6427 - Rewrite of the accounts system (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427). A big patch that touches a LOT of files and involves one of the most mission-critical aspects of Koha's circulation functionality. Pushing it before it was properly tested could be disastrous for libraries who collect fines throughout the day. The bug has a pretty good test plan, but is that enough? What else could we do to make sure it's ready for production? Perhaps set up a dedicated test instance with some good sample data, give out logins which give permission to circulate and collect fines, assign multiple days' worth of tests to be performed by multiple testers? Getting volunteer testers is hard, and getting multiple volunteer testers is harder, but sometimes I think we need to take a more active hand in soliciting and promoting testing. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
I don't want to weigh in on the overall discussion around these changes, but I thinkOwen's point about a setting up a separate test instance to test major features like his example of bug 6427 is a very good idea, and would allow many people to test it thoroughly, in a more robust, almost live environment. The more eyes on something this critical, the better, especially if you involve librarians at the circulation desk who deal with this part of the system many, many times a day. But having a test system these people can access is the key -- they aren't normally engaged in the community, but you know they know the fining system, and want to see it work. My organization has been waiting for this development for over a year now, and I can think of several people at our libraries that I'd be willing to volunteer to do some thorough testing if something like this was set up. Heather Braum NExpress Coordinator Resource Sharing Librarian Northeast Kansas Library System hbraum@nekls.org "The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn." ~Alvin Toffler, *Rethinking the Future* On Wed, Oct 15, 2014 at 7:23 AM, Owen Leonard <oleonard@myacpl.org> wrote:
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 think this is a good rule, and I think our current process has proved that by showing that with many different points of view looking at the code more issues can be found which need to be addressed before something is ready.
I realize how frustrating it is to have something big and hard to test languish in the QA process, but I think the right solution might be to get more creative about how to help things move along.
From my perspective as a bug tester the biggest thing I can say about it is to have good test plans. I mean really really good test plans. List, explicitly, every possible step that the tester could take to test the patch.
The obvious example here is Bug 6427 - Rewrite of the accounts system (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427). A big patch that touches a LOT of files and involves one of the most mission-critical aspects of Koha's circulation functionality. Pushing it before it was properly tested could be disastrous for libraries who collect fines throughout the day.
The bug has a pretty good test plan, but is that enough? What else could we do to make sure it's ready for production? Perhaps set up a dedicated test instance with some good sample data, give out logins which give permission to circulate and collect fines, assign multiple days' worth of tests to be performed by multiple testers?
Getting volunteer testers is hard, and getting multiple volunteer testers is harder, but sometimes I think we need to take a more active hand in soliciting and promoting testing.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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/
I agree these are good ideas. We have done these many times, but the follow-through just never really happens. I guess I'm more pointing out we've (we've = koha-community) got a problem with the current process. We have more patches than we have as a collective "volunteer time" within the community to keep up with the demand. The main point is we need more people in the community (one way to achieve that is to not limit the pool of potential community members signing-off on bugs - that's what I'm proposing). Everyone that attended the hackfest did not have any major problems with what we talked about - it was really an attitude of "Let's try it and see what happens (some thought it would help and others just weren't sure it would really make a difference or not)." I am excited to give it a try. We've changed our process a little and we find some libraries that will use a major feature in a production environment (a very small group, cause we try to keep everyone on the main releases of Koha), so once they have used it for awhile, we get them to sign-off on the bug. On Wed, Oct 15, 2014 at 7:27 AM, Heather Braum (NEKLS) <hbraum@nekls.org> wrote:
I don't want to weigh in on the overall discussion around these changes, but I thinkOwen's point about a setting up a separate test instance to test major features like his example of bug 6427 is a very good idea, and would allow many people to test it thoroughly, in a more robust, almost live environment. The more eyes on something this critical, the better, especially if you involve librarians at the circulation desk who deal with this part of the system many, many times a day. But having a test system these people can access is the key -- they aren't normally engaged in the community, but you know they know the fining system, and want to see it work.
My organization has been waiting for this development for over a year now, and I can think of several people at our libraries that I'd be willing to volunteer to do some thorough testing if something like this was set up.
Heather Braum NExpress Coordinator Resource Sharing Librarian Northeast Kansas Library System hbraum@nekls.org
"The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn." ~Alvin Toffler, *Rethinking the Future*
On Wed, Oct 15, 2014 at 7:23 AM, Owen Leonard <oleonard@myacpl.org> wrote:
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 think this is a good rule, and I think our current process has proved that by showing that with many different points of view looking at the code more issues can be found which need to be addressed before something is ready.
I realize how frustrating it is to have something big and hard to test languish in the QA process, but I think the right solution might be to get more creative about how to help things move along.
From my perspective as a bug tester the biggest thing I can say about it is to have good test plans. I mean really really good test plans. List, explicitly, every possible step that the tester could take to test the patch.
The obvious example here is Bug 6427 - Rewrite of the accounts system (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427). A big patch that touches a LOT of files and involves one of the most mission-critical aspects of Koha's circulation functionality. Pushing it before it was properly tested could be disastrous for libraries who collect fines throughout the day.
The bug has a pretty good test plan, but is that enough? What else could we do to make sure it's ready for production? Perhaps set up a dedicated test instance with some good sample data, give out logins which give permission to circulate and collect fines, assign multiple days' worth of tests to be performed by multiple testers?
Getting volunteer testers is hard, and getting multiple volunteer testers is harder, but sometimes I think we need to take a more active hand in soliciting and promoting testing.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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/
_______________________________________________ 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/
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
Salvete! The volunteer model is a good part of what is stalling the process. I can't see that having a single company sign off on their own code will necessarily ameliorate the problem if the companies themselves do not place enough of a value on bug testing that they are willing to include it within their service and enhancement RFPs. I still think of this as a happy problem; we're doing so much it's tough to get to everything. That speaks to planning and prioritisation at the root, though. More eyes are better once again: a single corporation's goals might vary widely with the community's. I am also wary of externalising the bad guy role to the QA or RM. Both of these individuals, regardless of who they are, have always had a heavy burden to carry. I am easier with this concept if it involves bugs that are not critical or blockers, which is what I thought was being proposed initially. I very much agree with Owen and Heather. I feel like there's accord on a year+ being far too long to wait on a new feature of any type. What does everyone feel is the right amount of time before falling back to a more lax protocol? A month has been mentioned, but I wonder if that's not too short. Cheers, Brooke
I like the sound of this. As I mentioned in my other email, I think stability is super important. I rather a feature languish indefinitely than have an unstable system that is going to give people major problems and corrupt the integrity of their data. Of course, it can be tough to test some features in test environments. I think Brendan mentioned how sometimes they'll push a feature locally and then upstream it only when it's been proven at the local level. I think that this is also really good idea. I've done this from time to time as well, although usually for small things relating to display. I'm generally very hesitant to make local enhancements that affect data in any way. At the moment, I'm looking at adding an OAI harvester client again, and I'm developing against master. I thought about doing it locally and then pushing it up, but it requires too many database additions and I want it to benefit from community scrutiny. I feel sometimes that we try to add too many bells and whistles. At this moment, there are 164 patches waiting to be tested. Only 41 of those are bugs. Personally, I would love more attention shown to bugs than enhancements. But again... that's just my two cents as someone with not a lot of time atm. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Owen Leonard Sent: Wednesday, 15 October 2014 11:23 PM To: Koha Devel Subject: Re: [Koha-devel] Proposal for a change in guidelines for the sign-off process in the Koha-community
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 think this is a good rule, and I think our current process has proved that by showing that with many different points of view looking at the code more issues can be found which need to be addressed before something is ready.
I realize how frustrating it is to have something big and hard to test languish in the QA process, but I think the right solution might be to get more creative about how to help things move along.
From my perspective as a bug tester the biggest thing I can say about it is to have good test plans. I mean really really good test plans. List, explicitly, every possible step that the tester could take to test the patch.
The obvious example here is Bug 6427 - Rewrite of the accounts system (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427). A big patch that touches a LOT of files and involves one of the most mission-critical aspects of Koha's circulation functionality. Pushing it before it was properly tested could be disastrous for libraries who collect fines throughout the day.
The bug has a pretty good test plan, but is that enough? What else could we do to make sure it's ready for production? Perhaps set up a dedicated test instance with some good sample data, give out logins which give permission to circulate and collect fines, assign multiple days' worth of tests to be performed by multiple testers?
Getting volunteer testers is hard, and getting multiple volunteer testers is harder, but sometimes I think we need to take a more active hand in soliciting and promoting testing.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ 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/
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
participants (6)
-
Brendan Gallagher -
BWS Johnson -
David Cook -
Heather Braum (NEKLS) -
Marcel de Rooy -
Owen Leonard