Some thoughts from QA team
Hi koha-devel, The 3.10 and 3.12 QA teams ( Mason, Jonathan, Marcel & me, with the freshly elected Travis, Katrin -and Jared as RM-) have had a discussion about QA process and would like to propose the 2 following things: * Create a QA specific mailing list (qa@lists.koha-community.org ?) This list would be used for QA related discussions. We had some private discussions in the last months (mostly about koha-qa.pl tool = should we add this, remove that,...), and think it's better to have a public mailing list. [ One thing that worried us is "should we let anyone subscribe to the list or moderate list subscriptions to avoid non-QA threads". Not a big deal, but if you've an opinion... ] * Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing. Comments welcomed. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On 24 October 2012 22:47, Paul Poulain <paul.poulain@biblibre.com> wrote:
Hi koha-devel,
The 3.10 and 3.12 QA teams ( Mason, Jonathan, Marcel & me, with the freshly elected Travis, Katrin -and Jared as RM-) have had a discussion about QA process and would like to propose the 2 following things:
* Create a QA specific mailing list (qa@lists.koha-community.org ?) This list would be used for QA related discussions. We had some private discussions in the last months (mostly about koha-qa.pl tool = should we add this, remove that,...), and think it's better to have a public mailing list. [ One thing that worried us is "should we let anyone subscribe to the list or moderate list subscriptions to avoid non-QA threads". Not a big deal, but if you've an opinion... ]
Why can't we use the koha-devel list, and/or the bugs themselves .. what type of mails would be on the qa list that wouldn't be fine on the koha-devel list? And if they are patch specific then on the bug itself makes more sense. I'd definitely like to see any qa discussions public, but I don't see the need for a new list .. am I missing something?
* Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing.
I don't see any problem with this. Chris
On 2012-10-24, at 10:52 PM, Chris Cormack wrote:
On 24 October 2012 22:47, Paul Poulain <paul.poulain@biblibre.com> wrote:
Hi koha-devel,
The 3.10 and 3.12 QA teams ( Mason, Jonathan, Marcel & me, with the freshly elected Travis, Katrin -and Jared as RM-) have had a discussion about QA process and would like to propose the 2 following things:
* Create a QA specific mailing list (qa@lists.koha-community.org ?) This list would be used for QA related discussions. We had some private discussions in the last months (mostly about koha-qa.pl tool = should we add this, remove that,...), and think it's better to have a public mailing list. [ One thing that worried us is "should we let anyone subscribe to the list or moderate list subscriptions to avoid non-QA threads". Not a big deal, but if you've an opinion... ]
Why can't we use the koha-devel list, and/or the bugs themselves .. what type of mails would be on the qa list that wouldn't be fine on the koha-devel list? And if they are patch specific then on the bug itself makes more sense.
I'd definitely like to see any qa discussions public, but I don't see the need for a new list .. am I missing something?
yes Chris, you are missing a lot of boring chatter :) if people are OK with having the QA-team discuss their stuff on the koha-devel list, then i am happy (we could prefix the QA email's subject with 'QA: ', so people can ignore them easily, if they want too) are people OK with this? Mason
Mason James schrieb
if people are OK with having the QA-team discuss their stuff on the koha-devel list, then i am happy (we could prefix the QA email's subject with 'QA: ', so people can ignore them easily, if they want too)
are people OK with this?
I am. And I think anyone on the dev-list should be as it is relevant to you QAing our patches ;) -- Mirko
On 24 October 2012 12:49, Mason James <mtj@kohaaloha.com> wrote:
if people are OK with having the QA-team discuss their stuff on the koha-devel list, then i am happy (we could prefix the QA email's subject with 'QA: ', so people can ignore them easily, if they want too)
are people OK with this?
+1 Magnus
(we could prefix the QA email's subject with 'QA: ', so people can ignore them easily, if they want too)
are people OK with this?
+1 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Wed, Oct 24, 2012 at 10:06 AM, Jared Camins-Esakov <jcamins@cpbibliography.com> wrote:
if people are OK with having the QA-team discuss their stuff on the koha-devel list, then i am happy (we could prefix the QA email's subject with 'QA: ', so people can ignore them easily, if they want too)
+1
+1
Greetings,
if people are OK with having the QA-team discuss their stuff on the koha-devel list, then i am happy (we could prefix the QA email's subject with 'QA: ', so people can ignore them easily, if they want too)
are people OK with this?
Yes, +1 to QA tagged subject lines and discussing on koha-devel. GPML, Mark Tompsett
Le 24/10/2012 11:52, Chris Cormack a écrit :
And if they are patch specific then on the bug itself makes more sense.
I'd definitely like to see any qa discussions public, but I don't see the need for a new list .. am I missing something?
Everybody says +1 to your counter-proposal, but we already have a koha-translate mailing list, dedicated to translation questions. And a koha-zebra one that is almost unused, but exist. The goal is just to separate different things in different mailing lists. Not a big deal, and I'm a little bit surprised that this idea create some trouble ! (I would have understood if we'd requested a private QAers-only mailing list, but for this request, really, I don't understand why it's argued ! ) Anyone interested could subscribe to this one as well, that's not harder than adding [QA] to QA related threads on koha-devel. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul, Everybody says +1 to your counter-proposal, but we already have a
koha-translate mailing list, dedicated to translation questions. And a koha-zebra one that is almost unused, but exist.
I am of the opinion we should close the koha-zebra list, at least. It just means more mailing lists that we have to keep track of, and I think lots of people don't bother subscribing to extra Koha mailing lists (including myself), meaning that people who know the answer and would be happy to help likely aren't seeing those questions. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi all, I think so far we have a lot of votes for keeping the discussion on the Koha developer mailing list so it looks to me like this is what we should do. Also a +1 from me. I think Mirko made a good point that it is interesting for all developers to know how the QA team works. On another note - maybe it's time to clean up our scattered mailing lists a bit? I didn't even know koha-zebra existed and I might not be alone in that. If it's mostly people asking for installation help there, it's maybe worth to fold back into the main Koha mailing list as more people helping out are subscribed there. Katrin -----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Jared Camins-Esakov Gesendet: Mi 24.10.2012 16:42 An: Paul Poulain Cc: Koha Devel Betreff: Re: [Koha-devel] Some thoughts from QA team Paul, Everybody says +1 to your counter-proposal, but we already have a
koha-translate mailing list, dedicated to translation questions. And a koha-zebra one that is almost unused, but exist.
I am of the opinion we should close the koha-zebra list, at least. It just means more mailing lists that we have to keep track of, and I think lots of people don't bother subscribing to extra Koha mailing lists (including myself), meaning that people who know the answer and would be happy to help likely aren't seeing those questions. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi all, I agree with Katrin in both points. Marc V. Am 24.10.2012 16:53, schrieb Fischer, Katrin:
Hi all,
I think so far we have a lot of votes for keeping the discussion on the Koha developer mailing list so it looks to me like this is what we should do. Also a +1 from me. I think Mirko made a good point that it is interesting for all developers to know how the QA team works.
On another note - maybe it's time to clean up our scattered mailing lists a bit? I didn't even know koha-zebra existed and I might not be alone in that. If it's mostly people asking for installation help there, it's maybe worth to fold back into the main Koha mailing list as more people helping out are subscribed there.
Katrin
I agree with Marc V. agreeing with Katrin. :) Ian On Oct 24, 2012 11:11 AM, "Marc Véron" <veron@veron.ch> wrote:
Hi all,
I agree with Katrin in both points.
Marc V.
Am 24.10.2012 16:53, schrieb Fischer, Katrin:
Hi all,
I think so far we have a lot of votes for keeping the discussion on the Koha developer mailing list so it looks to me like this is what we should do. Also a +1 from me. I think Mirko made a good point that it is interesting for all developers to know how the QA team works.
On another note - maybe it's time to clean up our scattered mailing lists a bit? I didn't even know koha-zebra existed and I might not be alone in that. If it's mostly people asking for installation help there, it's maybe worth to fold back into the main Koha mailing list as more people helping out are subscribed there.
Katrin
______________________________**_________________ Koha-devel mailing list Koha-devel@lists.koha-**community.org<Koha-devel@lists.koha-community.org> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<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/ <http://bugs.koha-community.org/>
I'm agreeing with Brooke, who agrees with Marc V., who agrees with Katrin... *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software Headquarters: Santa Barbara, CA Office: Lawrence, KS Phone/Fax (888)900-8944 http://bywatersolutions.com ruth@bywatersolutions.com On Wed, Oct 24, 2012 at 5:08 PM, BWS Johnson <abesottedphoenix@yahoo.com>wrote:
Salvete!
I agree with Marc V. agreeing with Katrin. :)
Oh yeah, well I triple dog agree with you.
I think a separate list might slightly hinder a would be bug wrangler.
nofences++
Cheers, Brooke
_______________________________________________ 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/
Am 24.10.2012 16:53, schrieb Fischer, Katrin: Hi all,
I think so far we have a lot of votes for keeping the discussion on the Koha developer mailing list so it looks to me like this is what we should do. Also a +1 from me. I think Mirko made a good point that it is interesting for all developers to know how the QA team works.
On another note - maybe it's time to clean up our scattered mailing lists a bit? I didn't even know koha-zebra existed and I might not be alone in that. If it's mostly people asking for installation help there, it's maybe worth to fold back into the main Koha mailing list as more people helping out are subscribed there.
Katrin
+1 lets close the koha-zebra list
Hi, On Wed, Oct 24, 2012 at 10:34 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 24/10/2012 11:52, Chris Cormack a écrit : Everybody says +1 to your counter-proposal, but we already have a koha-translate mailing list, dedicated to translation questions. And a koha-zebra one that is almost unused, but exist.
The goal is just to separate different things in different mailing lists. Not a big deal, and I'm a little bit surprised that this idea create some trouble ! (I would have understood if we'd requested a private QAers-only mailing list, but for this request, really, I don't understand why it's argued ! )
IMO, the difference is that QA is very closely tied to development as a whole, and I would be sorry to see QA concerns separated into their own list. Anything that touches code, including testing, should be discussed on koha-devel, and we should continue our trend of involving *everybody* in QA. Translations are a little different, as except for scheduling, translators can mostly do their own thing without having to closely interact with code contributors. I agree that koha-zebra ought to be closed and discussions about Zebra directed to the general or development list. Regards, Galen -- Galen Charlton Director of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Le 24/10/2012 11:47, Paul Poulain a écrit : As I've suggested last week, I tried to think of updating the priority flag to use it for "complexity" :
* Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing.
The problem is that, on lists, this flag is reduced to 7 characters. That's small... I see 2 options: * find a very short description for the 5 complexity proposed. I tried, but could not. If someone else has an idea ? * create a new custom field "Complexity", with those 5 values. I've checked, and, in lists, custom fields are not truncated, so we could have: - 1-Triv TT/doc - 2-Triv Perl - 3-Small patch - 4-Medium patch - 5-Large patch Does somone have another idea ? I do this one ? -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
On 2012-11-3, at 1:54 AM, Paul Poulain wrote:
Le 24/10/2012 11:47, Paul Poulain a écrit :
As I've suggested last week, I tried to think of updating the priority flag to use it for "complexity" :
* Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing.
The problem is that, on lists, this flag is reduced to 7 characters. That's small... I see 2 options: * find a very short description for the 5 complexity proposed. I tried, but could not. If someone else has an idea ? * create a new custom field "Complexity", with those 5 values. I've checked, and, in lists, custom fields are not truncated, so we could have: - 1-Triv TT/doc - 2-Triv Perl - 3-Small patch - 4-Medium patch - 5-Large patch
Does somone have another idea ? I do this one ?
hmmm, 7 chars is too small for easy descriptions 2 other ideas... 1/ change the code in bugzilla to not truncate the priority string to 7 chars 2/ increase the priority dropbox-list width from 80px to 160px (i think 2/ may not work)
Paul, As I've suggested last week, I tried to think of updating the priority
flag to use it for "complexity" :
* Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing.
The problem is that, on lists, this flag is reduced to 7 characters. That's small... I see 2 options: * find a very short description for the 5 complexity proposed. I tried, but could not. If someone else has an idea ? * create a new custom field "Complexity", with those 5 values. I've checked, and, in lists, custom fields are not truncated, so we could have: - 1-Triv TT/doc - 2-Triv Perl - 3-Small patch - 4-Medium patch - 5-Large patch
Does somone have another idea ? I do this one ?
What about: 1-string patch 2-trivial patch 3-small patch 4-medium patch 5-large patch If the problem is just lists, this is an issue for those people who look at a lot of lists: RM, QAers, and Signers off. People in those categories can learn to understand "1-strin," "2-trivi," "3-small," "4-mediu," and "5-large." Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
If we need a field for Complexity, we should perhaps not misuse priority IMO. We could probably simplify Priority to Low (most cases) and High. But we should define when to use High (not to confuse with Severity values like Blocker and Critical). Or just one value (say Normal) and make no use of it. My suggestions for Complexity would be: Textual changes only (comments, readme, pod, etc.); Template only (moving template vars around etc.); Few scripts only; More scripts (no modules); Minor Module changes; Major Module changes. (So: 6 values) Actually, I would have a Text, Script and Module value with a Minor and Major variant, allowing to make a difference between a patch that changes 3 lines in one module and another patch changing 250 lines in 7 modules, etc. Marcel Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Jared Camins-Esakov Verzonden: vrijdag 2 november 2012 22:18 Aan: Paul Poulain CC: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Updating priorities Paul, As I've suggested last week, I tried to think of updating the priority flag to use it for "complexity" :
* Change the priority flag use on bugzilla. Currently, this flag is not really used by anyone. We would like to change it's content to the following values, to reflect the complexity of a patch: 1- trivial patch template/doc only 2- trivial patch - minor Perl code 3- low risk of side-effect 4- medium risk of side effect, but don't underestimate it 5- High risk of side effect, be very careful ! We would also add a wiki page explaining how to choose the value. The value can be set by anyone (patch submitter, sign-offer, QA team, RM), and will just be a helper when someone want to pick up a patch for testing or QAing.
The problem is that, on lists, this flag is reduced to 7 characters. That's small... I see 2 options: * find a very short description for the 5 complexity proposed. I tried, but could not. If someone else has an idea ? * create a new custom field "Complexity", with those 5 values. I've checked, and, in lists, custom fields are not truncated, so we could have: - 1-Triv TT/doc - 2-Triv Perl - 3-Small patch - 4-Medium patch - 5-Large patch Does somone have another idea ? I do this one ? What about: 1-string patch 2-trivial patch 3-small patch 4-medium patch 5-large patch If the problem is just lists, this is an issue for those people who look at a lot of lists: RM, QAers, and Signers off. People in those categories can learn to understand "1-strin," "2-trivi," "3-small," "4-mediu," and "5-large." Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com<mailto:jcamins@cpbibliography.com> (web) http://www.cpbibliography.com/
participants (16)
-
BWS Johnson -
Chris Cormack -
Chris Nighswonger -
Fischer, Katrin -
Galen Charlton -
Ian Walls -
Jared Camins-Esakov -
Magnus Enger -
Marc Véron -
Marcel de Rooy -
Mark Tompsett -
Mason James -
Mirko -
Owen Leonard -
Paul Poulain -
Ruth Bavousett