OpenJDK bug database: DRAFT Developer Workflow

[Iris Clark]

Hi!

> >> I really like what we currently have in terms of:
> >> - cause known (problem has been identified)
> >> - fix understood (a solution seems to have been devised)
> >> - fix in progress (actively implementing the solution)
> >>
> >> As an IE (and someone who watches many new bug reports) I will often 
> >> take a bug to "cause known" as part of my initial eval. Combining an 
> >> understanding of the problem with the discovery of a solution into 
> >> one state loses very important information in my opinion. For 
> >> example, a bug with an understood fix can be easily picked up by a new
> >> developer as a "starter" bug. I agree that when we remove statuses,
> >> information may be lost. 
> >
> > I had combined these two statuses because my impression was that they 
> > were not currently being used effectively.  What seems to happen in 
> > many cases is that once sufficient investigation has been done to 
> > identify the cause, the recommendation for a solution would be known as
> > well). 
> >
> > What experience do other people have with these statuses?
> 
> Looking over the 100+ open bugs where I'm the responsible engineer, I have
> about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood.
> 
> Should these three related conditions about an increasing understanding of the
> bug be covered in one state with three substates?

It's a possibility.  I want to step back to think about what exactly we need
to represent.  Let's start by think about what the various points of a bug's
life are and the points are of interest (and to who).  Here's my basic
understanding of what happens to a bug from the time it come in
(i.e. currently "Dispatched") to the time somebody is actively working on it
(i.e. "Fix in Progress").

Assume adjustments to bug content as appropriate for every step.

1.  Dispatched:  A bug comes in.  
2.  Accepted*:  Component teams do initial triage.  The goal is to verify that
    there's sufficient information to investigate the bug and determine
    importance of the reported problem assuming it is real.  An initial
    Priority, Cat/Subcat, and target release are verified/assigned as
    appropriate.
    NOTE:  There is no guarantee that the problem actually exists!
3.  The reported problem reproduced.  Priority, target release, etc. may be
    adjusted. 
4.  BT Cause Known/JIRA Understood:  Sufficient investigation preformed to
    gain a basic understanding of how the problem should be addressed.
    Evaluation updated. 
5.  BT Fix Understood/JIRA Understood:  A potential solution is devised.
    Impact and risks associated with the solution are known.  Suggested fix
    updated. 
6.  Fix in Progress:  Active work started to address the problem.

Did I miss anything?   [ Note that 3 does not have a name in either the
proposed JIRA workflow or BT.  Minimally, that needs to be addressed. ]

3-5 feel like they're very tightly related so are perhaps a single status with
sequenced substatuses?  (I don't know if JIRA supports the concept of "sequenced
substatuses", so these might need to be individual statuses.)

[ We'll need to visit the names after we decide what they should represent. ]

> >> I don't think "closed: future project" works very well. Once a bug is 
> >> closed it should remain closed in my view. Maybe a new substatus of 
> >> "accepted" could be "future project" to indicate deferral?
> 
> I believe the intention of "closed: future project" state is intended to more
> neatly address issues like a "Java should have a module system" bug, filed
> back in 1996.  Leaving these is a chronic accepted or cause known state for
> years obscures other issues

Does it feel like we have a lot of these kinds of bugs?  Would it make it
easier to close these and similar bugs if "Closed: Future Project" exists?

Thanks,
iris