Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[David Holmes]

On 20/01/2012 6:18 AM, Richard Bair wrote:
>
> On Jan 19, 2012, at 12:11 PM, Richard Bair wrote:
>
>>> 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.
>>
>> As mentioned last time we went around this, the problem with many of these states is that they will not be universally enforced, and are therefore of no more real use than a label anyway. Meaning, you cannot derive meaningful information from a macro level from these states. That's just a plain fact. They can be useful on the micro level, but then so can labels. That's an opinion.
>
> When I say "these states", I mean things like "evaluated", "fix understood", "cause known", "in progress", etc. They are not universally used by everybody, and thus are not reliable (this is the "plain fact" stated above). That doesn't mean they aren't useful I like the idea that the "states" New, Open, Resolved, Closed (and maybe In Progress) are the only states you'd have, and then "Open" could have the additional sub states. I wouldn't use them, most likely, but if it were thus separated then we'd know that when a bug progresses from state to state, it is largely reliable and conveys meaningful information, whereas the sub states are really just canonized labels if you will, that people may or may not use.

I think canonical "tags" via states/sub-states are better than adhoc 
ones. Even if you do not need to follow all the intermediate 
transitions, the process can still define what those transitions mean.

David

> Richard