Base quorum on Yes votes only

[xaur]

Let's explore the idea to base quorum on Yes votes.

Currently, the sum of Yes+No votes must pass the quorum. The quorum and Yes threshold are configurable, but to date only the value of 20% quorum and 60% Yes threshold were used. If expressed in percentage of Yes votes among all eligible tickets, it translates to 12% Yes votes.

The hypothesis is that if the quorum is based on Yes%, people who want to vote No would need to do less guessing and gaming, and would vote more often and more early.

there are some scenarios where it doesn't make sense to vote No. if a proposal has high Yes % but hasn't met quorum requirement yet, No votes will help it to reach quorum requirement but may not decrease the approval % enough to reject the proposal.

someone suggested that we define the quorum in terms of Yes votes only, which makes sense to me. If we defined that requirement as 12% of all tickets voting Yes, it would remove this conflict for people who want a proposal to be rejected and allow them to vote more freely.

I'm coming around to the idea that the confusing incentives that the quorum creates (avoid voting No in case those No votes actually cause the prop to reach quorum and pass when it otherwise would not have) are something we should address by amending the way it works. If we expressed the current rule in terms of Yes votes it would be a requirement that 12% of eligible tickets vote Yes.

Described by @RichardRed0x but suggested by someone else.

Please comment on any downsides of this approach.

Discussions:

• 2019-02-27
• 2019-03-05

[xaur]

I think a table comparing the outcomes of existing and proposed solutions would help illustrate the difference.

[RichardRed0x]

Thanks for capturing this in an issue @xaur, a table comparing outcomes of existing and proposed solutions was my next step but some other stuff came up. I should be able to get it done in the next day or so.

[RichardRed0x]

https://github.com/RichardRed0x/pi-research/blob/master/analysis/voting/quorum-change-examples.md

[xaur]

In continuation of the last chat @davecgh provided some interesting input.

If I understand it correctly, main concern was about lowering the quorum from 20% to 12%, so a proposal could pass with ~5K instead of ~8K votes. I don't see the full picture, but it feels wrong to me as well. Perhaps we should compare the current 20% of Yes+No votes vs 20% of just Yes votes.

Looking at the nice charts from @RichardRed0x's research linked in the previous comment, the only difference between 20% Yes+No and 20% Yes is that the latter removes a part of Approved outcomes. That part is enclosed in a downwards pointing triangle between (8K yes, 0 No; 8K Yes, 5.5K No; 5K Yes, 3K No). Perhaps it is worth to highlight that triangle on the last chart.

Can we interpret what's inside that triangle? It is a space of outcomes below 13.5K total votes where a proposal could pass with certain combinations of 5..8K Yes and 0..5.5K No. Will we lose much if we remove it?

[RichardRed0x]

As you have identified, changing to a quorum defined as 20% tickets voting Yes is strictly a raising of the barrier. There are no proposals which would pass under this new rule that currently fail due to not reaching quorum requirement.

This higher barrier may be an issue if voter participation drops, which seems more likely for smaller scale proposals (like the $750 tutorials proposal, the only one so far that would be affected).

Ultimately, I think it would be best to have a more dynamic threshold, where smaller proposals of lower significance don't require as many votes. My personal preference would be for "small" proposals to have the 12% yes votes cut-off, with "big" proposals at 20% Yes requirement. How to define small/big is another topic though, because sometimes important proposals have small/no budget.

[RichardRed0x]

I added another scenario to the analysis, a requirement based on the Yes - No score, such that it is easier for less controversial proposals to meet the requirement. This one is similar to Dash (which uses this at 10%), I am not advocating for it just thought I would add it since the "modelling environment" is up and running now.

[s-ben]

The new quorum makes sense to me. Enough to warrant an experiment. Would this be something that would need to be put to a vote to stakeholders? Is there enough consensus to try that?

Anyway, looking through the politeia codebase just now, I don't think this will require much (if any) code changes. The tallying and "calling" of a vote is currently done manually. Though we might need to change visualizations of the vote von politeiagui. And of course, once we transition to full automation, logic implementing tallying and verifying votes will need to be coded.

[xaur]

Would this be something that would need to be put to a vote to stakeholders?

Regardless of the vote a good effort will be needed to notify them. Actually I feel many stakeholders might be unaware of some current key elements of voting, e.g. who sets the quorum, threshold and vote duration, and when. These have a huge impact on the vote outcome.

Is there enough consensus to try that?

I don't remember Politeia devs commenting on this anywhere.

[RichardRed0x]

Would this be something that would need to be put to a vote to stakeholders?

That seems right to me, a pi proposal would also help to ensure that stakeholders understand how these criteria are set. I was thinking of submitting a proposal about it, but wanted to get more feedback on where people think the Yes % requirement should be set for the quorum. To me 16% seems to strike a good balance in not making it generally easier or harder for proposals to pass.

[s-ben]

It seems like there was general support in the #proposals (or not strong opposition), but if this gets put up for a vote, I could imagine some contention in the comments; which is good, could help us determine a better number, or consensus against if it exists.

[lukebp]

Closing this due to inactivity. We can reopen the issue if this becomes a serious change request from the stakeholders in the future.