OpenJDK bug database: DRAFT Developer Workflow

[David Holmes]

On 17/12/2011 8:17 AM, Brian Beck wrote:
> On 12/16/11 11:07 AM, Iris Clark wrote:
>> [snip]
>> 1. Dispatched: A bug comes in.
>> 2. Accepted*: Component teams do initial triage. The goal is to verify
>> that
>> there's sufficient information to investigate the bug and determine
>> importance of the reported problem assuming it is real. An initial
>> Priority, Cat/Subcat, and target release are verified/assigned as
>> appropriate.
>> NOTE: There is no guarantee that the problem actually exists!
>> 3. The reported problem reproduced. Priority, target release, etc. may be
>> adjusted.
>> 4. BT Cause Known/JIRA Understood: Sufficient investigation preformed to
>> gain a basic understanding of how the problem should be addressed.
>> Evaluation updated.
>> 5. BT Fix Understood/JIRA Understood: A potential solution is devised.
>> Impact and risks associated with the solution are known. Suggested fix
>> updated.
>> 6. Fix in Progress: Active work started to address the problem.
>>
>> Did I miss anything? [ Note that 3 does not have a name in either the
>> proposed JIRA workflow or BT. Minimally, that needs to be addressed. ]
>>
>> 3-5 feel like they're very tightly related so are perhaps a single
>> status with
>> sequenced substatuses? (I don't know if JIRA supports the concept of
>> "sequenced
>> substatuses", so these might need to be individual statuses.)
>>
> To me 3-5 are very waterfall-esque. In particular, 4 and 5 are sort of
> theoretical states. Very often they don't exist as discreet points of
> time. For many bugs I can't say I understand the problem until I know
> the fix. Likewise I can't say I understand the fix until I've made it
> and tested it.
>
> There may be some element of personal style in this. I have met
> engineers who rigorously take bugs through all these states in Bugster.
> But I know this doesn't suit me. I also know from my days on the Bug
> Police that it doesn't suit lots of others.

Not just personal style but also what products you work with and their 
release schedules and resourcing etc, and what role you are playing with 
the bug.

For the products that I've worked on these sub-states were used 
extensively. Getting a problem to "cause known" meant you now know how 
the problems arises, under what conditions it might also arise and the 
potential impact it has. This may lead to a prioritising of the bug so 
that a fix is found immediately, or it may mean this problem is not 
critical and can be left to a later time (likely another release) - 
leaving it in "cause known". You may be working on a solution to a 
problem and time is running out to get this solution in place. Again the 
bug may be deemed not critical for this release and deferred, so you can 
mark it as "fix understood" and move on to critical work.

Sometimes an apparent fix is "obvious" but you (as the initial 
evaluator) are not the one who will fix this, nor even the one who may 
assign a resource to fix it, so again it can be marked as "fix 
understood" (with comments as to what the suggested fix is).

>  From a project management point of view the states that need to be
> distinguished are:
>
> 1. Open (a.k.a. accepted, a.k.a. triaged) - a valid bug that's waiting
> to be worked on
> 2. In Progress - an issue that is currently being worked on
> 3. Resolved - an issue that is solved

This is insufficient in my opinion as you have no idea to what extent 
progress is being made. If the weekly bug stats show X bugs as "cause 
known" and Y as "fix understood" then you have a much better idea as to 
what time and resources are likely to be needed to take them to "fix 
available" compared to just seeing "X+Y" in progress bugs.

David
-----

> These conditions need to be tracked widely across all types of issues
> and all types of work styles. When it comes to how much is known about
> an individual bug, this is best left to the description and commentary.
> They are far better at recording the nuances that are necessary to
> resolve a particular issue.
>
> Brian.
>
>
>
>