OpenJDK bug database: DRAFT Developer Workflow

[David Holmes]

On 4/01/2012 10:11 AM, Peter Jensen wrote:
> 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.

That sounds to me like you want the bug tracking system to do workflow 
and resource management. I don't consider that the role of such a system.

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

That depends on what query capabilities the tool provides. For bugster 
queries via the GUI you have to weed through them. If JIRA is better in 
that regard, great, but I still prefer to see more distinct top-level 
states.

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

I have yet to interact with a bug system that gives the submitter any 
idea whatsoever of when, or if, a particular issue may be fixed, until 
it reaches a state used to convey that information. While a bug is being 
investigated - transitioning from accepted to cause known, to fix 
understood - there is no information as to when it will be fixed. This 
seems more of a process issue to me. We could easily decide, for 
example, that a "commit to fix in build/release" field reflects the 
actual intention to fix regardless of actual state of that fix.

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

I don't see how asking a question relates/compares in any way to having 
clearly defined states like "cause known" or "fix understood". And of 
course you never know ALL of the implications - "fix understood" doesn't 
imply absolute knowledge of every nuance, just as actually fixing the 
bug doesn't imply you know ALL the implications of the fix you've committed.

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

The states convey initial information used to discuss estimates and 
risks pertaining to the bug. If every bug is just "accepted" then the 
discussion has to start with "where are with this bug? do we know what's 
causing it? do we have a fix?" instead of "I see the fix is understood, 
what do we need to do before pushing it? Is it a high or low-risk fix?"

Just my opinions - YMMV

David
-----