BMO/Workflow Proposal

Bugzilla 4.0 ships with a new default set of statuses and status workflow. This is a proposal that Mozilla adopts it, with one addition (a READY_TO_FIX state).

New Upstream Workflow

BMO uses the status workflow which shipped with the original Bugzilla, back in 1998. We recently upgraded to Bugzilla 4.0, which by default comes with a new default set of statuses and status workflow, which were chosen taking into account on the last 12 years of experience in Bugzillas around the world. The Bugzilla development team have published various explanations for why they changed the workflow. Here's a summary of the changes:

This proposal recommends adopting this change because the new workflow is better than the old. The two removed statuses will not be missed much (we no longer use CLOSED anyway). The new names for the other two better reflect what is going on - there are many NEW bugs which are very old, and it would be advantageous for it to be clear, and true in practice, for there to be a state which said unambiguously "I am working on this bug".

Also, even if the changes were neutral, it is advantageous to be doing the same thing as upstream Bugzilla.

Bugzilla only supports a single workflow across the entire installation, so we would need to make a project-wide change. (Exception: UNCONFIRMED can be enabled or disabled on a per-product basis.)

Note: this discussion is _not_ about resolutions (FIXED, DUPLICATE, WORKSFORME etc.). Those can also be changed, but independently. Let's have one discussion at a time.

READY_TO_FIX State

However, there is one additional change we can consider at the same time. The idea of having a READY or READY_TO_FIX state in bugzilla.mozilla.org goes back 6 years, with some proposals from mconnor {graphic) and fantasai. We tried to make this change 2 years ago but the effort stalled.

In the new workflow discussion bug upstream, Max Kanat-Alexander (a lead Bugzilla developer) said that a READY_TO_FIX state to go between CONFIRMED and IN_PROGRESS makes sense only for bigger Bugzillas (which we are). This is why it's not part of the default set.

This proposal suggests that we also add this state, for the reasons given in the above proposals. To summarise: it provides a clear delineation between "bugs which are QA's problem" (CONFIRMED or RESOLVED) and "bugs which are dev's problem" (READY_TO_FIX or IN_PROGRESS), with the latter distinction showing clearly what dev is working on and what they aren't. Without this change, a CONFIRMED bug could be on QA's plate or dev's plate - the status doesn't tell us.

How We'd Convert

The exact algorithm, as implemented by the conversion script shipped with Bugzilla, would be:

• "NEW" will become "CONFIRMED"
• "ASSIGNED" will become "IN_PROGRESS"
• "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be removed)
• "CLOSED" will become "VERIFIED" (and the "CLOSED" status will be removed)

The history of each bug will also be changed so that it appears that these statuses were always in existence. Bugmail will not be sent regarding this change.

If we adopt the READY_TO_FIX proposal, then initially no bugs would be in the READY_TO_FIX state.

Technical notes: once we made the change, we would need to:

• run ./collectstats.pl --regenerate to regenerate old chart data
• do "reset to default" on the mybugstemplate parameter to update it to use the new statuses

Compatibility

Existing saved searches and New Chart queries would be transparently updated to use the new names.

For old charts, see above.

We would write a patch to provide some support for the old names on search URLs, when explicitly named in the "status" field, so that bookmarks and external tools might continue to work even after the migration.