launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #08683
fallout and regressions are the new black
I propose we reorganise our priorities based on Francis' statement in
http://blog.launchpad.net/general/legacy-performance-testing-6-months-of-new-critical-bugs-analyzed
that fallout and regressions are the true critical issues.
At the start of the year we raised the importance of all oopses and
timeouts to critical. We told maintenance teams that they could work on
any critical bug they choose. It was assumed that all tags were equal
and that the queue could be driven to zero in 3-6 months. Maintenance
teams continue to select bugs to fix based on these rules, though we
know the predicated assumption is false.
I think we have a simpler set of rules based on Francis posting that
helps us to prioritise work. Fallout and regression bugs are criticals
because we recently made something worse for users. These bug queue must
be kept at zero.
Where there are no critical bugs, the teams may return to working high
bugs. For maintenance teams, these are the oops and timeout bugs. For
feature teams, these are the high bugs.
There are also a few other bug tags we recognise as critical. Broken
builds and bugs that block other cards on the kanban board. We currently
treat escalated bugs as critical because they need to jump the oops and
timeout bugs, but if/when those queues cease to exist, escalated bugs
would just be high.
The rules for setting importance based on tags and the team that is
driving the queue to zero look like this:
Feature team Maintenance team
|
CRITICAL
fallout | escalated
regression | regression
blocker | blocker
|
HIGH
<feature-tag> | oops
| timeout
I believe this continues to treat oopses and timeouts are work that must
be driven to zero before addressing tech-debt and user improvements.
--
Curtis Hovey
http://launchpad.net/~sinzui
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups