Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Phil Race]

If by "process" you mean "accept" and leave lying around, maybe.
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.
Evaluated and other states, such as the closed state are what tell you 
if they are really handled.

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.

-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?
>