launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Thu, 2011-01-06 at 17:41 +1300, Robert Collins wrote:
> 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

How deep is the High queue? We close about 540 high and critical bugs in
6 months, but we current have 801 high and critical bugs. Most of those
bugs were reported and closed in 30 days. I think this means the High
queue should be between 450 and 540 bugs. We have more than a 9-month
backlog.

10% of closed High are older than 90 days. We are going to close about
54 bugs High bugs that are before October of last year in the next 6
months. I ask again. Are old bugs bugs that marked High really High?

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

^ We are do for a quarterly review thrice over.

...

> == 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.

Please do not set any bug to triaged unless it also has an importance
set.

I tend to mark bugs relating to a feature in development as High, but
when I discover that we are not willing to fit the issue to a milestone
after a month or two, I downgrade it.

I mark feature requests/enhancements as low.

I am conflicted about trivial bugs (bugs that can be fixed in 1 or 2
hours or work). Most do not prevent someone from completing their task,
but these items that frustrate user as the bug ages. Maybe I should
never let users know the bug is easy to fix. While I rarely mark these
bugs high, once I see enough to consume a day, I arrange for them to be
fixed.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part