Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Iris Clark]

Hi, Peter.

> >                             As many have argued, the Evaluated status 
> > allows developers to organize their work by providing general 
> > information for queries and makes it possible for new developers to 
> > identify "starter" bugs.  For the non-developer, it provides a simple way
> > to interpret progress. 
>
> [ snip ]
>
> It only indicates progress according to a sequential model that just doesn't
> fit all (most) issues, and only when an individual/team choose to actually use
> this state (there's no external pressure to use it consistently).  If you're
> not in a context where you can trust the usage (e.g. if you're doing general
> process monitoring and release management), you've complicate things because
> you then have to combine Open and Evaluate to get an accurate picture of how
> well Development processes bugs.

You're correct.  A framework can be designed, but it can't be relied on unless
people choose to use it consistently.  In the case of JDK Release Projects,
a certain amount of enforcement around uniformity of use does exist by virtue
of the fact that reports are generated to gauge general progress.  (e.g.  How
many bugs haven't been triaged?  How old are they?)  Right now, those reports
are not widely available; however, one of the happy side-effects of having
the new bug system is that the entire community will have access to them.

> Finally, it also only indicates progress from the perspective of fixing the
> issue in a specific code base. It doesn't necessarily directly pertain to the
> problems of delivering a solution to the customer (may need to be delivered in
> multiple patches/releases), 

In the current bug system, we have a feature called "Multi-Release" (MR) which
allows us to track bug fixes as they're applied to different releases.
Similar functionality will need to exist in the new bug system.  I'll be
working on writing up a proposal for that so that it can be discussed here.

>                             or learning everything we can/should from the
> incident (regression test, more testing of functional area,
> definition/observance of coding practices, ...)

The existence of an Evaluated status does not preclude the ability to analyze
the bug data anymore than the existence of two statuses in the current
system.  

> I don't buy the arguments presented for the state Evaluated, but if you can
> demonstrate distinct process roles for Open and Evaluated, then I would be
> happy with it. I can also accept an argument of the form "we're used to do it
> this way, it works okay, so why change" :-)

As I said in an earlier e-mail, a bug may be moved to "Open" by anybody who
considers themselves part of triage.  Successful triage requires skill at
prioritization, resource management, and technical breadth.  A bug may be
moved to "Evaluated" by somebody who has technical depth in the bug's area.
In my mind these are distinct roles, though I'm sure there are many cases
where they may be preformed by the same person.

I can't argue the need for "Evaluated" from basic principles.  There are many
bug systems (out-of-the-box JIRA being one of them) which don't have such a
distinction.  Products which depend on such systems have been delivered.  What
I can say is that JDK developement has had the ability to indicate that a
certain amount of technical study has been performed on a bug and there are a
non-trivial number of people in various roles who have come to rely on its
existence.  In the current bug system, two status (Cause Known, Fix
Understood) are used.  In the Pilot, I am proposing that we use one.  This
seems like a reasonable compromise.

Thanks,
iris