Thanks for tackling this, Andre!
I don't think 'importance' should necessarily map to a timeframe for resolution - at least not one that is set in stone. Different teams/products use bugzilla to varying degrees and in different ways, and a reasonable time frame resolving a 'high' priority bug may be different depending on the specific component. Additionally, a bug's 'importance' in bugzilla may not directly map to other priorities they have (managed elsewhere), and it's up to each team/maintainer/etc to figure out how to prioritize bugzilla bugs relativel to everything else on their plates.
That said, I think it makes a LOT of sense to have a shared understanding of what things like 'importrance' in bugzilla actually means. It might be more useful to come up with a rubric of meanings for the different priorities instead of time constraints (or at least instead of thinking of bugs in terms of 'this should be resolved within the week') - eg:
* Highest = a mission-critical component is broken in such a way as to make the component completely unable to fulfill its purpose (eg credit card processing is broken in DonationInterface), or is a serious security or privacy vulnerability, or otherwise immediately threatens the health of the cluster * High = a mission-critical component is broken in such a way that does not prevent the component from totally fulfilling its purpose but greatly impedes its functioning/utility, or an issue that might not immediately threaten the health of the cluster but has potential to cause major problems if left unattended to (eg a performance issue that isn't causing problems now but will start causing problems a month from now) * Normal = an issue that does not affect a mission-critical component in such a way to to prevent it from fulfilling its purpose, but has a significant negative impact on users that may be addressable with a workaround * Low = an issue that does not affect a mission-critical component in such a way as to prevent it from fulfilling its purpose, is has low impact on users, and may be addressable with a simple workaround * Lowest = an issue that does not affect a mission-critical component in such a way as to prevent it from fulfilling it purpose, has minimal impact on users, addressable with trivial workaround or can otherwise be easily ignored
I'm not suggesting we necessarily go with these definitions, but rather offering these as an example of potential meanings for the different priorities. To me this is a much more useful approach than trying to define importance using timeframes, as timeframes are going to be (and should be) totally dependent on the responsible teams/maintainers/etc to figure out.
Thanks again for working to get bugzilla on track - I look forward to the bright future of our bug tracking system :)
On Mon, Nov 26, 2012 at 1:29 PM, James Forrester jforrester@wikimedia.orgwrote:
On 26 November 2012 10:51, Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2012-11-20 at 02:33 +0100, Andre Klapper wrote:
== Proposal ==
Proposing the following definitions for Priority:
- highest: Needs to be fixed as soon as possible, a week at the most. A human assignee should be set in the "Assigned to" field.
- high: Should be fixed within the next four weeks.
Any other opinions, especially by project/product managers? Or does silence mean "I don't really care, go ahead"?
For VisualEditor, this is pretty much how I use it *when in conjunction with a release window* - i.e. "Highest" and "2012-11-26" meant that it was one of the top priority things for the milestone that went out on the deploy train this morning, so it would have been worked on and hopefully closed within that two-week period (of course, some things take longer).
However, I'd also expect "High"-tagged bugs to get fixed in that two week period; I suppose that the one week / four weeks split it about right, but I worry about "Highest"-tagged bugs for work that doesn't need to land for months. Just because it's not urgent doesn't mean it's not important. The problem is that our "priority" field refers mostly to the second and a little to the first, and our "Severity" refers mostly to the first, but partially to release management work ("Blocker" is not a statement of severity of the problem, but a prioritisation flag about whether we can release the code; "Enhancement" similarly is not about severity but about work priority).
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l