@lara @johan @jwiegley @dralves @diegop @Arthur @skilesare
As I was trying to write out a proposal to pitch as a new topic in the governance category, I realized that I want to go through one more round of feedback from you here first. It’s a proposal shaped from the ideas that you all have presented in this thread. What do you think? Do you see any technical difficulties? Does it still meet the design intent of the voting mechanisms with minimal changes? A proposal framed in this way would redefine Current Voting Result and would introduce a new calculation of Projected Voting Result.
Proposal
- Do not execute Follower votes immediately…only include votes that are cast manually in the calculation of Current Voting Result.
- Create a new Projected Voting Result calculation that accounts for all manually cast votes and all Follower votes that result from liquid democracy.
- In the Wait for Quiet algorithm, define the “trend” and make algorithmic decisions based on the Projected Voting Result.
- At the conclusion of the voting period, execute Follower votes. Afterward, the Current Voting Result will match the Projected Voting Result.
- In the NNS app and on dashboard.dfinity.org, display both Current Voting Result and Projected Voting Result
Explanation
This proposal has several implications that I think are desirable, but I’m interested in your feedback.
Current Voting Result will be based on votes that have been cast manually and are not reversible. Projected Voting Result will be a calculation of the result if all Follower votes were cast based on their Followee assignments. By definition, Projected Voting Result will change every time a vote is cast manually. This voting mechanism would force all proposals to be finalized within the 4 to 8 day window of the Wait for Quiet algorithm even if the Projected Voting Result is an Absolute Majority.
When I use the term voting period, I am referring to the total time it takes to execute a proposal vote (inclusive of the Wait for Quiet algorithm) according to the current methodology for how the voting duration is determined. This means the voting period will be anywhere from 4 days to 8 days.
Voters can see the trend of the Projected Voting Results and decide for themselves if they want to cast their vote manually. They will be able to cast their vote manually at any time throughout the entire proposal including after the Wait for Quiet algorithm extends the voting period.
Voters who are not following any other neurons who have voted can still vote at any time throughout the entire voting period.
Neurons that are configured as Followees for other neurons can cast their vote at any time throughout the entire voting period and it will not prevent individual voters from casting their votes manually.
Simple Majority and Absolute Majority will still execute automatically according to Current Voting Results, but Wait for Quiet is based on Projected Voting Result. This ensures that Absolute Majority is only decided prior to the end of the voting period by manual voting instead of liquid democracy. This also enables voters who disagree with a Projected Voting Result to cast their vote manually even if the Projected Voting Result is an Absolute Majority. When they cast their vote manually, it will change the Projected Voting Result and may or may not change the “trend” as per the Wait for Quiet algorithm.
No new timers would be introduced and this proposal maximizes the time for which every voter can vote with their own brain on each proposal, while still ensuring that they can configure Followees when they prefer to allow others to cast their vote for them.
I’m interested in applying this change to Governance proposals, but it could be applied to other proposals as well if you want proposals to be executed consistently across all proposal types. You could use different min/max voting periods for different types of proposals. It works if the min / max is 1 day / 2 days or if it is 4 days / 8 days.
What do you think? Is this feasible? Does it cause you any concerns?