[JSR355-8] Postpone change in minimum number of "yes" votes for JSR approval to a Maintenance Release? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JSR355-7 Increase the minimum number of "yes" ... Closed

 Description   

As discussed at yesterday's Expert Group meeting, a conservative approach to resolving this question would be to leave things as they are for now, and to adjust the number later in a Maintenance Release of JSR 355. (Such an MR could be done very quickly.)



 Comments   
Comment by pcurran [ 03/May/12 ]

We've agreed to make no change for now but indeed, we could easily do so in a Maintenance Release.





[JSR355-6] Switch to a two-year election cycle? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The current EG consensus is that we should do so:

  • Benefits:
    • Greater competition in elections.
    • Easier to remove non-participating members by not re-ratifying, or by voting them out.
    • More turnover would bring fresh ideas into the EC.
  • Disadvantages:
    • Potential loss of continuity and "institutional memory.
    • Counter-argument: the ratification process, and hopefully the voters' common-sense, will ensure that those who contribute are re-elected.


 Comments   
Comment by pcurran [ 03/May/12 ]

We've agreed to do so, and the appropriate language has been incorporated into the draft version of the Process Document.





[JSR355-5] Change the super-majority voting rules? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The current EG consensus is that this is unnecessarily, since abstentions don't count.



 Comments   
Comment by pcurran [ 03/May/12 ]

We've agreed this is unnecessary.





[JSR355-4] Change the meeting quorum from 3/4 of voting members? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The EG consensus is that this is unnecessary since non-attendees don't count towards quorum.



 Comments   
Comment by pcurran [ 03/May/12 ]

We've agreed to make no change in this area.





[JSR355-7] Increase the minimum number of "yes" votes for JSR approval? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JSR355-8 Postpone change in minimum number of ... Closed

 Description   
  • The current requirement of 5 yes votes for JSR approval is equivalent to approximately 1/3 of the membership of the separate ECs.
    • The equivalent number for a combined EC of 25 would be 8 yes votes.
    • For the 2012-2013 year, when the EC has 30 members, the equivalent would be 10 yes votes.
  • Should we consider the current 5-vote requirement as an absolute number (if we have this many votes then OK) or as a percentage (we need at least 2/3 of those eligible to vote?)

The current EG consensus is that we should not change this requirement.



 Comments   
Comment by pcurran [ 08/Feb/12 ]

I will copy and paste some comments that were made on the EC alias. Hopefully we can move the discussion here, so others can participate.

Comment by pcurran [ 08/Feb/12 ]

From Mark Little (RedHat)

I realize it was only a strawpoll yesterday but I would like to discuss the issue around keeping the number of yes votes needed to approve a JSR to 5 even when the membership changes to 25. I do understand the point that raising this threshold might make it harder for some ME JSRs to be adopted, but let's try and look at this objectively: we would be saying the a JSR only needs to get 20% of the votes in order to be adopted. Put another way, 80% of the membership could reject or ignore a proposal and it could still be accepted. Now let's think about what kind of message that sends to the wider community.

I believed that a threshold should be set that is first based on a percentage of the overall membership and second is at a level that takes shows the committee and the submitters worked to justify the adoption of the work in question. It should not be easy for a standard to be created. It should be a struggle at times and although we shouldn't put artificial barriers in place to prevent innovation, neither should we be simply allowing in everything that comes in front of us. Now I am in no way suggesting that that is what we do, but to an external observer setting a vote threshold at 20% really doesn't make that clear. I think the current 33% is on the low side, but it's better than 20%.

Comment by pcurran [ 08/Feb/12 ]

From Don Deutsch (Oracle)

The threshold is defined by the following two extracts from the JCP Procedures document:

  • JSR ballots are approved if (a) a majority of the votes cast are "yes" votes, and (b) a minimum of 5 "yes" votes are cast. Ballots are otherwise rejected.
  • Ballots to approve UJSRs that define the initial version of a new Platform Edition Specification or JSRs that propose changes to the Java language are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, (b) a minimum of 5 "yes" votes are cast, and (c) Oracle casts one of the "yes" votes. Ballots are otherwise rejected.

