On Wed, 2015-04-01 at 09:31 -0700, Pine W wrote:
it seems to me that "unbreak now" bugs
should be fixed in something like
10 days max. If something is seriously broken, 48 days is long time to
wait for a fix.
Note that the value does not express how long a task has had this
priority, but how long a task which currently has this priority set has
been open. For example, T1090 has been open since Nov 2014 but has
"Unbreak now" priority only since March 2015.
On Wed, 2015-04-01 at 20:40 -0300, Brian Wolff wrote:
Or perhaps we need better definitions of what unbreak
now means. Wasn't the
original definition supposed to be for major outages? The type of thing
where 48 hours was the very outside limit on acceptability? E.g. bugs of
the form "25% of users can't edit".
The task priorities are defined here:
The list of open or stalled tasks with "Unbreak now" priority:
Some of these tasks likely don't match the definition of "Unbreak now".
It is welcome to ask about the progress of tasks which have had "Unbreak
now" priority set for a while and point to the priority definitions.
Generally speaking, some teams/developers are better and some are worse
setting realistic expectations via priorities.
The absolute numbers of open tasks per priority and project
(distribution of priorities in each project) can be seen here:
In my opinion, low and lowest priority should be used way more often.
Andre Klapper | Wikimedia Bugwrangler