The DAO's approach to multiple-choice voting

There’s been a lot of discussion throughout the voting period for EP2.2.5 over the selection of voting process.

I’m personally firmly of the belief that first-past-the-post is a terrible choice for voting due to the spoiler effect, and I believe that’s well established by research and practice. However, there’s still a lot of scope in choosing a system to replace it.

For EP2.2.5, we used Instant-Runoff Voting, which requires each voter to rank their choices in order. I believe this gives us a good representation of peoples’ preferences and leads to a fair election, but there are legitimate critiques that it is not as transparent as it could be, and that it can produce unintuitive results.

@carlosdp linked to this excellent explainer post on voting methods, which demonstrates an interesting failure case of IRV:

Under Instant Runoff, it’s possible for a winning candidate to lose, by becoming more popular . What a glitch!

This is expected to happen as much as 14.5% of the time, shockingly. I’ve run some experiments myself and am fairly confident that it couldn’t have happened for EP2.2.5; there’s no way for voters to downrank their preferred candidate, causing it to win where it previously lost. The existence of this issue raises concerns with using IRV for future votes, though.

The post also describes several other voting systems, including approval voting and score voting, which both score highly on simplicity and fairness scales. Snapshot supports approval voting but not weighted voting - though we could of course add support for that via a PR.

I’d encourage everyone to read the post, and I’d welcome input on how we should conduct ranked votes going forward.

3 Likes

They don’t support score voting (which I think you meant here). Thought I’d mention, they do support weighted voting, as in allocating different amounts of your total votes to different options. Cabin DAO famously uses it

Yea I think it’s worth a discussion for future votes. Even though this vote wasn’t subject to this “glitch,” it stands that one property of RCV is it’s definitely difficult for laypeople to understand how a vote result was achieved in their heads (although your diagrams were really helpful, gotta say!). So even if it captures preference correctly, it doesn’t do a great job at the second important attribute of a voting system: establishing confidence in the legitimacy of the result.

I like approval voting or score voting as an alternative to try. It avoids the spoiler problem, but is still simple to reason about!

2 Likes

I agree with the above.

Personally have always hated RCV because there is no real weight given to the choice preferences and for a RCV vote to be cast all choices have to be cast even though some of them I don’t want to just give a 0 weight but a negative weight.

It is why I think one last more vote should be done regarding Karpatkey being chosen for being the sole and single ENS Treasury manager to remove all questions on the results of this vote.

A new poll.

“Whether ENS should use Karpatkey for exclusive Treasury Management” Yes, No, Abstain

should be conducted to eliminate all questions of which way ENS should go on what I consider to be probably one of the most important issues for the DAO, not just what to do with treasury funds but WHO is going to be trusted to do it.

1 Like

That’s true of Snapshot’s current implementation, it’s not necessarily true of RCV in general. It is possible to allow people to choose only options they want, and have their vote count as “no confidence” if their choices are eliminated. In that scenario, if none of the choices are able to achieve a majority of votes, the vote would fail with no confidence.

That didn’t happen here, though. The way the vote played out, None of the Above worked as intended. So while we don’t know if the fact Snapshot forced everyone to choose to rank affected people’s votes at all, it was possible for people to express an accurate vote and it seems to have been counted. If None of the Above had been eliminated, then yea the results would have been wonky in the current Snapshot implementation and not a good result.

I don’t think that’s necessary, given the above. Also, we’ll still need to vote on-chain for the actual implementation of a proposal, so there’s still opportunity for the DAO to weigh in again (this time with simple majority, since that’s how it works on-chain). If the vote really was affected by the forced ranking, you could expect that vote to fail (assuming people don’t flip opinions in the meantime).

1 Like

I am very much in favor of weighted voting and would like to see it trialled in the upcoming steward elections (and probably used for most votes going forward). For anyone unfamiliar, here’s how it would work: A delegate would select how many votes are assigned by selecting a percentage for each option.

A delegate with 1500 votes choosing between four options and will assign a percentage to each option:

Option 1: 50%
Option 2: 25%
Option 3: 15%
Option 4: 10%

The 1500 votes are then assigned to each option based on the chosen voting percentages:

Option 1: 50% = 750 votes
Option 2: 25% = 375 votes
Option 3: 15% = 225 votes
Option 4: 10% = 150 votes

This gives a more accurate idea of how Delegates weigh each decision. Ranked choice voting makes the assumption that someone ranking between various options is equally fine with the subsequent choice if the first/current choice is not available.

With weighted voting a lot more information is communicated. For instance, we would know that a person may not want one option over another because they would choose 0% and increase the weightings for the other options.

I don’t know the extent to which this voting method would have changed the outcome of the vote in EP2.2.5, but I know that it would have given us a lot more information about how Delegates weigh their choices.

1 Like

Fwiw, I’m not a huge fan of weighted voting:

  • Percentage allocations of votes are often super arbitrary (like, how does one decide to put 35% vs 33%, etc.)
  • Adds a new layer of decision paralysis to voters, who already hate voting :sweat_smile:

I think the Score Voting method @nick.eth brought up could be a good in-between!

1 Like

My problem with the voting was mostly that the current implementation of RCV, by process of elimination (I’m call that one IRV) it’s confusing, hard to visualize and hard to predict. It makes therefore a bad voting scheme. I’ve just published a thread about it:

I also don’t believe we need to run another vote on the Endaoment, because I don’t want to throw shade in the governance. There will still be another vote when we finalize the endowment with precise allocations, at which point we could add a NotA option.

There’s another more serious glitch that I uncovered that is a lot more obvious and it did happen in the process: because the preferences of the second largest vote is never counted, there’s always a chance that if there’s a third, less polarizing and more agreeable candidate which would be preferred by all but gets eliminated too soon. See the example of this happening in this thread:

This actually happened during the vote. There was a brief moment in which Avantgard was the winner, even thou that Karpatkey was preferred by 60% of the voters (part of them were voting for nota). It means that if people who voted NotA + KK changed their vote to a more strategic KK + NotA then Karpatkey would win. Not needing to have strategic votes is precisely what RCV is supposed to fix! I’ve actually changed my vote, which was leaning towards AG because I preferred KK as the Condorcet winner.

I would instead suggest that on our next vote we keep using Ranked Choice voting but with two changes:

  • Allow people to rank only these who the want to rank
  • Use Condorcet method for results

Condorcet simply runs a simulated run off election between every pair of candidates and then picks the one that is able to win all (or the most) elections. If there’s not a clear Condorcet winner I would suggest simply picking the candidate who picked up the most votes on these pairwise elections.

Here’s the Condorcet analysis for the current vote, as well as the sum of their percentages:

Condorcet is not complicated. You don’t need to have complex Sankey charts (which wouldn’t even fit in Snapshot’s right sidebar!). Instead snapshot could show the current results as simply a series of elections on the sidebar. It’s also better at helping anyone look at the current state of the vote: one can clearly see how many votes would be needed to flip one race or the other. In fact I would argue it’s so simple that in the coming weeks at least a billion people will look at a series of such races, in the form of World Cup Group Stage.

It depends on the nature of the vote. When it comes to choosing between potential candidates in steward elections, weighted voting makes a lot of sense. To your points, I’m not suggesting that it would be perfect, but it should be trialled to see what problems arise, if any. We have enough information on ranked choice voting at this point to know what the issues are with that method.

Score-based voting would only make sense if you wanted to give something a score. I don’t see how that would make sense to score potential stewards in this way, but it could definitely be used for other votes.

Score-based voting could have been used for EP2.2.5 to determine the best option out of three, but NOTA couldn’t have been included, which I think provided important feedback in the context of the vote.

You have far too much faith in the voting masses lol. I think we can objectively call it “complicated” for people to reason about in their heads when calculating a result requires an O(n log(n)) calculation :sweat_smile:

Putting that aside, though, part of the reason Condorcet isn’t used by any governments is because of that property (which you pointed out, briefly occurred in this intermediate vote) where there’s a good chance there’s no result because there isn’t a “perfect candidate.”

(from the Nicky Case article)

So if we used it for the steward elections, for example, there’s a very good chance we simply fail to elect any stewards for a working group, or not fill all the seats, in which case how would we handle it from there? Even if we came up with using Borda for a runoff or something, seeking “perfection” in voter expression now vastly increases the complexity of achieving a result.

And I can’t stress how much people hate voting. You gotta make it simple to do, and simple to understand. That’s priority 1, in my opinion, if you want people to be engaged.

No, that’s not how Score Voting works. You give options a score (let’s say 1-5), and the winners are chosen based on the highest average scores – simple as that.

Yea that’s fair, it’s not immediately obvious how to handle “no confidence” in this method.

