== 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/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
