[JCPNEXT4-12] Voting change to provide protection against unqualified candidates Created: 21/Sep/11  Updated: 06/May/14  Resolved: 06/May/14

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

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


818-822 - It would be simpler to allow each member to vote yes or no on whether each candidate should hold a vacant seat. The candidates who get a simple majority of "yes" to "no" votes will get seats in order of who received the greatest proportion of yes to no votes. Should not all seats be filled but candidates remain because they did not receive a majority, that suggests a vote of no confidence for those candidates and the seats should not be filled. This prevents situations with marginal candidates, such as where there are two candidates, two seats, and candidate two gets only one vote but still gets a seat.

PC> Interesting suggestion, and far too late for this JSR. I suggest we factor this into the "EC merge" JSR. Please log a separate issue to ensure that we don't forget it.

Comment by pcurran [ 21/Sep/11 ]

Sorry - no need to log a separate issue - this one will do. We'll defer it (haven't yet figured out how to tag issues as deferred - and will definitely take it up again since c,early it deserves further consideration.

Comment by pcurran [ 06/Jul/12 ]

Too late now for the EC Merge too (sorry about that.)

However, it's still an interesting suggestion. I'm moving this issue to the newly-formed JSR 358 project, for consideration in that JSR.

Comment by jpampuch [ 06/May/14 ]

The current number of EC candidates and the size of EC voting population is such that this should not be a problem. Further, one of our goals is to increase membership. This change is not necessary at this time.

Comment by heathervc [ 06/May/14 ]

addressing with Elections Proposal in Issue #4.

Generated at Sat Oct 01 03:38:59 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.