Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Georges Saab]

Sounds like we will be constructing a lot of queries looking for all bugs
in status Open, Evaluated, or Fix in Progress...  


On 17 jan 2012, at 15:28, Iris Clark wrote:

> Hi, Georges.
> 
>> With the caveat that we should compare how the list of default JIRA status
>> values compare so as to not introduce _unnecessary_ complexity, I would say
>> that Open is a status, where evaluated, cause known, and Fix understood are
>> all sub-status values -- 
> 
> In this area of the workflow, the default JIRA status are: New and Open.  They
> have no substatuses.
> 
> The current proposal is: New, Open, and Evaluated (with substatuses Cause
> Known, Fix Understood).  Thus, there is one additional status with a very 
> limited number of substatuses that reflect the current usage.  
> 
> A bug may be moved to Open by anybody who considers themselves part of triage. 
> This could include people who are not actually qualified to investigate and
> apply a solution.  The criteria to move the bug from New to Open do not 
> require technical depth.  
> 
> A bug is moved to Evaluated by a person who is qualified to make a judgment 
> on the technical aspects of a solution.  The defined substatuses can be used
> to refine the level of understanding of the problem. 
> 
> I don't think it's a good idea to combine these two status.
> 
> In the current DRAFT of the Developer Workflow (2011/12/13)
> 
> http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html
> 
> for each status, there are three basic section of information:  the definition, 
> the "Comes From" list, and the "Goes to" criteria.  I think each status also needs 
> a "Who" to encapsulate the information that I've provided above.  If you read 
> through the feedback, you'll see that others have requested similar documentation.
> 
>>                            <bikeshed> one that is missing is 'investigating'
>> which would occur prior to evaluated, and there may be ones missing after Fix
>> Understood as well such as Fix in progress etc.  </bike-shed>
> 
> Let's not increase the complexity of our workflow right now.  We can always
> add substatuses if a strong argument for them comes up during the pilot.  We
> can even add them after the system goes into production if necessary.  It's
> much harder to remove them.
> 
> Thanks,
> iris