launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

I don't have a fixed viewpoint here either; I have a few things that I
think we need to achieve (which the triage document does mention) -
but its worth having a specific discussion on them I think...

 - it should be trivial to figure out which bug is best to pop off the
queue and work on (common case workflow)
 - bugs that are being worked on right now should be visually distinct
(e.g. in progress means *In Progress* not *queued for fred*).
 - we should not put more effort into bucketisation than actually is
needed to look after ~ 6 months worth of work
 - we should be able to tell users sensibly where our most important
bugs are and how deep the queue is
 - we should be able to say 'bug X now' regardless of where bug X is
in the system - and see that that has been done in the bug tracker

If we meet all these goals, I'll be happy. I don't fundamentally care
whether the bug of (oops/regression/timeout) is labelled critical or
high. I don't believe that having a bucket above that bucket makes
*any* difference to what we do, or that it affects the goals above:
because *if* something is a crisis its not going to go into *any*
bucket, its going to get an engineer interrupted, whatever they are
doing dropped, and the crisis put into their plate.

Thats *not* the normal workflow and so putting it in a bucket of its
own makes no difference: the buckets are used solely for:
 - informing users (and an operational problem showing as critical is
fine from that angle)
 - the common case workflow of choosing a new bug *after* finishing
previous work (and having oops/regression/timeout as 'critical' works
fine from that perspective too).

So the reason I proposed critical for the oops/regression/timeout bucket is:
 - thats what I think of them as - critical problems
 - its what our users think of them as
 - and it works within the constraints AFAICT

-Rob