Bug System Pilot Dev Workflow: DRAFT Closed

[Iris Clark]

Hi.

Thanks again for your comments over the past few weeks.

Here is a summary of the relevant portions of messages relating to the
"Closed" status, a decision for what the Pilot workflow will look like, and a
reasons for that decision.

Thanks,
iris

DECISION

Keep a single terminal status, "Closed".  Remove the new "Closed:Not Accepted"
substatus. Rename the new "Closed:Not our Bug" to "Closed:External".  Define a
new JIRA link type "caused by" which references the failed solution in the new
bug when a bug is "Closed:Fix Failed".  Finally for "Closed:Will not Fix"
recommend that the Evaluation include reasoning and provide examples.

REASONS

For "Closed", the desire to easily distinguish between those bugs which have
resulted in modifications and those that do not is trivially met using the
"WAS" or "WAS NOT IN" operator to identify all bugs which have (not?) been in
the "Fixed" status:

  http://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-WAS

  status WAS ("Fixed")

  http://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-WASNOTIN

  status WAS NOT IN ("Fixed")

We may need to reconsider this decision if performance is found to be
unacceptable during the Pilot.

Remove the new "Closed:Not Accepted" substatus.  It does not appear that this
new substatus will be generally useful.

Rename the new "Closed:Not our Bug" to "Closed:External".  "Closed:Not our
Bug" is too similar to the existing "Closed:Not a Bug" which may lead to entry
errors.

For "Closed:Fix Failed", define a new JIRA link type "caused by" which must be
used in the new bug to reference this failed solution.

  http://confluence.atlassian.com/display/JIRA/Configuring+Issue+Linking

Description for "Closed:Will not Fix" will be updated as follows to recommend
that the Evaluation include reason(s?) and provide examples:

  http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html#closed-will-not-fix

  The IE agrees that this is a problem; however, they have chosen not to fix
  it. The Evaluation should include reasoning, e.g. not appropriate for the
  given release, causes unacceptable incompatibilities, problem will be
  addressed via alternate solution, cost exceeds benefit, etc.

BACKGROUND

Here's a summary of the relevant portions of the discussion.

David Holmes:
  http://mail.openjdk.java.net/pipermail/discuss/2011-December/002238.html

David is not thrilled with "Closed:Future Project".  He would like to see
"Closed" be divided into two status to easily separate those bugs for which a
change was applied from those without changes.  David notes that "Closed:Not
Accepted" is likely only applicable to RFEs and the IE may not be in a
position to make such a decision.  He requests that the description for
"Closed:Will Not Fix" include text clarification for when this substatus might
be appropriate.

  http://mail.openjdk.java.net/pipermail/discuss/2011-December/002296.html
  http://mail.openjdk.java.net/pipermail/discuss/2012-January/002301.html

Reiteration that he'd prefer separate states to distinguish between bugs which
resulted in a code changes and those which did not.

Joe Darcy:
  http://mail.openjdk.java.net/pipermail/discuss/2011-December/002259.html

"I believe the intention of "closed: future project" state is intended to more
neatly address issues like a "Java should have a module system" bug, filed
back in 1996.  Leaving these is a chronic accepted or cause known state for
years obscures other issues."

  http://mail.openjdk.java.net/pipermail/discuss/2011-December/002262.html

In answer to a question posed by me (Iris) Joe says that some areas (e.g. Java
language) have a large percentage of bugs which would make use of
"Closed:Future Project".

  http://mail.openjdk.java.net/pipermail/discuss/2011-December/002245.html

Joe wants the results of the following query to be extremely easy to get:
"Which issues were successfully resolved in a release because of my code
changes?"  A workflow which is structured to make this query simple would be
ideal.  He suggests two final/terminal states.  Regarding "Closed:Fix Failed",
Joe indicates that he is in favor of it being a substatus of "Closed" (as
stated in DRAFT 2011/12/13) rather than its own state (as in BT now).

Alan Bateman:
  http://mail.openjdk.java.net/pipermail/discuss/2011-December/002243.html

Alan thinks that the set of "Closed" substatuses are too generous and the lack
of clear separation may lead to minor spats.  He assumes that it will be
possible to change the substatus at anytime.

Peter Jensen:
  http://mail.openjdk.java.net/pipermail/discuss/2012-January/002300.html

Peter provides an argument for keeping a single terminal state.  Optimization
for a particular query will likely make other queries more difficult.
Different people will be interested in the results of different queries.