jsr348
  1. jsr348
  2. JSR348-74

Refactor the balloting requirements to reduce duplication

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Component/s: Process Doc
    • Labels:
      None

      Description

      Alex Buckley says:

      "Duplication is the bane of a narrative spec, so I'm delighted to see standardized language for balloting in 1.3 (2nd para) and 3.4 (2nd para). 4.2 comes close. 5.2 could come close if the will of the 348 EG is to simplify Maintenance. Propose extracting the process of balloting into a new subsection, then "invoking" that process with parameters (length, what happens if revision received, etc) in 1.3, 3.4, 4.2, 5.2."

        Activity

        Hide
        pcurran added a comment -

        Having received no further input from the submitter I'm closing this issue,

        Show
        pcurran added a comment - Having received no further input from the submitter I'm closing this issue,
        Hide
        pcurran added a comment -

        Re:

        As part of extracting a common reconsideration process, please consider the paragraph of 1.3 JSR Deadlines that starts "If the JSR Renewal Ballot fails".

        Does the clause "If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 5)." apply only if the EG does not submit a revision within 30 days (wherein the JSR is closed), or only if the EG does submit a revision but the Reconsideration Ballot fails, or both?

        ==================

        The latter. I've fixed this by re-wording. I don't see that this demonstrates the need for "parameterizing" the balloting logic.

        This was discussed at the September f2f meeting and the consensus was that such a refactoring is unnecessary.

        If you'd like to pursue this, please propose specific changes, otherwise we'll close this as "will not fix."

        Thanks...

        Show
        pcurran added a comment - Re: As part of extracting a common reconsideration process, please consider the paragraph of 1.3 JSR Deadlines that starts "If the JSR Renewal Ballot fails". Does the clause "If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 5)." apply only if the EG does not submit a revision within 30 days (wherein the JSR is closed), or only if the EG does submit a revision but the Reconsideration Ballot fails, or both? ================== The latter. I've fixed this by re-wording. I don't see that this demonstrates the need for "parameterizing" the balloting logic. This was discussed at the September f2f meeting and the consensus was that such a refactoring is unnecessary. If you'd like to pursue this, please propose specific changes, otherwise we'll close this as "will not fix." Thanks...
        Hide
        Alex Buckley added a comment -

        As part of extracting a common reconsideration process, please consider the paragraph of 1.3 JSR Deadlines that starts "If the JSR Renewal Ballot fails".

        Does the clause "If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 5)." apply only if the EG does not submit a revision within 30 days (wherein the JSR is closed), or only if the EG does submit a revision but the Reconsideration Ballot fails, or both?

        Show
        Alex Buckley added a comment - As part of extracting a common reconsideration process, please consider the paragraph of 1.3 JSR Deadlines that starts "If the JSR Renewal Ballot fails". Does the clause "If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 5)." apply only if the EG does not submit a revision within 30 days (wherein the JSR is closed), or only if the EG does submit a revision but the Reconsideration Ballot fails, or both?

          People

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

            Dates

            • Created:
              Updated:
              Resolved: