OpenJDK bug database: DRAFT Developer Workflow
peter.jensen at oracle.com
Tue Jan 3 16:11:07 PST 2012
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
> 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
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
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
when you have a one-to-one mapping between states and roles of primary
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
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
>> If we want to use substates as a form of enumerated documentation
>> options, that's fine; Closed:Verified vs Close:WillNotFix is a good
> 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
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
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
More information about the discuss