launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Francis and I chatted on irc; he said he likes this \o/, with the
assignment to buckets stuff clarified a little. So heres that one
section reworded. I'm still very interested in input from everyone
here - is this sane, insane, confusing, clear, ...

== Triage guidelines ==

These guidelines describe the rules we use to sort bugs - and from
that sort we assign bugs to bugs. We broadly want:
 * queue jumping bugs to be in the critical bucket. (OOPS, timeouts,
regressions, stakeholder-escalated bugs are all examples of queue
jumping bugs)
 * the high bucket to be about 6 months deep - many parts of Canonical
are on a 6-month cycle and fitting in with that is convenient

The quarterly review is responsible for shrinking the high bucket if
its too full.

What we need to do then in assessing the bucket for a bug is to do
*enough* sorting on it to see if its a queue jumper, of its its more
important than the least important bug currently in the high bucket.
Beyond that, all bugs are in the low bucket.

If a bug is a regression : if the thing *was* working and now isn't,
we sort it higher. We're currently discussing having a policy that
regressions are critical, which if implemented will make these queue
jumpers (critical bucket).

If the bug is one that has been escalated via the Launchpad
stakeholder process, it is a queue jumper (critical bucket).

OOPS and timeout bugs also jump the queue: performance is very important
to our stakeholders and OOPS dramatically affect our ability to
operate and maintain Launchpad as well as being a very negative
experience when encountered. The ZeroOopsPolicy contains details on this.

For things like browser support, when a new browser is released but
the vendor is in our supported-browser-set, we should treat issues as
regressions and so they will be queue jumpers.

Beyond these rules a bug is more important than another bug if fixing
it will make Launchpad more better than fixing the other bug.
Discretion and a feel for whats in the bug database will help a lot
here, as will awareness of our userbase and their needs. One sensible
heuristic is to look at 5-10 existing high bugs, and if the new bug is
less important than all of them, mark it low (its probably less
important than all existing high bugs).

Engineers have discretion to decide any particular bug should be
sorted higher (or lower) than it has been; some change requests are
very important to many of our users while still not big enough to need a
dedicated feature-squad working on them (so these bugs may be high).
When two engineers disagree,
or if someone in the management chain disagrees, common sense and
courtesy should be used in resolving the disagreement.

== How to triage ==

Visit https://bugs.launchpad.net/launchpad-project/+bugs?field.importance=Unknown

For each bug:
 * See if there are any duplicates by having a bit of a look around,
search your memory etc.
 * If the bug is unrelated to Launchpad, move it somewhere appropriate.
 * If the bug is something we won't do at all, mark it as won't fix.
 * If its a operational request, convert it to a question.
 * apply the guidelines in 'Triage Guidelines' to get a bucket for the
bug and set the bug importance to that bucket.
 * If the bug status is 'Incomplete', check that the filer was asked
to clarify something; if they were and haven't replied in a month,
close the bug. Otherwise either ask them to clarify something, or set
the bug to Triaged.
 * If the bug status is New, set it to triaged.