Still think Weighted Voting would result in three camps:

  • Governance nerds choosing non-sense values, because they can (in the Cabin DAO example, wtf does “91.3% Yes, 8.7% No” even mean?)
  • Engaged voters doing 100% or equal votes on options anyways
  • Everyone else closing the tab because they can’t be bothered

That said, I think whatever we choose, based on feedback I’m hearing from people, critical thing is we have to let people not rank/score/weight every single choice.

For whatever the information may be worth, Stack Overflow and its associated network of Q&A sites elect moderators (sometimes more than one per election) using OpaVote with the Meek STV method; here is a recent example. Voters do not have to rank all choices if they do not wish to express any preference among unranked candidates.

1 Like

Understand how it works. Re the steward elections, my position is that it is socially undesirable and in my mind inappropriate to score people in the same way that you might score ideas. When someone puts their name forward to be a steward, it is socially awkward to then have delegates score those people. When you score something, there has to be a reason for assigning a score. I suspect many delegates will feel uncomfortable scoring people, which may lead to lower delegate participation. It would also potentially make it harder to get people to put their names forward, which is already a challenge.

Completely agree.

Gotcha, yea that’s fair, but isn’t that the case with Weighted Voting too?

One other thing I want to throw into this discussion, since it’s been mentioned a few times that certain methods are better for certain kinds of decisions (which is true): if we don’t have 1 vote method, who decides the method for each (social) proposal?

Cause being able to determine the method is clearly very powerful in and of itself, so it’s a little weird for it to be the proposer, or a single working group (which is basically how it’s been done thus far in our infancy, since we haven’t formally hashed this out yet as a DAO).

edit: Actually, RCV is specified in the WG rules (EP4 w/ amendment) for steward votes, so above is only correct for non-steward votes

My view is that voting for someone by way of assigning a percentage of votes, is a fundamentally positive act. Anyone who receives a vote is receiving a vote of confidence. If a delegate doesn’t know/like a particular person, they will likely ignore that person.

With scored voting, socially negative acts may occur – delegates are more likely to give individuals low/average scores. While a low/average score is still added to a person’s total, it feels far less socially desirable and to the extent that we are trying to encourage candidates to put their names forward, it is not something we should run towards.

Again, this is just my view with respect to steward elections where I think it’s important to remove as much friction as possible and make the process as positive as possible. It might be useful to run a dummy vote in the near future and trial different voting methods and get delegate feedback.

As you point out, anyone who creates a social proposal can choose the voting method. In the short term, I don’t see this as a problem. Once we have trialled more voting methods, we can formalize the voting processes for different types of votes in a set of governance rules. I personally don’t see the need to rush the formalization of these rules.

I removed the requirement to use ranked choice voting in WG elections in EP1.8 (previously EP12), so different voting methods can be used for the election of stewards.

I am quite confident I can make a design for a Condorcet method that would fit in a tweet or the sidebar of snapshot (can’t do it now, on my phone). As for not having winners that is not true: there are many types of Condorcet compliant implementations: minimax, schulze, ranked pairs, all of which will always select a single winner.

As I said, the World Cup first stage is basically a reverse Condorcet: but instead of ranking candidates and then figuring that it how they win pairwise, countries have to play against all of the competitors in the group and then they get a ranking. Over a billion people understand it without any issue.

I don’t think weighted voting works very well. The naive approach is to assign 100% of your votes to the person you want most to win, in which case it becomes first-past-the-post. In fact, it can be thought of as first-past-the-post, but you get to cast each of your (many) ballots separately.

The strategic option would have you trying to guess how much each of your preferred candidates is losing by, and assigning them just enough votes to get them over the threshold, unless they’re too far behind in which case you assign none. I don’t think this kind of meta-game leads to good outcomes reflective of peoples’ actual desires either.

I’d personally prefer either score voting or approval voting. I don’t like the fact that approval voting doesn’t let me state preferences - in the recent vote I would have had to choose between endorsing a second-favorite option so my vote counts, or not endorsing it and risking a much less preferred option wins - but it’s a lot better than FPTP and very easy to explain.

My concern is that the condorcet-based schemes seem harder to explain to people than IRV was.

You might be right. I’m not married to any voting method and we obviously don’t know how it will play out until it is implemented. I think scored voting makes a lot of sense in many instances, but much prefer approval over scored for steward elections if we are going to make a move away from ranked choice.

1 Like

Took it as a challenge to present the results of a Ranked Pair voting that is almost self explanatory and would fit in either a tweet or the sidebar of Snapshot:

