== 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=…
(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=…
* 2 of them for more than 90 days (Huggle vs IPv6; moving to EQIAD):
https://bugzilla.wikimedia.org/buglist.cgi?priority=Highest&resolution=…
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/