Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Iris Clark]

Hi.

See inline.

> On 17 jan 2012, at 01:46, David Holmes wrote:
> > 
> > On 17/01/2012 6:52 PM, David Holmes wrote:
> >> Just one comment on this:
> >> 
> >> > We rename "Accepted" to "Open" with the following definition: 
> >> > Initial triage has determined that the bug/feature request contains 
> >> > sufficient information to estimate the basic feasibility of 
> >> > addressing the problem and to prioritize the request. If this is a 
> >> > bug, there is no guarantee that the problem has been reproduced.
> >> 
> >> I find those two statements somewhat contradictory. If the problem 
> >> may not have even been reproduced how can you have triaged it enough 
> >> to have "sufficient information to estimate the basic feasibility of 
> >> addressing the problem and to prioritize the request" ?
> > 
> > Okay maybe not so contradictory in some cases eg if external triage has
> > already been done. 
> > 
> > I think what I'm missing from this definition is understanding the criteria
> > for moving from New to Open. 
> 
> Initial triage should ensure that the bug is assigned to the right group and
> has the information needed to assess where looking at it should come relative
> to other work/bugs.  Until we know otherwise we have to assume that it is a
> real issue and treat it as such (which is an evaluation task not an initial
> triage task).
> 
> For initial triage I would suggest the things that should be reviewed are:
>    1. To which group the bug is assigned
>    2. In the context of which release it should be investigated (aka
>       'targeted' in the current system though I know people have issues with
>       that) 
>    3. Correctness of the priority given the knowledge we have now.
>    4. Any other obvious missing information which would mean it should
>       immediately be assigned back to the submitter as NMI (Needs More
>       Information) 
>    
>    /GES

The currently published DRAFT (2011/12/13) lists the following criteria for
moving from "Dispatched to Accepted" (now renamed "New to Open"):

http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html#dispatched

- Accepted [ typical progression ]
  When the Initial Evaluator (IE) (or other) can verify all of... 
  - Category/subcategory is correct (assuming we have subcategories)
  - Description contains sufficient information to verify/suspect that 
    this is a real problem
  - Priority complies with release standards and is computed based on 
    questions for impact, likelihood, and workaround (ILW).
  - Other basic information is correct or adjusted as necessary (reported
    release, synopsis, type (bug or feature), etc.)
  Assignment of a responsible engineer is not required but strongly 
  encouraged.

  Question: Is a targeted release required?

With the exception of my open question regarding setting the targeted release,
I think I've covered all of 1-3 and most of 4 that Georges outlines above. I
believe that the remainder of Georges 4 is covered in the criteria for moving
from "Dispatched to Incomplete" (now renamed "New to Incomplete"):

- Incomplete
  - More information from the bug/RFE's creator is necessary to evaluate the
    problem. 
  - The IE must provide a description of the required information.

If you're in the DRAFT and are wondering what the criteria were to getting to
this status, there are already back links in the "Comes from" secton for each
status.

Sadly, it's hard to completely extricate the definition of the status from
it's context (how did we get here), but I think the information is all there.
Here's a minor revision to the definition of "Open":

  Initial triage has determined that the bug/feature request contains
  sufficient information to estimate the basic feasibility of addressing the
  problem and to prioritize the request. At this point, the report is assumed
  to represent a real problem.  If this is a bug, there is no guarantee that
  the problem has been reproduced.

About the targeted release open question, given the trend in JDK development
to require setting a "targeted release" as described by Georges here:

http://mail.openjdk.java.net/pipermail/discuss/2011-December/002269.html

and John Pampuch's comment that "targeted release" should be regarded as a
targeted analysis here:

http://mail.openjdk.java.net/pipermail/discuss/2011-December/002278.html

I think I need to add the following bullet to the "New to Open" criteria in
answer to the "Question":

  - Targeted release is set providing an initial estimate for analysis.

Given the trend to not assign an engineer to a bug unless they are actively
working on it (or have plans to do so in the immediate future), the sentence
encouraging assignment should be modified as follows:

  Assignment of a responsible engineer is not required.

Thanks,
iris