Bug System Pilot Dev Workflow: DRAFT Closed
iris.clark at oracle.com
Mon Jan 23 22:16:51 PST 2012
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.
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.
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:
status WAS ("Fixed")
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
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.
Description for "Closed:Will not Fix" will be updated as follows to recommend
that the Evaluation include reason(s?) and provide examples:
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.
Here's a summary of the relevant portions of the discussion.
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
Reiteration that he'd prefer separate states to distinguish between bugs which
resulted in a code changes and those which did not.
"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."
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
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 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 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.
More information about the discuss