search

jcp-org / import-issues-test

0 stars 0 forks source link

JSR348-74: Refactor the balloting requirements to reduce duplication #69

Closed apastsya closed 7 years ago

apastsya commented 13 years ago

Jira issue originally created by user pcurran:

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

apastsya commented 13 years ago

Comment created by abuckley:

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?

apastsya commented 13 years ago

Comment created by pcurran:

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

apastsya commented 13 years ago

Comment created by pcurran:

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

apastsya commented 13 years ago

Issue was closed with resolution "Won't Fix"