Development/ QA protocol question
Hi, All -- A small group of small NH libraries has co-sponsored a small enhancement to get its feet wet in the Koha development world: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14365 As I understand it, once a patch has been signed off & passed on to QA, it can hit a bottleneck as there are limited number of QA Team Members. To make this as positive experience as possible for our informal consortium & to increase the chances of similar collaborations in the future, it would help if we can move through the development process as quickly as possible. So here's my question -- For sponsored (i.e., funded) projects, would it make sense to include funds to pay for the cost of a QA Team Member's time to review a patch? I'm thinking the financial commitment would be one way of boosting a patch's status in the queue. Hounding the developer is another option, of course, but that's unpleasant for both sides :-) I realize the QA person often, & perhaps preferably, will work for a different firm. And there may be other complicating factors I'm not aware of. Grateful for any thoughts from folks on the programming side of things. Cheers, Cab Vinton, Director Plaistow Public Library Plaistow, NH
This patch already is in PQA. Your question is interesting btw.. ________________________________ Van: koha-devel-bounces@lists.koha-community.org <koha-devel-bounces@lists.koha-community.org> namens Cab Vinton <bibliwho@gmail.com> Verzonden: woensdag 29 maart 2017 16:16 Aan: koha-devel@lists.koha-community.org Onderwerp: [Koha-devel] Development/ QA protocol question Hi, All -- A small group of small NH libraries has co-sponsored a small enhancement to get its feet wet in the Koha development world: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14365 As I understand it, once a patch has been signed off & passed on to QA, it can hit a bottleneck as there are limited number of QA Team Members. To make this as positive experience as possible for our informal consortium & to increase the chances of similar collaborations in the future, it would help if we can move through the development process as quickly as possible. So here's my question -- For sponsored (i.e., funded) projects, would it make sense to include funds to pay for the cost of a QA Team Member's time to review a patch? I'm thinking the financial commitment would be one way of boosting a patch's status in the queue. Hounding the developer is another option, of course, but that's unpleasant for both sides :-) I realize the QA person often, & perhaps preferably, will work for a different firm. And there may be other complicating factors I'm not aware of. Grateful for any thoughts from folks on the programming side of things. Cheers, Cab Vinton, Director Plaistow Public Library Plaistow, NH _______________________________________________ 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/
Hi Cab, I would not expect a QAer to be paid (by the sponsor of the enh) to review a patch, I'd call that more corruption / conflict of interest than sponsoring :) On Wed, 29 Mar 2017 at 11:16 Cab Vinton <bibliwho@gmail.com> wrote:
Hi, All --
A small group of small NH libraries has co-sponsored a small enhancement to get its feet wet in the Koha development world:
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14365
As I understand it, once a patch has been signed off & passed on to QA, it can hit a bottleneck as there are limited number of QA Team Members.
To make this as positive experience as possible for our informal consortium & to increase the chances of similar collaborations in the future, it would help if we can move through the development process as quickly as possible.
So here's my question --
For sponsored (i.e., funded) projects, would it make sense to include funds to pay for the cost of a QA Team Member's time to review a patch? I'm thinking the financial commitment would be one way of boosting a patch's status in the queue. Hounding the developer is another option, of course, but that's unpleasant for both sides :-)
I realize the QA person often, & perhaps preferably, will work for a different firm. And there may be other complicating factors I'm not aware of.
Grateful for any thoughts from folks on the programming side of things.
Cheers,
Cab Vinton, Director Plaistow Public Library Plaistow, NH _______________________________________________ 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/
On Wed, Mar 29, 2017 at 10:30 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
I would not expect a QAer to be paid (by the sponsor of the enh) to review a patch, I'd call that more corruption / conflict of interest than sponsoring :)
Ah. Hadn't thought of it that way. Good point. Not sure there's an easy way around that one, even if the QAer is paid directly by the sponsor. I suppose that's the nature of incentives -- they produce changes in behavior that wouldn't happen otherwise, a process that can be "innocent" or corrupt ... Thanks, Cab
The developer is supposed to estimate the cost of the development including the QA process and the different steps of submission. A (good) developer must take care of most of the project's requirements and follow the guidelines. He will also provide tests for the change he made, write a valid and correct test plan, take care of side-effects, provide small patches, etc. The longer a developer will spend during the development step (before the first submission), the quicker the QA process will/should be :) Hope it makes sense, Jonathan PS: QA is not an exact science... On Wed, 29 Mar 2017 at 11:44 Cab Vinton <bibliwho@gmail.com> wrote:
On Wed, Mar 29, 2017 at 10:30 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
I would not expect a QAer to be paid (by the sponsor of the enh) to review a patch, I'd call that more corruption / conflict of interest than sponsoring :)
Ah. Hadn't thought of it that way. Good point. Not sure there's an easy way around that one, even if the QAer is paid directly by the sponsor.
I suppose that's the nature of incentives -- they produce changes in behavior that wouldn't happen otherwise, a process that can be "innocent" or corrupt ...
Thanks,
Cab
Yes, all makes perfect sense, Jonathan. I suspect the way in which projects work their through QA is opaque to most libraries, and like any client, they're always happy when their projects get lots of attention, move through quickly, etc. I believe at any given time there are dozens of patches somewhere in the QA process. So from the client's perspective it would be great to have a better understanding of how the QA team determines which ones to work on first. I believe the vast majority have P5 priorities & low severity (i.e., are "enhancements" rather than critical or major). Thanks, Cab On Wed, Mar 29, 2017 at 11:04 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
The developer is supposed to estimate the cost of the development including the QA process and the different steps of submission. A (good) developer must take care of most of the project's requirements and follow the guidelines. He will also provide tests for the change he made, write a valid and correct test plan, take care of side-effects, provide small patches, etc. The longer a developer will spend during the development step (before the first submission), the quicker the QA process will/should be :)
Hope it makes sense, Jonathan
PS: QA is not an exact science...
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"... And then the new enhancements, features. 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. On Wed, 29 Mar 2017 at 12:28 Cab Vinton <bibliwho@gmail.com> wrote:
Yes, all makes perfect sense, Jonathan.
I suspect the way in which projects work their through QA is opaque to most libraries, and like any client, they're always happy when their projects get lots of attention, move through quickly, etc.
I believe at any given time there are dozens of patches somewhere in the QA process.
So from the client's perspective it would be great to have a better understanding of how the QA team determines which ones to work on first. I believe the vast majority have P5 priorities & low severity (i.e., are "enhancements" rather than critical or major).
Thanks,
Cab
On Wed, Mar 29, 2017 at 11:04 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
The developer is supposed to estimate the cost of the development including the QA process and the different steps of submission. A (good) developer must take care of most of the project's requirements and follow the guidelines. He will also provide tests for the change he made, write a valid and correct test plan, take care of side-effects, provide small patches, etc. The longer a developer will spend during the development step (before the first submission), the quicker the QA process will/should be :)
Hope it makes sense, Jonathan
PS: QA is not an exact science...
. I believe the vast majority have P5 priorities & low severity (i.e., are "enhancements" rather than critical or major).
Note that the priority scale (P5-P1) is not used. I agree with Jonathan's process of evaluating the priority of bugs based on severity. It should also be understood that simple patches are far more likely to be signed off and thus QA'ed sooner. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Thank you, Owen. If the priority scale is unused, then seems like a good candidate for removal/ suppression from Bugzilla, if possible. Severity is definitely a good first pass. As I mentioned earlier, however, the vast majority are "enhancements", so QAer's would have to move on to other factors fairly quickly. I think length/ complexity can be checked by looking at the attachments in BugZilla. Would be neat if there were an easier way from the main screen. Cheers, Cab On Wed, Mar 29, 2017 at 12:21 PM, Owen Leonard <oleonard@myacpl.org> wrote:
. I believe the vast majority have P5 priorities & low severity (i.e., are "enhancements" rather than critical or major).
Note that the priority scale (P5-P1) is not used. I agree with Jonathan's process of evaluating the priority of bugs based on severity. It should also be understood that simple patches are far more likely to be signed off and thus QA'ed sooner.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org
There is a "Patch complexity" field, but I personally do not use it (I should yes). On Wed, 29 Mar 2017 at 17:48 Cab Vinton <bibliwho@gmail.com> wrote:
Thank you, Owen.
If the priority scale is unused, then seems like a good candidate for removal/ suppression from Bugzilla, if possible.
Severity is definitely a good first pass. As I mentioned earlier, however, the vast majority are "enhancements", so QAer's would have to move on to other factors fairly quickly.
I think length/ complexity can be checked by looking at the attachments in BugZilla. Would be neat if there were an easier way from the main screen.
Cheers,
Cab
On Wed, Mar 29, 2017 at 12:21 PM, Owen Leonard <oleonard@myacpl.org> wrote:
. I believe the vast majority have P5 priorities & low severity (i.e., are "enhancements" rather than critical or major).
Note that the priority scale (P5-P1) is not used. I agree with Jonathan's process of evaluating the priority of bugs based on severity. It should also be understood that simple patches are far more likely to be signed off and thus QA'ed sooner.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org
On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
There is a "Patch complexity" field, but I personally do not use it (I should yes).
I've see. Don't think anyone else uses it either :-) Would be cool if it auto-populated with the number of new/ different lines in the patch ... Pretty rough & ready measure of complexity.
The complexity does not depend on the size of the patch :) A one line patch can be much more complex than a 1k lines patch On Wed, 29 Mar 2017 at 18:00 Cab Vinton <bibliwho@gmail.com> wrote:
On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
There is a "Patch complexity" field, but I personally do not use it (I should yes).
I've see. Don't think anyone else uses it either :-)
Would be cool if it auto-populated with the number of new/ different lines in the patch ... Pretty rough & ready measure of complexity.
Bug 15760, 13690 are about Koha::Schema. They are very small but they fix global problems and can have big side effects. Patches that add external JS libs, move files, update less/css, or thing like bug 9978 are huge but are easy to review On Thu, 30 Mar 2017 at 08:58 Cab Vinton <bibliwho@gmail.com> wrote:
A one line patch can be much more complex than a 1k lines patch
¯\_(ツ)_/¯
Now you got me curious. Can you provide an example of this? For research purposes :-)
Bug 15760, 13690 are about Koha::Schema. They are very small but they fix global problems and can have big side effects. Patches that add external JS libs, move files, update less/css, or thing like bug 9978 are huge but are easy to review
Ah, OK. Makes sense. Thank you, Jonathan!
I always fill patch complexity. Also for patches that I qa. And not filling that field (and/or other fields) gives it a lower priority. And yes, the number of lines is not the same as complexity. -----Oorspronkelijk bericht----- Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Cab Vinton Verzonden: woensdag 29 maart 2017 23:01 Aan: Jonathan Druart <jonathan.druart@bugs.koha-community.org> CC: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Development/ QA protocol question On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
There is a "Patch complexity" field, but I personally do not use it (I should yes).
I've see. Don't think anyone else uses it either :-) Would be cool if it auto-populated with the number of new/ different lines in the patch ... Pretty rough & ready measure of complexity. _______________________________________________ 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/
+1 for using 'Patch complexity' 'Patch complexity' gives a hint for singing off as well. While signing off I fill it in most of the cases. Sometimes I forget it, though... Marc Am 30.03.2017 um 08:34 schrieb Marcel de Rooy:
I always fill patch complexity. Also for patches that I qa. And not filling that field (and/or other fields) gives it a lower priority. And yes, the number of lines is not the same as complexity.
-----Oorspronkelijk bericht----- Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Cab Vinton Verzonden: woensdag 29 maart 2017 23:01 Aan: Jonathan Druart <jonathan.druart@bugs.koha-community.org> CC: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Development/ QA protocol question
On Wed, Mar 29, 2017 at 4:58 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
There is a "Patch complexity" field, but I personally do not use it (I should yes). I've see. Don't think anyone else uses it either :-)
Would be cool if it auto-populated with the number of new/ different lines in the patch ... Pretty rough & ready measure of complexity. _______________________________________________ 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/
participants (5)
-
Cab Vinton -
Jonathan Druart -
Marc Véron -
Marcel de Rooy -
Owen Leonard