launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

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