OpenJDK bug database: DRAFT Developer Workflow

[Peter Jensen]

On 12/31/11 19:44, David Holmes wrote:
> On 1/01/2012 4:16 AM, Brian Goetz wrote:
>>>> Completely agree. I don't see any value in the various "sub states"
>>>> and I think you captured well the reason.
>>>
>>> Do we have to chose one or the other? I have used systems that had
>>> both a high level state (New, Open, Closed) and substates useful to
>>> one or more groups to keep track of where the bug is 'right now' or
>>> giving more information (for instance -- Closed:Fixed vs
>>> Closed:Verified vs Closed:Will not fix). I agree completely that
>>> some of the current status terms are misleading or confusing at best
>>> (accepted being perhaps the worst offender). As such we should take
>>> care in choosing names and perhaps most importantly have clear links
>>> to help text describing what each of these is supposed to mean.
>>
>> A good JIRA rule is: don't design a workflow where any query that anyone
>> ever has to do regularly as part of their job includes examining 
>> substates.
>
> Then you need more primary states.

Sometimes you care only that an issue is closed, others time you care 
why it's closed. If you combine  the "level of completeness" with the 
"criteria for asserting the level of completeness" you may make life 
easier for those who care about the why, only to make it harder on those 
who don't.

Having worked in both QA and Development, and with systems using either 
approach, I know that you can make it work either way. My personal 
preference is to keep the two separate:
- state: indicate a level of completeness (e.g. closed).
- substate: criterion by which the level of completion has been asserted 
(e.g. validated).

The main reason why I prefer to have a small set of states is that it 
easier to maintain a clear and common understanding of state and 
responsibility,
when you have a one-to-one mapping between states and roles of primary 
responsibility.

But, I actually don't think state is a particularly good way of managing 
workflow and responsibility. A better way would be to explicitly track 
subtasks for roles (e.g. development, qa, support,...), with responsible 
individuals assigned for each role. This way you could more easily 
iterate and work in parallel (e.g. QA may perform escape analysis while 
development fix a bug; or QA and Development may both estimate effort 
needed in parallel, before a priority is decided). Rather than relying 
on state to tell you what issues you need to look at, you would query 
based on open task for yourself or for your role (in particular, a lead 
would query for role to ensure a responsible engineer gets assigned). 
You don't miss secondary responsibilities (such as responding to request 
for information).

Anyway, I don't think this is possible with JIRA (only one responsible 
engineer at a time, and only comments available to request specific 
actions), so a small number of states that at least approximately map to 
primary responsibility is preferable. Detailed workflow needs to be 
managed informally (lots of email, and lots of information not recorded) 
. With a bit of goodwill it works fine (at other times it can get 
downright unproductive, when people start pointing fingers:-) In any 
case, more states than roles, doesn't help (at least, it doesn't help 
workflow management).


>
>> If we want to use substates as a form of enumerated documentation
>> options, that's fine; Closed:Verified vs Close:WillNotFix is a good
>> example,
>
> I think that is actually a good example of a bad situation. If I want 
> bugs fixed in a given release or build I don't want to have to select 
> all Closed bugs and then weed through them based on substates - as per 
> your "good JIRA rule". I'd advocate two different final states (as 
> opposed to our current system) that distinguishes between "closed and 
> something was changed" versus "closed and nothing happened".
You don't weed through them. You simply query on both fields, which is 
no harder than the reverse situation
where you want all closed bug and would have to query for multiple 
closed states (in some system on a numeric range of states).


>
>> since the most common consumer will be a human looking at the
>> summary page to learn the disposition. But if our processes need to
>> distinguish between Open:FixUnderstood and Open:IHaveNoFrigginIdea,
>> we're creating the sort of problem that tends to lead to the creation of
>> boundary systems.
>
> I don't know what problems you are alluding to but please don't under 
> estimate the utility of the existing states to both dev and dev 
> management. A bug system that only tracks existence is next to useless 
> in my view for both dev and the external submitter.
>
> As I have enumerated before there are numerous situations where the 
> difference between:
> - accept: "we agree this looks like an issue that needs investigation"
> - cause known: "I know how this comes about and (hopefully) understand 
> the potential implications"
> - fix understood: "I think I know how to resolve this"
> provide valuable information to both Dev and Dev mgmt. If you have a 
> deadline looming and have six bugs that are "fix understood" then you 
> have much greater confidence in your ability to meet the deadline than 
> if you have six bugs merely "accepted". And if the bug system doesn't 
> let you tell the difference then you have to assume the worse.
If they carry definite information, they are probably useful, for some 
purposes. However, they are pretty useless if not used consistently (and 
in my experience, these fields are not used consistently, at least not 
across projects).

They are of limited usefulness. For instance, they are useless to the 
submitter/support who have no way to translate this into probability of 
getting something fixed.

Something like "QA, if we changed this to work this way instead, what 
would the impact on testing be?" would be infinitely more useful than 
"cause known" or "fix understood" (do you really understand ALL the 
potential implications?)

Management would be much better served by updated estimates and risk 
evaluation. I've yet to meet a manager who, deadline looming or not, 
would make a decision to commit-to-fix or reject a bug based on these 
states.

>
> David
> -----