<div dir="ltr"><div><div>I agree these are good ideas. We have done these many times, but the follow-through just never really happens.<br><br></div>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.<br><br></div>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.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 15, 2014 at 7:27 AM, Heather Braum (NEKLS) <span dir="ltr"><<a href="mailto:hbraum@nekls.org" target="_blank">hbraum@nekls.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. <br><br>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. <br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Heather Braum<br>NExpress Coordinator<br>Resource Sharing Librarian<br>Northeast Kansas Library System<br><a href="mailto:hbraum@nekls.org" target="_blank">hbraum@nekls.org</a><br><br><div>"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*<br><br><br><br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Wed, Oct 15, 2014 at 7:23 AM, Owen Leonard <span dir="ltr"><<a href="mailto:oleonard@myacpl.org" target="_blank">oleonard@myacpl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I’d like to put forward a motion for removal of the guideline that one<br>
> company shouldn’t sign-off on the same company's patches within the<br>
> community.<br>
<br>
</span>I think this is a good rule, and I think our current process has<br>
proved that by showing that with many different points of view looking<br>
at the code more issues can be found which need to be addressed before<br>
something is ready.<br>
<br>
I realize how frustrating it is to have something big and hard to test<br>
languish in the QA process, but I think the right solution might be to<br>
get more creative about how to help things move along.<br>
<br>
>From my perspective as a bug tester the biggest thing I can say about<br>
it is to have good test plans. I mean really really good test plans.<br>
List, explicitly, every possible step that the tester could take to<br>
test the patch.<br>
<br>
The obvious example here is Bug 6427 - Rewrite of the accounts system<br>
(<a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427" target="_blank">http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427</a>). A big<br>
patch that touches a LOT of files and involves one of the most<br>
mission-critical aspects of Koha's circulation functionality. Pushing<br>
it before it was properly tested could be disastrous for libraries who<br>
collect fines throughout the day.<br>
<br>
The bug has a pretty good test plan, but is that enough? What else<br>
could we do to make sure it's ready for production? Perhaps set up a<br>
dedicated test instance with some good sample data, give out logins<br>
which give permission to circulate and collect fines, assign multiple<br>
days' worth of tests to be performed by multiple testers?<br>
<br>
Getting volunteer testers is hard, and getting multiple volunteer<br>
testers is harder, but sometimes I think we need to take a more active<br>
hand in soliciting and promoting testing.<br>
<span><font color="#888888"><br>
-- Owen<br>
<br>
--<br>
Web Developer<br>
Athens County Public Libraries<br>
<a href="http://www.myacpl.org" target="_blank">http://www.myacpl.org</a><br>
</font></span><div><div>_______________________________________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a></div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="http://www.koha-community.org/" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" target="_blank">http://bugs.koha-community.org/</a><br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">---------------------------------------------------------------------------------------------------------------<br>Brendan A. Gallagher<br>ByWater Solutions<br>CEO<br><br>Support and Consulting for Open Source Software<br>Installation, Data Migration, Training, Customization, Hosting<br>and Complete Support Packages<br>Headquarters: Santa Barbara, CA - Office: Redding, CT<br>Phone # (888) 900-8944<br><a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a><br><a href="mailto:info@bywatersolutions.com" target="_blank">info@bywatersolutions.com</a><br></div>
</div>