[Wikitech-l] Standardizing highest priority in Bugzilla

[Andre Klapper]

== Situation ==

In Wikimedia Bugzilla you can set a priority for a bug report.
Some people and teams set highest priority often (meaning "These issues
should get fixed first in the next weeks").
Some don't set it at all (and likely related: Some teams don't really
use Bugzilla but other tools).
Some are in-between.
This use might work well for each team.

* Currently there are 15 open tickets with highest priority:
 https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=---&order=product%2Ccomponent
 (You might only see 14 if you don't have access to security bugs)
* 5 of them have highest priority for more than 30 days:
 https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=---&chfieldto=-30d&query_format=advanced&chfield=priority&chfieldvalue=Highest
* 2 of them for more than 90 days (Huggle vs IPv6; moving to EQIAD):
 https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=---&chfieldto=-90d&query_format=advanced&chfield=priority&chfieldvalue=Highest
The latter imply either missing maintainership (Huggle?) or tasks that
take longer (EQIAD) and could be broken down into subtasks.

== Problem ==

Currently "Highest Priority" has no single (cross-team) meaning.
This makes it hard for people outside of a team (e.g. Engineering
Management) to see at a glance what's most important and urgent for each
team.

== 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.


andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/