OpenJDK bug database: DRAFT Developer Workflow

[Jim Graham]

Perhaps we have 2 separate issues here and much of the disagreement is 
coming from combining the two into a single solution (vs. "not that 
solution"):

- Some engineers find value in knowing and tracking whether the cause of 
a bug has been discovered (or not).

- How do we track that information - i.e. via a bug state or a tag?

As an contributor I guess I'm only moderately interested in whether a 
bug is evaluated or not as I'm more concerned with "how complex is the 
problem and can I tackle it in the next milestone development phase" 
than "do I know what caused this bug?"  For one thing, if I did the 
investigation then I know by reading the bug what the cause was and so I 
don't need to tag it as such for my own purposes.  But, I guess I would 
like to find out quickly "which of these bugs are waiting for me to 
review them".  On another hand, though, if another engineer investigated 
it and commented on the cause and then assigned it to me, I usually 
start from square one because I'm very suspicious of someone else's 
findings.  At that point, it only becomes "cause known" when I verify 
that what they said is correct.  Often it is not - especially when they 
are reassigning it to me - because they determined that it was caused by 
"something in someone else's domain" and that was enough for them to 
consider it "cause known", but not enough for me to consider it 
"specific cause known".

On the other hand, as a customer of a product with an exposed bug 
system, I very much want to know when the bug has been looked at and 
what the prognosis on how long it will be before I see a fix.  Thus, I 
want more than "the bug is accepted but not yet fixed".

I don't have a good answer, but if we find some orgs wanting to mark 
bugs as "cause known" and other orgs not caring then I would suggest 
that the orgs that are not in that habit are not being kind to our 
customers and so they are a problem here.  As to how we then mark them, 
that can have multiple solutions, but as a customer I tend to think of 
it as part of the workflow of watching my reported bug flow through the 
system - I send it in, then it appears in the public list, then someone 
looks at it, then they realize what causes it, then they have a plan for 
how and when it may get fixed, then (sadly usually much later) I see 
progress on fixing it.  I think we owe it to our customers (Java 
developers in this case) to extend that same level of information, 
however we may choose to tag it for tracking, and however we may choose 
to triage bugs internally...

			...jim