OpenJDK bug database: DRAFT Developer Workflow

[Georges Saab]

I don't think the sub-states matter to any processes used on a daily basis.

I do think they can add information (without requiring detailed reading of the bug comments) that can help 
find outliers that need attention.

For instance, if we have two sub-states for New (unqualified and qualified, the distinction being initial triage 
ensuring that the information in the bug report is sufficient to do something with it), we could have a desired 
SLA (service level agreement)  on the time to move between these.  If we are consistently failing to meet this 
in a particular area then it shows us we need more investment there (or we need to decide we can accept a 
less aggressive SLA).   This kind of query can easily be automated.  Maybe this is exactly the kind of boundary 
system you are worried about, though?

(yes, usual caveats about be careful what you measure and lets not get so excited about measuring things 
that we create a false economy or think that the measuring is more important than the work being measured).




On 31 dec 2011, at 10:16, Brian Goetz wrote:

>>> 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.