I like this too. Here is the what I understand to be the short form of it:
* only three buckets: critical (drop everything), high, and low * importance reflects priority (order we will do them), and only indirectly severity (user impact) * priority is determined by: user impact, impact on project health, impact on key stakeholders, general judgement... * oopses and timeouts are high * a regression of something that was previously working is more likely to be high than if the feature never worked at all * the high bugs are all of approximately equally importance: if we would find it disappointing if bug X was done before bug Y, X must be marked low * therefore squads in bugfix mode can take whatever high priority bug they see first or whatever they think is easiest * bugfix squads should basically never do low-priority unless they are genuinely trivial to do as part of another fix * squads in feature mode can fix whatever bugs are relevant to their feature, but they can't mark their feature Done until there are no more relevant (tagged) high bugs * every developer has some discretionary time in which they can fix whatever will increase their happiness with the project, regardless of normal priority * the high bucket will be softly capped at about as many bugs as can be done in 6 months (ie 400-1000) * it is of course fine to move, or talk about moving, a bug up or down the scale One thing here that wasn't mentioned: confirmed vs triaged. I think this would be a great opportunity to start using just one of those statuses. (But perhaps that's a separate issue.) -- Martin _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
