<div dir="ltr"><div>In my opinion the QA queue (as well as the signoff queue actually) should be processed by bugs severity: blocker, critical, major, others. It's a "should be", not a "is"...<br></div>And then the new enhancements, features.<br><br>The way the patch is written, the length of the diff, the author of the patches (yes!), the module it affects (not SIP...) are some of my personal factors.<br><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 29 Mar 2017 at 12:28 Cab Vinton <<a href="mailto:bibliwho@gmail.com">bibliwho@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, all makes perfect sense, Jonathan.<br class="gmail_msg">
<br class="gmail_msg">
I suspect the way in which projects work their through QA is opaque to<br class="gmail_msg">
most libraries, and like any client, they're always happy when their<br class="gmail_msg">
projects get lots of attention, move through quickly, etc.<br class="gmail_msg">
<br class="gmail_msg">
I believe at any given time there are dozens of patches somewhere in<br class="gmail_msg">
the QA process.<br class="gmail_msg">
<br class="gmail_msg">
So from the client's perspective it would be great to have a better<br class="gmail_msg">
understanding of how the QA team determines which ones to work on<br class="gmail_msg">
first. I believe the vast majority have P5 priorities & low severity<br class="gmail_msg">
(i.e., are "enhancements" rather than critical or major).<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
<br class="gmail_msg">
Cab<br class="gmail_msg">
<br class="gmail_msg">
On Wed, Mar 29, 2017 at 11:04 AM, Jonathan Druart<br class="gmail_msg">
<<a href="mailto:jonathan.druart@bugs.koha-community.org" class="gmail_msg" target="_blank">jonathan.druart@bugs.koha-community.org</a>> wrote:<br class="gmail_msg">
> The developer is supposed to estimate the cost of the development including<br class="gmail_msg">
> the QA process and the different steps of submission.<br class="gmail_msg">
> A (good) developer must take care of most of the project's requirements and<br class="gmail_msg">
> follow the guidelines.<br class="gmail_msg">
> He will also provide tests for the change he made, write a valid and correct<br class="gmail_msg">
> test plan, take care of side-effects, provide small patches, etc.<br class="gmail_msg">
> The longer a developer will spend during the development step (before the<br class="gmail_msg">
> first submission), the quicker the QA process will/should be :)<br class="gmail_msg">
><br class="gmail_msg">
> Hope it makes sense,<br class="gmail_msg">
> Jonathan<br class="gmail_msg">
><br class="gmail_msg">
> PS: QA is not an exact science...<br class="gmail_msg">
</blockquote></div></div></div></div>