OpenJDK bug database: DRAFT Developer Workflow

[Brian Goetz]

I have a number of issues with the proposed workflow.

1.  At the risk of starting with a silly one, Dispatched?  Really?  Yes, 
everyone who has worked at Sun over time has learned what Dispatched 
means, but it is a constant question for newcomers, and given that one 
of the major motivations for a new bug system is externalizing the 
process so that the community can play too, we should err on the side of 
using terms that are understood by the community.  Every other bug 
system calls this "New".  Using a term that no one understands sends the 
wrong message about who this system is for.

2.  Accepted/Understood.  I think these should be merged into something 
like "Open".  The distinction between Accepted And Understood is a very 
fuzzy one; in reality there are many shades of grey between them and 
achieving understanding often happens gradually over time.  Having a bug 
transition from one to the other does not provide a great deal of 
additional information to external stakeholders, which is mostly the 
point of bug state transitions.  A good way to evaluate whether this 
state carries its weight is: what impact does the transition from 
Accepted to Understood have to non-Dev stakeholders, such as the bug 
submitter or QE?  I think very little, since Understood does not mean 
that resources have been allocated to the bug.  And the names Accepted 
and Understood carry connotations that are easily misinterpreted as 
committments to fix.

3.  Fixed.  Having this be the end of the line seems excessively 
Dev-centric.  The workflow should support not only Dev, but QE, RE, and 
other participants as well.  I think a better fit for our process would 
be Fix Available, which indicates that Dev has pushed a changeset for 
the fix, but that changeset has not necessarily been integrated (RE) or 
tested (QE).  I would think that the transition after an engineer pushes 
a changeset would be to move it to some Fix Available state, and 
transfer ownership of the issue to the responsible integrator. 
(Similarly, once integrated, ownership of the issue should go to QE to 
for verification, who can close the issue.)  This more easily enables 
reports to show where in the organization the work currently is, where 
the bottlenecks are, etc.

Bug states (and other top-level metadata, such as owner) should provide 
a simple view of not only where the bug is in its lifecycle, but who in 
the organization has ownership now.  As a bug progresses, ownership 
should transition from its creator to a triage team to a component team 
to a responsible engineer to integration to testing to delivery. (Though 
it may not be necessary to reflect every one of those transitions as 
part of the state.)  Similarly, when an engineer or integrator or QE is 
done with their part, they should be able to *get it off their plate.* 
The workflow should reflect who has ownership of the issue between the 
time Dev has pushed a fix and the time it is integrated; pretending that 
Dev still owns the issue (and that RE/QE does not) presents a distorted 
view of the process.

4.  There are a number of other things that are not reflected in this 
draft workflow, including:
  - What happens before a bug hits the "new" state?  What is the 
equivalent of today's "webbugs" system?  Do we anticipate creating bugs 
in this project, or doing what most large projects do, which is have a 
front-end triage project whose final workflow stage is to move it to the 
New state in the main project?
  - What are the access control rules for state transitions?  Who can 
create issues?  Who can assign them to engineers?  Who can set 
priorities or target fix versions?  How does this play into JIRAs 
security policies?
  - What is our plan for handling when a fix has to be integrated into 
multiple codelines?  There was talk of a "normalized" data model for 
this (which made a lot of sense to me) but I don't see any mention of 
that here.

I look forward to seeing future drafts.