OpenJDK bug database: DRAFT Developer Workflow

[David Holmes]

On 1/01/2012 4:16 AM, 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.

Then you need more primary states.

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

I think that is actually a good example of a bad situation. If I want 
bugs fixed in a given release or build I don't want to have to select 
all Closed bugs and then weed through them based on substates - as per 
your "good JIRA rule". I'd advocate two different final states (as 
opposed to our current system) that distinguishes between "closed and 
something was changed" versus "closed and nothing happened".

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

I don't know what problems you are alluding to but please don't under 
estimate the utility of the existing states to both dev and dev 
management. A bug system that only tracks existence is next to useless 
in my view for both dev and the external submitter.

As I have enumerated before there are numerous situations where the 
difference between:
- accept: "we agree this looks like an issue that needs investigation"
- cause known: "I know how this comes about and (hopefully) understand 
the potential implications"
- fix understood: "I think I know how to resolve this"
provide valuable information to both Dev and Dev mgmt. If you have a 
deadline looming and have six bugs that are "fix understood" then you 
have much greater confidence in your ability to meet the deadline than 
if you have six bugs merely "accepted". And if the bug system doesn't 
let you tell the difference then you have to assume the worse.

David
-----