Please don’t use instant-runoff voting. This is a well-known, but not well-designed, voting system.
Add up everyone’s 1st choice to get a count for each candidate.
If there are more than 3 candidates with any votes, eliminate the least popular, and redistribute those votes according to the voters’ next favourite choice.
Plurality-based systems like this suffer from vote-splitting, which can incorrectly eliminate the most-preferred candidates, especially in elections with many candidates (like this one).
Counting only first-choice preferences is a highly flawed and undemocratic way to count ranked ballots. You’re throwing away most of the preference data that voters expressed on their ballots. 😞
The raw data for last year’s IRV vote are available; that might (or might not) help you make an argument that the voting method is likely to produce a problematic result this year. E.g., someone more skilled at data analysis tools than I could probably figure out if there was any non-winning candidate who won all the pairwise comparisons with all other candidates.
OK I ran the numbers on the raw data. IRV happened to select the correct top 3 candidates, so that worked out OK, but it did not select them in the correct order or proportions (but it’s pretty close, so it doesn’t make much difference in this particular election).
The official results are:
RP: 37.0% = $9484
EAAWF: 32.3% = $8271
SWP: 30.6% = $7844
But when considering all preferences, not just first choices:
SWP was actually the true winner, preferred by 50.3% majority of voters over RP, by 50.9% over EAAWF, by 56.4% over WAI, etc.
EAAWF is runner-up, preferred by 50.2% over RP, by 57.2% over WAI, by 59.8% over THL, etc.
RP is third, preferred by 54.9% over WAI, by 59.2% over THL, etc.
I don’t know of an established way to translate this to proportional winnings, but you might choose to break it up by pairwise margins between the top three, like this:
SWP: (50.9+50.3)/3 = 33.7% = $8636
EAAWF: (49.1+50.2)/3 = 33.1% = $8473
RP: (49.8+49.7)/3 = 33.2% = $8490
The majority preferences between the top three are pretty close to even, so something that evenly distributes money between them seems intuitively correct.
One thing I’d note is that the donation election doesn’t necessarily have the same purposes as a standard political election. Spurring public deliberation and obtaining data on community preferences are probably more important than distributing the specific funds (especially this year with a smaller pot). That may blunt certain criticisms of IRV, or generate new ones that aren’t as salient in a standard political context.
The ability to see running vote totals and change votes—important for user engagement—is also a distinguishing feature.
Yeah, the decision to select the top three candidates and divide funds between them is pretty arbitrary (and unlike a standard political election) but I think most people would agree that counting all voter preferences in that process is better than counting some voters’ preferences while discarding others’.
Please don’t use instant-runoff voting. This is a well-known, but not well-designed, voting system.
Plurality-based systems like this suffer from vote-splitting, which can incorrectly eliminate the most-preferred candidates, especially in elections with many candidates (like this one).
Counting only first-choice preferences is a highly flawed and undemocratic way to count ranked ballots. You’re throwing away most of the preference data that voters expressed on their ballots. 😞
The raw data for last year’s IRV vote are available; that might (or might not) help you make an argument that the voting method is likely to produce a problematic result this year. E.g., someone more skilled at data analysis tools than I could probably figure out if there was any non-winning candidate who won all the pairwise comparisons with all other candidates.
OK I ran the numbers on the raw data. IRV happened to select the correct top 3 candidates, so that worked out OK, but it did not select them in the correct order or proportions (but it’s pretty close, so it doesn’t make much difference in this particular election).
The official results are:
RP: 37.0% = $9484
EAAWF: 32.3% = $8271
SWP: 30.6% = $7844
But when considering all preferences, not just first choices:
SWP was actually the true winner, preferred by 50.3% majority of voters over RP, by 50.9% over EAAWF, by 56.4% over WAI, etc.
EAAWF is runner-up, preferred by 50.2% over RP, by 57.2% over WAI, by 59.8% over THL, etc.
RP is third, preferred by 54.9% over WAI, by 59.2% over THL, etc.
I don’t know of an established way to translate this to proportional winnings, but you might choose to break it up by pairwise margins between the top three, like this:
SWP: (50.9+50.3)/3 = 33.7% = $8636
EAAWF: (49.1+50.2)/3 = 33.1% = $8473
RP: (49.8+49.7)/3 = 33.2% = $8490
The majority preferences between the top three are pretty close to even, so something that evenly distributes money between them seems intuitively correct.
https://forum.effectivealtruism.org/posts/k8NLM6QoEjMkEGEmG/2024-donation-election-results?commentId=9tEzksXPNqH6Gnreo
Thanks!
One thing I’d note is that the donation election doesn’t necessarily have the same purposes as a standard political election. Spurring public deliberation and obtaining data on community preferences are probably more important than distributing the specific funds (especially this year with a smaller pot). That may blunt certain criticisms of IRV, or generate new ones that aren’t as salient in a standard political context.
The ability to see running vote totals and change votes—important for user engagement—is also a distinguishing feature.
Yeah, the decision to select the top three candidates and divide funds between them is pretty arbitrary (and unlike a standard political election) but I think most people would agree that counting all voter preferences in that process is better than counting some voters’ preferences while discarding others’.
The actual raw data is here, by the way: https://docs.google.com/spreadsheets/d/1N3B5bO4EORbokpLyc4Ew5dUmXUVerElN047KBIbOnbM/edit?usp=drivesdk
Thanks, I’ll try to take a look at it.