jsr348
  1. jsr348
  2. JSR348-7

Specify issue-tracking requirements in more detail

    Details

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

      Description

      Section 0.0.2 Issue Tracking needs more detail. How do we know that an issue has been adequately responded to? (It may not be appropriate to close an issue logged early in the process when the response is "we agree - we'll fix this later" yet we'll need to check before Final or Maintenance Release that all open issues have been closed.

        Activity

        Hide
        pcurran added a comment -

        Need to write the requirements in general language that is not specific to any particular issue-tracker.

        Show
        pcurran added a comment - Need to write the requirements in general language that is not specific to any particular issue-tracker.
        Hide
        pcurran added a comment -

        Replace lines 199-201 with the following (and also remove the comment.)

        Issues must be tracked through a publicly readable issue tracking mechanism. Formal comments must be entered into the issue-tracker, and all open issues must be responded to publicly before the JSR moves to the next stage. If the EG decides to reject a suggested change then the response in the issue-tracker must include a rationale for rejection. Responses stating that the suggested change will be made at a later date (but before the JSR or Maintenance Release is finalized) are permissible; in these cases the issue should be kept open until the change has actually been made. The issue-tracking mechanism must make a clear distinction between open, responded-to, and closed issues so the EC can clearly judge whether the EG has met its obligation to respond to all issues.

        Show
        pcurran added a comment - Replace lines 199-201 with the following (and also remove the comment.) Issues must be tracked through a publicly readable issue tracking mechanism. Formal comments must be entered into the issue-tracker, and all open issues must be responded to publicly before the JSR moves to the next stage. If the EG decides to reject a suggested change then the response in the issue-tracker must include a rationale for rejection. Responses stating that the suggested change will be made at a later date (but before the JSR or Maintenance Release is finalized) are permissible; in these cases the issue should be kept open until the change has actually been made. The issue-tracking mechanism must make a clear distinction between open, responded-to, and closed issues so the EC can clearly judge whether the EG has met its obligation to respond to all issues.
        Hide
        pcurran added a comment -

        This comment replaces the last one (I didn't notice that the following section (0.0.3) addresses response to comments.

        Please replace sections 0.0.2 and 0.0.3 with this new section 0.0.2

        Issues must be tracked through a publicly readable issue tracking mechanism. Formal comments must be entered into the issue-tracker, and all open issues must be responded to publicly before the JSR moves to the next stage. If the EG decides to reject a suggested change then the response in the issue-tracker must include a rationale for rejection. Responses stating that the suggested change will be made at a later date (but before the JSR or Maintenance Release is finalized) are permissible; in these cases the issue should be kept open until the change has actually been made. The issue-tracking mechanism must make a clear distinction between open, responded-to, and closed issues so the EC can clearly judge whether the EG has met its obligation to respond to all issues.

        EC members, when voting to approve a JSR's advance to the next stage, should take into consideration the EG's responses to comments, and may insiste that a suggestion or issue the EG considers resolved be re-addressed before the JSR moves on.

        Show
        pcurran added a comment - This comment replaces the last one (I didn't notice that the following section (0.0.3) addresses response to comments. Please replace sections 0.0.2 and 0.0.3 with this new section 0.0.2 Issues must be tracked through a publicly readable issue tracking mechanism. Formal comments must be entered into the issue-tracker, and all open issues must be responded to publicly before the JSR moves to the next stage. If the EG decides to reject a suggested change then the response in the issue-tracker must include a rationale for rejection. Responses stating that the suggested change will be made at a later date (but before the JSR or Maintenance Release is finalized) are permissible; in these cases the issue should be kept open until the change has actually been made. The issue-tracking mechanism must make a clear distinction between open, responded-to, and closed issues so the EC can clearly judge whether the EG has met its obligation to respond to all issues. EC members, when voting to approve a JSR's advance to the next stage, should take into consideration the EG's responses to comments, and may insiste that a suggestion or issue the EG considers resolved be re-addressed before the JSR moves on.
        Hide
        eduardo added a comment -

        The suggested change has been implemented.

        For review before closing.

        Show
        eduardo added a comment - The suggested change has been implemented. For review before closing.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: