BMO/Workflow Proposal 2

This is a proposal that bugzilla.mozilla.org switch to a workflow model which focusses on the next thing to happen rather than the thing which has just happened.

Background

Since the very beginning of Bugzilla, it has had a Status field, which is supposed to tell you what the current state of the bug is. There have been various modifications to the available statuses, and Bugzilla 4.0 shipped with a modified set. However, they have been criticised both as being too general ("the bug is NEW - what does that tell me?") and as focussing too much on the past.

The Big Idea

Knowing what just happened on a bug is not all that useful. What observers and potential helpers really want to know is: what needs to happen next? How can this bug be moved forward? This enables meaningful participation - people can search for bugs which require the skill they have, or try and find someone which has it. It makes it much less likely that bugs will fall through the cracks as each person expects someone else to take action. It's much more obvious whether a bug is in the realm of QA, dev, UX, security or is actually in limbo.

It would be possible to agree with this idea but disagree with my particular proposal to implement it. Please make it clear when you comment whether you object to the principle or the proposal.

Proposal

I suggest we rename (in the UI) the Status field as "Next Action", and the "Assignee" field as "Next Action Owner".

The Next Action field would have the following values:

Open States

(These states have no associated resolution.)

• TRIAGE - the bug requires triage to see if it really is a bug, and whether it is in the correct product and component.
• TESTCASE - the bug requires a reduced testcase to be written which shows it off.
• DIAGNOSE - the bug is confirmed as a real bug, but requires someone to investigate the cause.
• DESIGN - the problem has been identified, and work is required to design a solution. This code be code design, UI design or something else.
• FIX - the path is clear, and someone needs to fix the bug or implement the feature.
• REVIEW - some particular person needs to review either an artifact (such as a patch) for some reason (code review, design review, accessibility review) or a approve a decision
• APPROVE - the change has been reviewed, but (perhaps due to the tree it is destined for) this bug requires approval.
• CHECKIN - the change has had all necessary reviews and approvals, and now needs to be checked in.
• VERIFY - the change has been checked in, and someone needs to check it has worked.

Bugs with Next Action as TRIAGE, TESTCASE, DIAGNOSE and VERIFY would be the responsibility of QA; the others would be the responsibility of Dev. When QA was initially finished with a bug, they would set the next action to FIX. (Dev might later decide some DESIGN was necessary first.) Once Dev has fixed a bug, they set it to VERIFY. Once QA has verified, they set it to --NONE--.

Closed States

(These states have an associated resolution.)

• --NONE-- - no further action is required on this bug - see the Resolution to find out why. (That could be FIXED, INVALID or whatever as now.)

Clearly, there are a great many other candidates for values - e.g. more specific ones like "STACK", "BISECT" or "VALGRIND". But the number of values cannot be too large, otherwise people will get choice paralysis. I hope the above covers everything at a high level.

Some other things you might want to say would be covered by the Resolution field - "SUPPORT", "WRITE_AN_EXTENSION", etc.

Migration

Migrating from the current system to the above one is tricky, because it requires some guesswork as to what the next action is! Here is a straw man proposal:

• UNCONFIRMED -> TRIAGE
• NEW -> DIAGNOSE
• ASSIGNED -> FIX
• REOPENED -> FIX
• RESOLVED -> VERIFY
• VERIFIED -> --NONE--

In all cases, the assignee would not change.

Incoming bugs which are now UNCONFIRMED would come in instead as TRIAGE, and those which are now NEW would come in as DIAGNOSE.

Possible Issues

From the discussion in 2009, bz raised the following issues:

• What if there are multiple things that have to happen next (e.g. reviews)? (How common is this?)
• If bugs are reassigned when they are to be reviewed, the person requesting review loses track of them, and therefore is less likely to go and hassle the reviewer.

References

Most of this is shamelessly stolen from Getting Bugs Done by Jesse Ruderman.