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's 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 Next Actions 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.
• MAKE_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.
• DECIDE - a general state which means that someone or some group has to make a decision for the bug to progress further.
• FIX - the problem definitely needs fixing, and someone needs to do some work towards that goal (design or coding).
• CHECK_IN - the change has had all necessary reviews and approvals, and now needs to be checked in.

Closed States

(These Next Actions have an associated resolution.)

• VERIFY - the change has been checked in, and someone needs to check it has worked. This probably makes most sense for FIXED, but occasionally for other resolutions.
• --NONE-- - no further action is required on this bug - see the Resolution to find out why.

Commentary

Bugs with Next Action as TRIAGE, MAKE_TESTCASE, DIAGNOSE and VERIFY would be the responsibility of QA, DECIDE can be either depending on the assignee, and FIX and CHECK_IN would be the responsibility of Dev. When QA was initially finished with a bug, they would set the next action to FIX. Once Dev has fixed a bug, they set it to VERIFY. Once QA has verified, they set it to --NONE--.

The names have been chosen to hopefully be general enough that groups which use Bugzilla for things other than software bugs (e.g. helpdesk tickets) can still use it, even if they wouldn't have a use for every state. MAKE_TESTCASE and CHECK_IN are fairly software-specific, but the rest are general.

Those without editbugs would file bugs into TRIAGE. Those with editbugs could also file a bug in MAKE_TESTCASE, DIAGNOSE, DECIDE or FIX.

Clearly, there are a great many other candidates for values - e.g. more specific ones like "GET_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.

Review and approval would continue to use flags, as now.

Once a bug has been fixed, it is often passed to QA for verification, and it would therefore be assigned to a QA person. In order to make it possible to search easily for "who fixed this bug" even after that point, we would have a custom field which is automatically populated with the username of the person who actually did the fix.

Next Action Owner

(This bit still needs comment.)

The bug may have several owners over the course of its life. We need to make it easy for people to assign the bug to the right person.

Bugzilla currently has the concept of "default owner" and "default QA contact". We should morph those (only slightly) into "default developer" and "default QA person". Then:

• If a bug is filed in a dev state, it gets assigned to the default developer. If it is filed in a QA state, it gets assigned to the default QA person.
• Whenever a bug transitions from a dev state to a QA state, it gets assigned to the last person to own it in a QA state, or the default QA person if it's never been in a QA state.
• Whenever a bug transitions from a QA state to a dev state, it gets assigned to the last person to own it in a dev state, or the default dev person if it's never been in a dev state.
• (Both of the above can, of course, be overridden by people making an explicit choice of assignee.)

The aim here is to DTRT with the assignee with minimal effort on the part of the person making the change to the bug.

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 -> TRIAGE (so we can see why it was reopened and move it on accordingly)
• RESOLVED -> VERIFY (if resolved in the last month), otherwise --NONE--
• 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.

Resolutions

The Resolution field then ends up as the thing which tells you why the Next Action is --NONE--, or to put it another way, why the judgement is that there is no further action to take on the bug. This proposal would work fine with our existing set of statuses - nothing is to be done because it's FIXED, because we WONT FIX it, because the bug is INVALID, because it's a DUPLICATE, and so on. There are several other suggestions for Resolutions we might want to add, but discussing that at the same time as this would just lead to a larger discussion as the two issues became confused. So let's not do that.

Possible Issues

• It's useful to know who fixed a bug when it's closed; if the Current Action Owner at the end is the QA guy who verified the bug, then that information is not immediately obvious.

References

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