As you can see, while wikipedia might use complex pentagram arrows to explain each method, we can simplify them a lot. All votes are arranged in pairs, and the winner of each pair gets a trophy. Candidate with more trophies win. Ties are broken by candidates with most votes total.

We could also add the option to hide the running pairs and just show the end result. Ranked Pairs has some other edge cases, like: “Lock in” each pair, starting with the one with the largest strength of victory and, continuing through the sorted pairs, add each one in turn to a graph if it does not create a cycle in the graph with the existing locked in pairs. The completed graph shows the winner." which basically means: in some cases you can win a game but not get a trophy because you’re too low on the rank. But mostly the system would be quite self explanatory and we would be able to have live results on Snapshot.

A curious note is that I found that solution almost independently from the point of view “what is the better way to visualize this data”, and I arrived at the conclusion that the best would be to pair wise it and then count the wins. Only then I found this was the Condorcet method. I think that points to the fact that this could be, in fact an easier method to understand it.

(updated image by switching trophy to medals)

1 Like

I’m not sure I’m as convinced this isn’t at least something that can become a problem within <= 5 social votes, let’s say. My most recent evidence is the fact half the discussion around this recent proposal was on why RCV was chosen.

I’ll be honest, I didn’t notice the amendment did that, and looking back at the threads for that proposal there seems to have been 0 discussion or mention of that particular change, so it seems like a lot of us just didn’t read the Terms of Service on that one lol :sweat_smile: Especially since at least one of the remaining provisions still assumes there is some sort of ranking-based method being used:

Screen Shot 2022-11-23 at 5.03.51 PM

I think this is definitely something we should seek to re-introduce into the rules in the short-term, with whatever method the DAO chooses. Presumably, in lieu of a DAO-set rule, those very representatives are the ones deciding on the election method! That can lead to a bad negative feedback loop, even without any intentional malice or desire to manipulate a result.

For example, take the last steward elections. I myself was second if you did First Past the Post on the first round ballot, Simona was eliminated. But, because it was RCV, I ended up not being chosen at all, and Simona came out on top when it was all resolved.

If this were the next election, and I were on MetaGov or otherwise part of the informal committee that chooses the vote method, maybe I could have swayed opinion to instead use FPTP, because I like it better (perhaps because of logic, perhaps because I subconsciously know I can perform better with it). It would have completely changed the result, if we use these sets of votes and nominees.

That’s why it’s important that steward election methods are encoded in the rules and only changeable by DAO-wide vote, even if we keep going ad-hoc for a while on general social proposal rules. Happy to draft and spearhead that amendment myself, once/if there’s a consensus on what method we should be using!

That’s a really nice design!

Look, I can grok it, you can grok it, but we’re both clearly voting system nerds! What I’m saying is, the average ENS voter that only shows up for the Snapshots and looks at the page for like 5 minutes is not going to understand at first glance why “having the most trophies” is a win condition, in this example.

Meaning, they might be able to see where the trophies come from (as your design example does a good job of that), but they aren’t going to understand why Ranked Pairs theoretically achieves a more accurate result than a first-round-only vote by just looking at a UI (and they aren’t going to look it up, we don’t get to have that much of their time).

The core thing I’m trying to advocate is that when it comes to voting systems with humans, no amount of nerd-snipe gets you a perfect result – all you can do is chose which imperfections you want to deal with. The most important attribute when the votes are tallied is that every person that voted can understand how their vote factored in to the result, and that they can mentally see why their side lost fair-and-square. I think any iteration of RCV does very poorly in that criteria.

I agree that Approval would likely be my vote for the one to try next given what’s been discussed here!

2 Likes

I’ve shown to a few people (twitter, may wife) and everyone was able to grasp the basics. Maybe not every detail on how ties are done, but I don’t need people to nerd out about the specifics of a voting method. I want users to understand very few things:

  • How do I vote: this is identical to the current method which has worked so far
  • How are winners selected. This gives legitimacy to the process. They don’t need to understand why it’s like this, or how ranked pairs are chosen, just to get the gist of “you get medals you get points”

It does not surprise me that you have some Twitter followers that are able to grasp the concept. I don’t think that comes close to even suggesting the average ENS voter would be able to do the same, though.

Even some of the most competent and experienced delegates confidently claimed things about this recent vote result that were clearly incorrect, and IRV is more straightforward!

I’d say they absolutely need to understand why the result makes sense. The reason this thread even exists is because people don’t understand why the IRV result is correct, and that partially overshadowed the proposal itself :confused:

1 Like