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/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
