803625 - Implement a way of tracking and triaging bugs

Status: RESOLVED FIXED

(L20n :: General, defect)

Description

[Staś Małolepszy :stas]

Should we use bug dependencies and tracking bugs?  Target milestones?  Custom tracking flags like blocking-next[?-+]?

How should we use priorities?

Comment 1

[Staś Małolepszy :stas]

Here's what I propose:

Bigger chunks of functionality can have tracking bugs, blocked by smaller items of work.  Neither should be version-specific.  I filed "[tracking] Compiler 1.0" (bug 802843) a few days ago, but that's an example of what we shouldn't do.  Instead, I should have filed those bugs flat and set Target Milestone to 1.0.

OTOH, if we were to implement a "Better debugging info" feature, we would perhaps file a tracking bug.   Some of its dependencies would have Target Milestone set to 1.0.  Other would not.

Planning what goes into a particular release should be done via the Target Milestone flag.  We'll keep 1.0 around because it's a major milestone, but then, I suggest having 'next' and 'future'.  Keep it simple.

No custom tracking flags.  We'd need them if we had tens and hundreds of bugs filed daily, and we needed to nominate bugs for a blocking status.  For now, having weekly triage sessions for all open bugs should be enough.

P1 - a milestone cannot be released with open P1's targeting it.
P2 - should be done before the milestone is released
P3 - nice to have, but the milestone can be released without it.
P4-P5 - not used.

Comment 2

[Staś Małolepszy :stas]

Here's another proposal of interpretation of priorities (as used by the devtools team):

P1 - all other work stops, all team focuses on it, our product is broken;

P2 - this is important enough that we cannot *not have* someone assigned to it and work on it; it might be a new feature or a buga lot of users affected by a bug;  blocks someone else's work

P3 - we recognize this needs to be done, but we won't work on it until all P2s are assigned; "I'm not sure exactly what I should be working on right now, so I'll take assign one of P3s to myself and start hacking on it"

P4 - this would be nice to have, but is not crucial and doesn't block us;  usually, a good-first-bug that we can afford leaving open for a newcomer to pick up.

P5 - not used.

I like this much better than the description from comment 1, mostly because it isn't tied to specific milestones.

Comment 3

[Staś Małolepszy :stas]

(In reply to Staś Małolepszy :stas from comment #2)

> P2 - this is important enough that we cannot *not have* someone assigned to
> it and work on it; it might be a new feature or a buga lot of users affected
> by a bug;  blocks someone else's work

Sorry, I was typing this too quickly.  "or a bug a lot of users are affected by;  also, a bug that blocks someone else's work"

Comment 4

[Staś Małolepszy :stas]

Gandalf, Jeff and I talked about this today in the l20n weekly call.  We agreed on the semantics proposed in comment 2 and we fell that the interpretation of priorities from comment 2 suits us well.

I summarized the current approach on the wiki: https://wiki.mozilla.org/L20n/Tracking

One thing that we'd like to revisit after 1.0 is how we track bugs targeting the next release.  If we start seeing more people involved, it might make sense to use a custom tracking flag with 3 states (+-?) instead of the Target Milestone field.