Bug System Pilot Dev Workflow: DRAFT Accepted/Understood
john.pampuch at oracle.com
Tue Jan 17 15:38:31 PST 2012
This makes sense to me, as it reflects the current process of bug
triage, which is a fairly cursory analysis of a bug by the component
triage team, followed by a further evaluation where an assigned engineer
can determine the extent and complexity of the bug and potential fixes.
On 1/17/12 3:28 PM, 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)
> 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.
More information about the discuss