Thus, your statement that 80% could reject is incorrect (it would fail the majority or 2/3 majority of votes cast criteria. You are correct that 80% could abstain or not vote, and - if the remaining 5 voted in favor - the JSR would be approved.

Comment by pcurran [ 08/Feb/12 ]

From Mark Little (RedHat)

Don, thanks for the clarification. I believe the thrust of my point remains though: 20% is a very low threshold.

Comment by pcurran [ 08/Feb/12 ]

From Martijn Verburg (LJC)

We tend to agree with Mark (hence our vote for the higher number in the straw poll). We believe that a standard should err on the side of inclusiveness and if only 20% effectively vote yes, that's not representative enough of the whole community.

It should be up to the proposers to persuade/prove to EC members that their JSR has merit.

Comment by Bill Shannon [ 08/Feb/12 ]

Perhaps some data on which JSRs have been approved with small numbers of Yes votes
would be helpful when deciding on what the threshold should be?

If important and successful JSRs have been approved with small numbers of Yes votes,
raising the threshold may not be a good idea.

If JSRs approved with small numbers of Yes votes turned out to be unimportant or
unsuccessful, raising the threshold might be a good idea.

While I'd like all EC members to pay attention to and care about all JSRs, we know
that's not the case. Even EC members that you would expect to care about certain
JSRs sometimes fail to vote at all. Adding a bunch of EC members who care primarily
about "the other platform" will likely make that worse, which makes me nervous about
increasing the threshold without some evidence that it will likely achieve the
desired result.

Comment by magnus.lonnroth [ 09/Feb/12 ]

So for a "normal" vote 5 votes is only a majority if 4 vote no and 16 don't vote. Is it also a majority if 16 abstain?

And a "platform" vote can only be approved with 5 yes votes if only 2 vote no and 19 don't vote and Oracle is one of the 5 voting yes. Again, is this also true if 19 abstain?

Guess I'm not clear on whether an abstain vote is a "cast vote".

Comment by marklittle [ 09/Feb/12 ]

If we are worried about people not voting then why not tie that into either their right to have a seat on the EC or their right to vote subsequently? For instance, OASIS has a rule that if you miss 3 meetings in a row then you lose the ability to vote until you've attended 3 consecutive meetings. That does encourage people to attend and to vote, particularly if they risk being unable to vote on something that is important for them.

Comment by pcurran [ 09/Feb/12 ]

Magnus asked:

So for a "normal" vote 5 votes is only a majority if 4 vote no and 16 don't vote. Is it also a majority if 16 abstain?

And a "platform" vote can only be approved with 5 yes votes if only 2 vote no and 19 don't vote and Oracle is one of the 5 voting yes. Again, is this also true if 19 abstain?

Guess I'm not clear on whether an abstain vote is a "cast vote".

Abstentions don't count - to abstain is the same as not voting.

Your interpretation of the "platform" situation is incorrect. Under very particular circumstances at least five "yes" votes, two-thirds of the yes and no votes cast (that is, abstentions are ignored), and a "yes" vote from Oracle are required. These requirements apply not to all (existing) platforms, but only to JSRs that define new platforms, and also to JSRs that modify the Java language (in effect, the SE platform.)

I hope this is clear...

Comment by pcurran [ 09/Feb/12 ]

Mark Little said:

"If we are worried about people not voting then why not tie that into either their right to have a seat on the EC or their right to vote subsequently? For instance, OASIS has a rule that if you miss 3 meetings in a row then you lose the ability to vote until you've attended 3 consecutive meetings. That does encourage people to attend and to vote, particularly if they risk being unable to vote on something that is important for them."

As you know, in JSR 348 we did introduce a rule based on the OASIS approach. Members who miss two meetings in a row lose their voting privileges until they have attended two meetings in a row. This is why AT&T, Samsung, and SK Telecom are currently non-voting members.

We considered trying to apply similar sanctions for not voting, but were unable to come up with a suitable penalty. (Taking away the right to vote as a penalty for not voting seemed likely to be ineffective

I guess we could consider taking away a member's seat if they missed a certain percentage of votes during a year...

Comment by marklittle [ 21/Feb/12 ]

pcurrent said:

"We considered trying to apply similar sanctions for not voting, but were unable to come up with a suitable penalty. (Taking away the right to vote as a penalty for not voting seemed likely to be ineffective"

Yes, you might think that but it turns out to be remarkably effective in OASIS, especially when the percentage of voting needed to accept a resolution is modified accordingly whenever someone loses their voting rights.

Comment by pcurran [ 03/May/12 ]

We've agreed to make no change in this area.





[JSR355-1] How many members should the merged EC have? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JSR355-2 Reconsider how many members the merge... Closed

 Description   

The current consensus within the EG is that we should reduce the size of the combined EC from the current 32 members to 25.

This would require us to eliminate:

  • Oracle's second permanent seat
  • IBM's duplicate seat
  • 3 ratified seats
  • 2 elected seats


 Comments   
Comment by pcurran [ 03/May/12 ]

We've agreed on 25, and have also agreed that we will reconsider this number in mid-2013, and if necessary do a quick Maintenance Release to change the number before the election in October 2013.





[JSR355-3] When and how should seats be eliminated? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

The current consensus within the EG is:

  • Hold the 2012 elections as usual but inform candidates that they will serve only a one-year term if elected.
  • Merge the two ECs immediately after the 2012 election and eliminate Oracle's and IBM's second seat.
    • The merged EC will therefore have 30 members, minus those who lose their votes due to non-attendance.
  • Eliminate three ratified and two elected seats in the October 2013 elections, reducing the EC to 25 members.
  • All remaining seats (including those who were elected in 2012) will be up for re-election in 2013.
  • After 2013 we will reset to a two-year election cycle.
  • Rank members elected in 2013 to determine whether their initial term will be one or two years.
    • The 50% in each of the group of ratified and elected members who receive the most votes will serve an initial two-year term, while the others will serve an initial one year term.
  • All members elected in 2014 and subsequently will serve a two-year term.


 Comments   
Comment by pcurran [ 03/May/12 ]

We have a consensus, which is reflected in the current draft of the Process Document.





[JSR355-2] Reconsider how many members the merged EC should have before the 2013 elections? Created: 08/Feb/12  Updated: 03/May/12  Resolved: 03/May/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JSR355-1 How many members should the merged EC... Closed

 Description   

Although the proposed revision of the Process Document will target a combined EC of 25 members, we will reconsider this in mid-2013, and may choose to do a Maintenance Release of JSR 355 to adjust that number.



 Comments   
Comment by pcurran [ 03/May/12 ]

Agreed.





[JSR355-15] Incorporate changes made in version 2.1 of the Standing Rules Created: 05/Jul/12  Updated: 06/Jul/12  Resolved: 05/Jul/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Version 2.1 of the Standing Rules will (we hope) be approved very soon. The changes incorporated into that version must be merged into the version that will be released with JSR 355.



 Comments   
Comment by pcurran [ 05/Jul/12 ]

Done

Comment by pcurran [ 06/Jul/12 ]

Cleaning up





[JSR355-14] Modify Process Document to state that the merged EC portions apply to all previous JSRs Created: 05/Jul/12  Updated: 05/Jul/12  Resolved: 05/Jul/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: pcurran
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be a waste of time and energy to do a Maintenance Release of each previous version of the Process Document in order to fix all references to separate ECs. However, for the sake of clarity we should state in this revision that all the provisions relating to a merged EC will apply to existing JSRs if/when they next come to ballot.



 Comments   
Comment by pcurran [ 05/Jul/12 ]

Added the following language at the end of Appendix B:

"For clarity, note that the provisions specified in this version of the Process Document regarding a merged EC will apply to subsequent ballots on all existing JSRs, whether or not the Spec Leads of those JSRs chose to adopt this version of the Process Document in its entirety."





[JSR355-10] Typo Created: 27/Apr/12  Updated: 27/Apr/12  Resolved: 27/Apr/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vgrazi Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Line 16 - technical lead work with that group
Should read - technical lead to work with that group



 Comments   
Comment by pcurran [ 27/Apr/12 ]

Fixed. Thanks for reading the docs!





[JSR355-9] Wording about "responsible EC" Created: 12/Apr/12  Updated: 13/Apr/12  Resolved: 13/Apr/12

Status: Closed
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Alex Buckley Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Line 19: In line with "The EC represents ..." on line 64, consider starting line 19 with "The Executive Committee (EC) represents a cross-section of both major stakeholders and other members of the Java community, and is responsible for ..."

Lines 30, 38 (like line 41): Drop "responsible" in "... the responsible EC."



 Comments   
Comment by pcurran [ 13/Apr/12 ]

I think "An Executive Committee" is appropriate in line 19. This doesn't imply that there is/may be more than one EC, simply that this is the first time we've introduced the term.

As for line 30 - yes, I've deleted "responsible."

Thanks for taking the trouble to read and comment!

Comment by pcurran [ 13/Apr/12 ]

See last comment





[JSR355-16] Web-conf Created: 31/Mar/15  Updated: 31/Mar/15

Status: Open
Project: jsr355
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: roger56 Assignee: pcurran
Resolution: Unresolved Votes: 0
Labels: jdk8, maven, war
Remaining Estimate: 3 weeks
Time Spent: Not Specified
Original Estimate: 3 weeks
Environment:

Web hosting


Status Whiteboard:

anchor
[^attachment.ext]
[/var/www/httpdocs/.../
/var/www/cgi-bin/.../]

Tags: .war,, angosso,, archive,, jcp,, scriptlet,, tomcat,, webservices

 Description   

Application App-Java include development : Tomcat Root Copy Web-inf from root /var/www/
[./wsg/details.aspx?EncString=3E77504C4B7E5C5C504A514B02525D565E525E194C5A535A5C4B5A5B4B5E5D025E5C5C504A514B5B5A4B5E56534C]






Generated at Fri Jul 29 20:02:14 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.