[ALAC] Explanation of RoP Director voting alternatives

Alan Greenberg alan.greenberg at mcgill.ca
Wed Jun 15 17:26:12 UTC 2016

As I said, I think that option 2 will lead to 
strategic voting where the supporters of the 
leading candidate may vote for the WEAKEST 
candidate instead of for their preferred choice 
(among the two), and I believe that in the final 
race, we should have the two strongest candidates against each other.

You are correct that option 1 brings the leading 
contestant in, but option 2 allows the electors 
who support this candidate to vote (since we could not exclude them!)

But clearly others have a different views. Makes life interesting!


At 15/06/2016 12:22 PM, Seun Ojedeji wrote:

>I would agree with Tijani's option as well, for 
>similar reason; I think it's just fair not to 
>bring the leading contestant in the tie breaking 
>process between 2 other contestants.
>Sent from my LG G4
>Kindly excuse brevity and typos
>On 15 Jun 2016 16:59, "Tijani BEN JEMAA" 
><<mailto:tijani.benjemaa at topnet.tn>tijani.benjemaa at topnet.tn> wrote:
>Hi Alan,
>My inclination is to option 2. I find it more 
>logical and preserve the right of the candidate 
>with the best score. I think that the first vote 
>is done without side consideration, means that 
>each electorate member will vote for their 
>preferred candidate, and its result is the more 
>relevant with the electorate choice. So, it’s 
>fair to respect it and keep the candidate with 
>the best score and rerun the vote to break the tie between the tied candidates.
>Executive Director
>Mediterranean Federation of Internet Associations (FMAI)
>Phone: <tel:%2B216%2098%20330%20114>+216 98 330 114
>           <tel:%2B216%2052%20385%20114>+216 52 385 114
>>Le 10 juin 2016 Ã  22:22, Alan Greenberg 
>><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca> a écrit :
>>In the Rules of Procedure revision that I sent 
>>a few days ago, there are several options to 
>>one of the voting stages in the selection of 
>>the At-Large Director. The RoP revision group 
>>did not reach unanimity on which option to pick 
>>(largely because of the deadline required to 
>>sent the revision to the ALAC to allow us to 
>>approve the revisions in Helsinki).
>>The options have to do with the reduction of 
>>three candidates to two. In the optimal case, 
>>one of the three candidates will have fewer 
>>votes (or first preference votes) and will be 
>>dropped, resulting in two candidates being 
>>left. The difficulty arises if the two 
>>candidates tie for last place, but with the 
>>leading candidate not receiving an absolute 
>>majority of votes needed to be declared the final winner.
>>Option 1: Re-run the entire three-way election, 
>>with the hope that some positions may have 
>>changed. This would be done just once. If the 
>>second vote results in a tie for the last 
>>position (even if it is not the same pair as 
>>the first time), one of those tied is 
>>eliminated based on a verifiable random 
>>selection. The down side of this method is that 
>>no one may alter their vote and we would have to use a random selection.
>>Option 2: Have a run-off vote between the two 
>>tied candidates. If the results between the two 
>>is tied, a verifiable random selection would be 
>>used to eliminate one of them. The down side of 
>>this option is something called "strategic 
>>voting". Those electors who originally voted 
>>for the leading candidate (the one not in this 
>>runoff) may not vote for the  person they 
>>prefer, but could vote for the one they 
>>perceive as the weakest opponent to their preferred candidate.
>>Option 3: There will be no 2nd vote. One of the 
>>two tied candidates will be dropped based on a verifiable random selection.
>>Option 4: Use the same STV voting as would be 
>>used in the first round (to narrow the slate 
>>down to three). The BigPulse STV system will 
>>always eliminate one candidate, but if it must 
>>resort to a random selection, it would be 
>>internal to the voting system and would not be 
>>verifiable (ie it would have to be trusted to 
>>have used a truly random selection.
>>Since the ALAC will have to decide on a which 
>>option to use, it would be good to begin the 
>>discussion now and not wait for Helsinki.
>ALAC mailing list
><mailto:ALAC at atlarge-lists.icann.org>ALAC at atlarge-lists.icann.org
>At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org
>ALAC Working Wiki: 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/alac/attachments/20160615/90d22f44/attachment.html>

More information about the ALAC mailing list