Robla has has asked me to put together a page documenting how I plan to use Bugzilla. For now, I've decided to mostly use the “Priority” field (since it is largely unused) and write up my understanding of the current usage of how “Severity” is used.
You can see the result at http://www.mediawiki.org/wiki/Bugmeister/Bugzilla and I welcome your comments.
Mark.
On 18/02/11 21:15, Mark A. Hershberger wrote:
Robla has has asked me to put together a page documenting how I plan to use Bugzilla. For now, I've decided to mostly use the “Priority” field (since it is largely unused) and write up my understanding of the current usage of how “Severity” is used.
You can see the result at http://www.mediawiki.org/wiki/Bugmeister/Bugzilla and I welcome your comments.
Great! Finally someone taking the time to document the evil priority & severity couple. This has always been a nightmare to explain properly and to get people to understand the concept behind. My comments about the fields:
== priority ==
The meanings you have associated to the priority field, is actually the urgency or the importance of a bug. Ie how long until it will have an impact on our "business".
This field should only be changeable after an agreement between two positions: 1) product owner, which represents stackholder assets / customer needs / future business development 2) software maintainer, which does the work (or make it mades)
In our terms, and as I understand it, it would translates to: - product owner role is assumed by the product managers representing the community willings, CTO & board vision ... - software maintainer role is assumed by the release manager (Roan / Tim ?). The bugmeister position could be the one in between the two roles and setting the priority accordingly. Each level of priorities would need different review frequencies which you described properly.
My recommendation: lock the priority field to a handful of people excluding the end users and developers.
== severity ==
I do not like the proposed severity meanings. They should be described as the effect/impact on the software. A proposition would be:
blocker: prevents development work critical: affecting the whole software (crash, data lost...) major: making only part of the software unusable, regressions, make a functionality totally unusable. normal: default minor: not important functionality change, workaround exist trivial: nice to have, comments issues, cosmetic, typos .. enhancement: feature request
The bugs we want on the WMF sites should be made more important regardless of the severity. In your proposition, we could have a lot of bug marked major even if they are just a typo ;o)
My recommendation: make sure to have the severity descriptions easily accessible from the bugzilla interface. Make sure every bug reporter and developers understand what they mean.
Please note you are starting a hard task, with lot of possible ways to solve it :-)
Ashar Voultoiz wrote:
The bugmeister position could be the one in between the two roles and setting the priority accordingly. Each level of priorities would need different review frequencies which you described properly.
My recommendation: lock the priority field to a handful of people excluding the end users and developers.
Locking the field would deter gnome-labour on bugzilla. I wouldn't lock it more than the equivalent of an autoconfirmed level. Although given that it is defined as how often the Bugmeister will look at the bug, I don't think other people would be interested on it or even find it useful.
== severity ==
I do not like the proposed severity meanings. They should be described as the effect/impact on the software. A proposition would be:
blocker: prevents development work critical: affecting the whole software (crash, data lost...) major: making only part of the software unusable, regressions, make a functionality totally unusable. normal: default minor: not important functionality change, workaround exist trivial: nice to have, comments issues, cosmetic, typos .. enhancement: feature request
I would usually call a crash or data lost a blocker (although it could be downgraded if they affect just one piece -like the installer- or happens only once in a blue moon).
wikitech-l@lists.wikimedia.org