Custom workflow (almost) implemented

[Gervase Markham]

A key point before I start: I believe it's an extremely important 
principle of the custom workflow design that, aside from being 
designated as "open" or "closed" (note: I am making a distinction 
between "closed" and CLOSED; the former is a class of statuses, the 
latter a particular status in that class), there should be no "special" 
states. That is, there should be no code in Bugzilla which references 
particular states by name.

Frédéric Buclin wrote:
> I have (almost) implemented custom workflow in Bugzilla 3.1. I still 
> have a few lines of code to fix, but it's mostly working. One thing I 
> have to think about is what to do with this UNCONFIRMED/REOPENED 
> behavior when reopening a closed bug ('closed' as in 
> RESOLVED/VERIFIED/CLOSED).

My proposal: we do not make the state of reopened bugs dependent on 
their previous opened state. In other words, we abandon the 
"everconfirmed" flag.

In specific terms, using the workflow we have today, that would mean 
that bugs would always go to REOPENED, and never to UNCONFIRMED.

I think this is the right thing to do for several reasons.

The first is that it preserves the principle I outline at the top, 
thereby simplifying both the implementation and the model in the user's 
mind of how custom workflow works.

It also makes good sense.  As it's now possible to change resolutions 
while a bug is closed, that means that if you are reopening a bug, it 
must be because you want someone to work on it some more - i.e. you have 
some information that it is a bug. So UNCONFIRMED is inappropriate.

Under the current workflow, there is no way to re-enter UNCONFIRMED, and 
so this feature has some possible uses. With a custom workflow, that no 
longer has to be the case. If people want to be able to take occasional 
bugs back to UNCONFIRMED based on the quality of the bug report, they 
can enable the REOPENED -> UNCONFIRMED transition. But this decision 
should be based on the information in the report, rather than the 
previous state.

It would be interesting to see how many bugs in b.m.o. were reopened and 
set back to UNCONFIRMED by the everconfirmed flag, only for the triager 
to have to go in and change it to NEW.

Gerv