apastsya / jcpnext4

0 stars 0 forks source link

JCPNEXT4-32: Clarify the meaning of the term "conditional yes vote" in the Process Document #28

Closed apastsya closed 7 years ago

apastsya commented 10 years ago

Jira issue originally created by user pcurran:

Section 5.2 of the Process Document uses the term "conditional yes vote". This should be explained. (It means that an EC member voted "yes" with a comment similar to "I'm not voting no now, but I expect issue X to be addressed in the future".)

apastsya commented 10 years ago
apastsya commented 10 years ago

Comment created by heathervc:

We will address this as part of Issue #2 Definitions in JSR 364.

apastsya commented 10 years ago

Comment created by pcurran:

Proposed fix

No need for a formal definition.

On lines 636-627:

Change: "An issue that was referenced in a conditional yes vote during an earlier development stage has not been addressed."

To: "An issue that was referenced in a conditional yes vote (when an EC member voted "yes" with a comment stating the expectation that it would be addressed in the future) has not been addressed."

apastsya commented 10 years ago

Comment created by pcurran:

Suggested text has been incorporated into version 1 of the revised Process Document.

apastsya commented 10 years ago

Comment created by jpampuch:

If this is intended to only apply to maintenance releases, then this issue is complete and can be closed. However, perhaps we want to consider the idea of "conditional yes" for regular reviews as well (perhaps in a future revision.)

apastsya commented 10 years ago

Comment created by pcurran:

It was intended to apply specifically to Maintenance Releases (we're addressing the specific - and deliberately limited - set of circumstances under which it is permissible for the EC to vote "no" on a Maintenance Release). (In earlier versions of the Process Document they had no such veto power, and could only require that a specific change be postponed until a new version of the JSR.

It may well be that an EC member would cast a similar "conditional yes" vote at, for example, Public Review (the Process Doc is silent on this). Under those circumstances that member would presumably vote "no" at Final Release (or a subsequent additional Public Review) if the issue was not addressed.

I believe this is fixed, and will close the issue.

apastsya commented 10 years ago

Issue was closed with resolution "Fixed"