OpenJDK bug database: DRAFT Developer Workflow

[Richard Bair]

> [snip, snip]
>> 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
>> -----
> After countless hours (maybe years!) of conducting bug review meetings, my experience is that *every* bug has a story.  Nobody is content to describe their work as "fix understood" or "cause known".  And without the story, reviewers can't make useful decisions about risks, rewards, estimates etc.  The story is (or should be) captured in the commentary and it must be read.  I can't think of any useful decisions that an RTeam or Eng. Mgr. could make simply by looking at a "cause known" or "fix understood" status.
> 
> Perhaps these statuses are useful for individual engineers to sort their bugs, but I don't see them helping any of the management functions.

To give even more context to this, we haven't missed these sub states at all in JavaFX. Most of us are ex-JDK developers, but in JavaFX we have been using JIRA for 3 maybe 4 years now. The states we have are:

	New
	Open (Not my favorite term)
	In Progress
	Reopened
	Resolved (Engineers resolve)
	Closed (SQE closes after verification)

There are a couple others in our JIRA system, but we don't use them. To be honest, I've not found a great deal of utility out of Reopened either, but it hasn't complicated my life much so I'm OK with it.

Then there are a number of different "Resolutions" which indicate how we resolved it.

	Fixed
	Won't Fix
	Duplicate
	etc etc

The only piece of information that we've felt pain over not having, is "Fix Available" or some other method for tagging the issue with what repo the fix is available in. I'd prefer not having a state for this, but just tag the issue (so it is still searchable), and have the tagging done automatically when an issue is pushed into a repo.

As Brian said, I don't see any value from a bug court or release team perspective in having more states or sub states, and as an engineer I wouldn't ever use them. However as an engineer, if you find them useful, you can make use of the custom tag feature in JIRA and keep this additional information in a way that is easy for you to query and understand. Likewise if a team decides they want additional categorization (for example, in the JavaFX UI Controls team we would add a tag ScrollPane for any issues involving the ScrollPane control, etc, and a single Issue might affect multiple controls and so forth), then that is perfectly reasonable as well. But from a higher level release team perspective and from a don't-overcomplicate-my-life perspective and from a universal-process-decision perspective, I much prefer just having a short list of states.

Thanks
Richard