OpenJDK bug database: DRAFT Developer Workflow

[Brian Goetz]

>> Completely agree. I don't see any value in the various "sub states"
>> and I think you captured well the reason.
>
> Do we have to chose one or the other?  I have used systems that had
> both a high level state (New, Open, Closed) and substates useful to
> one or more groups to keep track of where the bug is 'right now' or
> giving more information (for instance -- Closed:Fixed vs
> Closed:Verified vs Closed:Will not fix).    I agree completely that
> some of the current status terms are misleading or confusing at best
> (accepted being perhaps the worst offender).  As such we should take
> care in choosing names and perhaps most importantly have clear links
> to help text describing what each of these is supposed to mean.

A good JIRA rule is: don't design a workflow where any query that anyone 
ever has to do regularly as part of their job includes examining 
substates.

If we want to use substates as a form of enumerated documentation 
options, that's fine; Closed:Verified vs Close:WillNotFix is a good 
example, since the most common consumer will be a human looking at the 
summary page to learn the disposition.  But if our processes need to 
distinguish between Open:FixUnderstood and Open:IHaveNoFrigginIdea, 
we're creating the sort of problem that tends to lead to the creation of 
boundary systems.