search

jcp-org / import-issues-test

0 stars 0 forks source link

JSR348-71: Issue Tracker should be a defined term #66

Closed apastsya closed 7 years ago

apastsya commented 13 years ago

Jira issue originally created by user shannon:

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

apastsya commented 13 years ago
apastsya commented 13 years ago

Attachments:

apastsya commented 13 years ago

Comment created by keilw:

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

apastsya commented 13 years ago

Comment created by shannon:

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.

apastsya commented 13 years ago

Comment created by starksm64:

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.

apastsya commented 13 years ago

Comment created by starksm64:

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

apastsya commented 13 years ago

Comment created by pcurran:

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.

apastsya commented 13 years ago

Comment created by pcurran:

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

Thanks...

apastsya commented 13 years ago

Comment created by pcurran:

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

apastsya commented 13 years ago

Comment created by eduardo:

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".

apastsya commented 13 years ago

Comment created by pcurran:

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

apastsya commented 13 years ago

Comment created by pcurran:

It is resolved - we just need to review.

apastsya commented 13 years ago

Comment created by pcurran:

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

apastsya commented 13 years ago

Issue was closed with resolution "Fixed"