[JSR348-71] Issue Tracker should be a defined term Created: 11/Aug/11  Updated: 22/Sep/11  Resolved: 08/Sep/11

Status: Closed
Project: jsr348
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bill Shannon Assignee: eduardo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File JCPIssueStates.png    
Issue Links:
is related to JSR348-95 Section 1.1.2 needs a little rewordin... Closed


Issue Tracker should be a defined term, possibly including some requirements around what
we think an acceptable Issue Tracker is.

Comment by keilw [ 17/Aug/11 ]

What you suggest there, a list of suggested systems like JIRA, Bugzilla, etc.?

Comment by Bill Shannon [ 17/Aug/11 ]

A list of examples such as those would be good, but what I had in mind was some
sort of description of what you think the minimum requirements are for an
Issue Tracker for the purposes of the JCP.

Is a spreadsheet sufficient?

A wiki page?

Is some sort of search capability required?

Must the public be allowed to enter issues directly? Or is it ok if they send
their issues to an email address and the Spec Lead enters them?

Must closed issues remain visible, or can they disappear after they're closed?

Does the PMO or the EC have to approve your choice of Issue Tracker when the
JSR is submitted, so the only actual requirement is that the JSR gets approved?

I suspect you don't want to say much about most of this, but think about what you
would consider to be minimally acceptable and not open to the judgment of the EC
and write that. I'm not suggesting any particular answer, only that you decide
what the answer should be and record it in the defined term.

Comment by starksm64 [ 25/Aug/11 ]

At a minimum, in order for issues to be useful for tacking the state of a JSR, we need to enumerate the logical states and resolutions that need to be used to classify issues. I believe all issues must be visible, organized according to state and resolution at each phase of the EC balloting.

Comment by starksm64 [ 30/Aug/11 ]

Suggested states:
+ Open - open, new or in progress issue
+ Resolved - resolution taken, awaiting verification
+ Closed - resolution accepted, end of workflow

Suggested resolutions:
+ Complete - work on issue completed
+ Rejected - issue was not accepted as valid with reason why
+ Deferred - issue was out of scope for current release
+ Challenged - issue has no satisfactory resolution

Comment by pcurran [ 08/Sep/11 ]

Please add the following new definitions

Issue Tracker: A mechanism to allow issues (problems, tasks, comments, or requests for change) to be recorded and tracked by priority, status, owner, or other criteria. The Issue Tracker should permit issues to be identified by states such as open, resolved, and closed and should support the assignment of resolution types such as deferred (postponed to a follow-on release,) fixed (implemented,) challenged (no satisfactory resolution,) and rejected (deemed inappropriate or out of scope.)

Issue: an explicit reference to an item defined in an Issue Tracker.

Issue List: A list of Issues generated from an Issue Tracker, identifying the disposition of each.

Please replace the contents of section 1.1.2 ISSUE TRACKING with the following

Issues must be tracked through a publicly readable Issue Tracker. The Expert Group may choose to use a publicly writable Issue Tracker, thereby permitting the public to log issues directly, or alternatively to identify formal comments in some other manner and to enter them into the Issue Tracker on behalf of the submitter. Whenever a Spec Lead or a Maintenance Lead submits materials to the PMO for review or ballot they must also provide an Issue List indicating the disposition of all of the Issues that have been logged against the JSR. In order to enable EC members to judge whether Issues have been adequately addressed the Issue List must make a clear distinction between Issues that are still open, those that have been resolved, and those that are closed, and must indicate the reason for any change of state.

The PMO will publish the Issue List or a pointer to it together with the other materials.

EC members should review the supplied Issue list and take it into consideration when casting their ballot. If they have any reservations or concerns about a 'yes' vote, or if they wish to vote 'no,' they should accompany their ballot with comments which reference one or more Issues (perhaps logged by them) that they would like to see addressed in the future. EC members should vote 'no' if they believe that the Spec Lead or Maintenance Lead has not adequately addressed all Issues including those that have been rejected or otherwise closed by the Expert Group.

Comment by pcurran [ 08/Sep/11 ]

Please make the changes indicated in my previous comment and then we'll look for additional feedback.


Comment by pcurran [ 08/Sep/11 ]

Will reopen to try and work around a JIRA bug...

Comment by eduardo [ 08/Sep/11 ]

I've implemented all suggested changes, as well as harmonizing the use of Issue List, and changing all instances of "issue tracking mechanism" to "Issue Tracker".

Comment by pcurran [ 08/Sep/11 ]

Reopening until we've confirmed that the changes implement what we agreed.

Comment by pcurran [ 08/Sep/11 ]

It is resolved - we just need to review.

Comment by pcurran [ 22/Sep/11 ]

Closed, as agreed at the September 21 Working Group meeting.

Generated at Fri Dec 09 17:14:19 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.