Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Peter Jensen]

On 01/19/12 11:07, Phil Race wrote:
> If by "process" you mean "accept" and leave lying around, maybe.
If I'm looking at it from the outside, trying to answer if we're on 
track to complete in time,
then I don't care. If I'm trying to optimize Development operation, then 
I might.

> Since if you don't have an evaluated state then you really don't know 
> how well development
> really processes bugs. Getting them into triaged/open tells you 
> something about incoming
> rate (not everything since it ignores bugs that go straight to 
> incomplete or closed for some reason
> such as being  a duplicate or will not fix, or not a bug etc). So 
> looking at "open" bugs
> really tells you the ones that dev. is not really handling beyond the 
> 2 minute triage.
Only, if you assume Evaluated is used consistently. If it's optional (up 
to teams or individuals),
the distinction is only useful when you know to which bug it applies.

> Evaluated and other states, such as the closed state are what tell you 
> if they are really handled.
Not really. I've seen issues sitting idle as "Fix Understood" for months 
and years. Bugs can also get stalled waiting for validation, and a 
non-negligible percentage will fail validation. State only tells me what 
(supposedly) has been done. It not a good indicator of what's being 
done, or when you can hope for completion.

>
> Tags are not the same as states or sub-states. They are free-form 
> keywords with no
> guarantee of consistency and probably a lot less efficient to search 
> on too. So I
> can't agree with anyone who tells me tags are a suitable replacement 
> for a state/substate.
I agree about tags. I think they are just a safety valve for things you 
didn't anticipate.

But it doesn't have to be tags. You can use substate or other fields 
with well-defined values.
For instance, instead of the state Evaluated, with substates Cause Known 
and Fix Understood, you could easily have just Open, with substates 
Backlog (default), Cause Known and Fix Understood.

>
> -phil
>
> On 1/19/2012 10:22 AM, Peter Jensen wrote:
>>
>>> 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.
>> Just by means of example.
>>
>> If I want to know the rate at which Bug arrives on Development's 
>> plate, I would need to count the bugs changing to Open, from states 
>> other than Evaluated, plus the bugs changing to Evaluated, from 
>> states other than Open, with in a given period of time.
>>
>> Not impossible, just not as easy as counting bugs changing to a 
>> single state.
>>
>> Of course, if JIRA, unlike Bugster, can impose the restriction that 
>> the state Evaluated can only be reached from Open, then it's almost 
>> the same (except for the Evaluated->Open transition, which I somehow 
>> don't see getting used a lot, never mind how badly an issue was 
>> initially misunderstood:-)
>>
>> BTW, does anyone know if the JIRA database records transition history 
>> in a form that makes this kind of queries practical?
>>
>