Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Peter Jensen]

On 01/17/12 16:59, Bernard Traversat wrote:
> On Jan 17, 2012, at 3:28 PM, Iris Clark wrote:
>
>> 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.
> We should consider other pieces of information to capture the evaluated state without having
> to create an entirely new state (targeted release info, assigned engineer, comments, etc). An
> evaluated state is also a fairly subjective state.  Until a fix has been created, you can't really be sure
> that you have fully understood and evaluated the issue. From a management  standpoint, i
> most likely will want look at the bug comments and targeted release info than just rely on
> this state anyway.
There's an awful lot of information one might want to track in a bug 
record. Any modification of a bug record effectively constitutes a 
change-of-state, so maybe we should define what kind of change qualify 
as a change of State (capitalized).

In my opinion, the one defining characteristic of a State change, is the 
implication of a transfer of (primary) responsibility from one 
well-understood function/role to another. At least a rule like this 
results in a consistent level of abstraction (which allegedly is good 
for human understanding:-)

For instance, the State New may be said to be "owned" by the 
Support/Evaluator role, Open by the Development role, Fixed by the 
Quality role, and Closed by the Release Managment role.

Substates can then be defined by the each functions. Substates may be 
used in different ways. For instance, Development may use it to indicate 
progress/subprocess (e.g. queued (default), cause known, fix understood, 
fix in progress, ...), while Release Management may use it for 
classification (verified, unverified, not-a-bug, ...).

Another way of putting this. Before you make something a State, you must 
define a corresponding role. It's, of course, entirely possible to 
assign New to Support (initial-evaluation), Open to Architect 
(business/technical evaluation), and Evaluated to Development. I'm just 
not sure that this is the most accurate reflection of the actual 
development process. In any case, we're just pretending when we suggest 
evaluation and fixing is an orderly sequential process.

>
>> Let's not increase the complexity of our workflow right now.
> +1
+1

There are also some potential Substates which might be useful for Fixed 
issues, such as
- queued (default)
- verification-in-progress
- escape cause known
- escape solution known

However, rather than confusing "the world", with more Substates, I think 
it's probably better to track this stuff by a different mechanism (e.g. 
tags). Another reason is that escape analysis might well happen before a 
bug is Fixed, or even after it's Closed. The whole notion of a 
sequential workflow really is a gross approximation.

>
> Cheers,
>
> B.
>