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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
