[JSR348-74] Refactor the balloting requirements to reduce duplication Created: 16/Aug/11  Updated: 22/Sep/11  Resolved: 22/Sep/11

Status: Closed
Project: jsr348
Component/s: Process Doc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


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



 Comments   
Comment by Alex Buckley [ 16/Sep/11 ]

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?

Comment by pcurran [ 19/Sep/11 ]

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

Comment by pcurran [ 22/Sep/11 ]

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

Generated at Fri Dec 09 05:26:42 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.