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/