jsr348
  1. jsr348
  2. JSR348-71

Issue Tracker should be a defined term

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Component/s: None
    • Labels:
      None

      Description

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

        Issue Links

          Activity

          Hide
          keilw added a comment -

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

          Show
          keilw added a comment - What you suggest there, a list of suggested systems like JIRA, Bugzilla, etc.?
          Hide
          Bill Shannon added a comment -

          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.

          Show
          Bill Shannon added a comment - 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.
          Hide
          starksm64 added a comment -

          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.

          Show
          starksm64 added a comment - 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.
          Hide
          starksm64 added a comment -

          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

          Show
          starksm64 added a comment - 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
          Hide
          pcurran added a comment -

          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.

          Show
          pcurran added a comment - 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.
          Hide
          pcurran added a comment -

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

          Thanks...

          Show
          pcurran added a comment - Please make the changes indicated in my previous comment and then we'll look for additional feedback. Thanks...
          Hide
          pcurran added a comment -

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

          Show
          pcurran added a comment - Will reopen to try and work around a JIRA bug...
          Hide
          eduardo added a comment -

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

          Show
          eduardo added a comment - 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".
          Hide
          pcurran added a comment -

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

          Show
          pcurran added a comment - Reopening until we've confirmed that the changes implement what we agreed.
          Hide
          pcurran added a comment -

          It is resolved - we just need to review.

          Show
          pcurran added a comment - It is resolved - we just need to review.
          Hide
          pcurran added a comment -

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

          Show
          pcurran added a comment - Closed, as agreed at the September 21 Working Group meeting.

            People

            • Assignee:
              eduardo
              Reporter:
              Bill Shannon
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: