Proposal to Enable Manual Voting Throughout the Entire Voting Period of Governance Proposals

[wpb]

Update: This post has been edited based on feedback from comments in posts 2 - 6 as well as post 14 of this topic.

Summary
This proposal is intended to enable all neuron owners to vote on any NNS proposal with the topic called Governance with their own brains at any time within the voting period even if their Followees have voted. It also enables all Followees to cast their vote at any time.

Introduction
Currently, if a Followee neuron votes, then liquid democracy is executed immediately and all applicable votes for neurons that are following that Followee neuron are cast immediately. Since Difinity Foundation and Internet Computer Association are disabling default following for proposals on the governance topic and the voting rewards will be weighted based on the topic (see NNS Proposal ID 34485), this means people will start looking for other organizations with neurons they want to follow for the specific proposal topic called Governance. It is impractical to expect that organizations will time their votes until the very end of a proposal to allow individuals to vote manually. Therefore, this proposal intends to enable Followee organizations to vote any time they want within the voting period. If individuals vote at any time within the voting period, then this vote is what counts and the votes that would be sent by following are disregarded on Governance proposals.

Proposal

1. Do not execute Follower votes immediately…only include votes that are cast manually in the calculation of Current Voting Result.
2. Create a new Projected Voting Result calculation that accounts for all manually cast votes and all Follower votes that result from liquid democracy.
3. In the Wait for Quiet algorithm, define the “trend” and make algorithmic decisions based on the Projected Voting Result. (See Note below, which is intended to give Dfinity the ability to carefully think about whether the algorithmic decisions should be based on the Current Voting Result instead)
4. At the conclusion of the voting period, execute Follower votes. Afterward, the Current Voting Result will match the Projected Voting Result.
5. In the NNS app and on dashboard.dfinity.org, display both Current Voting Result and Projected Voting Result
   Note: During the realization phase of this proposal, it is acceptable to modify the details if needed to develop a better way to meet the objective of the proposal than what is outlined in the concrete proposal above.

Explanation
In this proposal, 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. Simple Majority and Absolute Majority will still execute automatically according to Current Voting Results, but Wait for Quiet is based on Projected Voting Result (or possibly Current Voting Result, see Note). Projected Voting Result would change when a vote is cast manually if the vote is different than the Followee vote. This voting mechanism would not accept proposals before the end of the voting period unless the Absolute Majority is obtained by way of manual voting. This proposal 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.

For the purpose of this proposal, the term voting period refers to the total time it takes to execute a proposal vote (inclusive of the Wait for Quiet algorithm) according to the applicable methodology for how the voting duration is determined. This means the voting period will be anywhere from 4 days to 8 days due to a recent proposal to extend the wait for quiet algorithm (NNS Proposal ID 33658).

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.

This proposal is only intended to apply to Governance proposals. Application to other types of proposals would be at the discretion of Dfinity if they think there is value.

Timeline
This proposal will be open for deliberation until after the new year before the formal proposal is submitted to the NNS. Comments are appreciated during this deliberation phase and actionable suggestions that improve the design intent of this proposal may be included with the proposal. If this proposal passes, then the desired outcome would be for Dfinity to develop the required code changes quickly, but also give due consideration to the need for a thorough security review. A strict timeline is not imposed with this proposal.

Background
This concept that was shaped by conversation in another topic…Proposal to include cycle_dao & ICDevs as default follow-target neurons to the NNS - #31 by wpb. Please see that comment history for further background information.

@lara @johan @jwiegley @diegop @Arthur @skilesare

[Manu]

Interesting idea @wpb! I definitely agree with your intent that voters should always be able to make up their own mind, even if they follow somebody.

So in your idea, a proposal that reaches > 50% projected voting result (but < 50% current voting result) would not execute by absolute majority yet, right? Do you think that’s an important feature of your proposal?

I ask because I’m thinking about potentially easier ways to achieve your intent, simply because there is so much work to do . One thing that comes to mind is that we could let voters always change their vote (as long as the vote isnt decided yet), possibly even for all proposal types. Then if I’m following someone that voted yes on a proposal that I actually want to vote no on, i can just change my vote manually, assuming the proposal is still open. But in this approach, proposals that reach >50% including follower votes would immediately be adopted. Wdyt?

If this proposal passes, then the desired outcome would be for Dfinity to develop the required code changes and put them forward for NNS approval within 1 month

This of course fully depends on what the proposal actually proposes. For more ambitious proposals this would be completely impossible, but i still think we should allow such proposals. Or if there is one month in which the community comes up with many great proposals that all get adopted, it will be very difficult to get all of that done the next month, but we should still vote in all those great ideas. So overall I’m not entirely sure committing to a timeline is helpful.

[wpb]

Thank you for providing input @Manu. I was definitely hoping to get responses that help better shape the idea and I do think your idea may achieve that goal, especially if it simplifies code changes and is easier to implement.

I think it is acceptable for Absolute Majority to automatically execute as you describe. I expect for Governance proposals it will be very difficult (nearly impossible) to achieve Absolute Majority due to (see NNS Proposal ID 34485). Hence, the scenario where Absolute Majority has been achieved, but people may want to change their vote manually, is not likely to be a credible scenario. Your idea enables proposals that are routine business (everything except Governance proposals) to be executed by Absolute Majority according to the current default Followee configurations, which I think is still a highly desirable feature. Hence, I’m inclined to shape the proposal further according to your suggestion unless someone comes up with a strong argument otherwise.

What would happen if a Followee neuron were to change it’s vote? Would that manual change only apply to the votes in that neuron, or would the entire liquid democracy chain be executed again? Is there any risk of overwriting manual votes by followers if the entire liquid democracy chain is executed?

Is there any reason to limit the number of times a voter can change their vote? Do you see any risk of a large or highly influential neuron swinging the vote multiple times?

I am interested in framing this proposal in a way that enables creative freedom for how to achieve the overall goal, which is to ensure that all governance participants are able to vote according to what they individually believe is in the long term best interest of the internet computer (which will sometimes differ from their Followees). If there is any specific wording that helps achieve that goal then please feel free to offer that text.

Also regarding timing…my hope is that we can make a proposal that will not take too long to implement. I’m open to suggestions on what timing to propose including not including a timeframe. That said, it would certainly be helpful to know when it is practical for this change to be implemented.

[Manu]

What would happen if a Followee neuron were to change it’s vote?

That’s a very good point, I did not think of that. That seems like a big downside, because both changing the follower votes and not changing the follower votes seem odd. @lara curious to hear your thoughts.

[lara]

Thanks for tagging me @Manu and @wpb,
I agree that allowing reverting votes is problematic in different respects and I would be very careful about that.
As you already pointed out there is the question of what this would mean for the followers. Especially, for more complicated following-graphs: “What if a followee’s followee changes the vote?” etc.

However, what I consider even more an issue is the question of how one would even define an “absolute majority” in such a case. You seem to suggest that we would still execute the proposal in case of an absolute majority. But what if there are 51% of voting power in favor of a proposal, we execute the proposal, and afterwards some people change their vote (neurons can still vote until the end of the voting period).
I think this could be very problematic.

So I think it can still make sense to just capture the intent in the proposal and leave it open to explore other possibilities in the realisation phase, but I doubt that this concrete proposal would make things simpler.

[lara]

Thanks for the concrete proposal and for tagging me.

My general feedback is that, as pointed out by @Manu it might be an option to leave some of the details out of the proposal and leave them to the realisation. For example, while I think the current proposal can make sense it might still be worth exploring and comparing it to the option where we use the current, rather than the projected, voting result for wait-for-quiet (I don’t see an obvious reason why this makes more sense, but might still be worth to spend a little more time on it).

One of the main points that I would like to point out: it is now stated that

but it could be applied to other proposals as well if we want proposals to be executed consistently across all proposal types

As already argued in the original thread, I would advise against this. While I also would like enough time to vote by myself, I think for some proposal topics it is more important that they can be executed quickly in emergencies and I am willing to accept a followee’s judgement to make this possible.

Then, I also agree with Manu that it is likely very hard to commit to a timeline as this depends on so many other factors, especially the community could decide on other features and deem them more important etc. Also, we should keep in mind that the governance is a security critical part of the IC. Therefore, I would strongly advocate for a thorough security review of any changes, which both means that the delivery will also depend on other factors, e.g., the security team’s availability, and will likely take a bit longer.
Thus, I also think it might be better to maybe not impose a strict timeline.
Especially, I think with the upcoming holidays 1 month is likely not realistic.

Also timing wise, I was wondering whether you think it makes sense to submit this proposal in 3 days or whether it might make sense to wait until the new year? I am not sure how people in the community are available this and in the next weeks, but it could be that some people are already in holidays that would have interesting feedback.

Finally, I have a few more detailed points that could maybe be clarified for the final proposal text. (I understood you would be glad for such feedback how maybe things can be clarified. If you didn’t look for this feedback, I think the text is also quite clear as it is):

this proposal intends to enable Followee organizations to vote any time they want within the voting period and simultaneously allow all individuals to vote manually at any time within the voting period on Governance proposals.

=> Maybe I would state here that if individuals vote at any time, then this vote is what counts and the votes that would be sent by following are disregarded (just to make this clear already in the summary).

By definition, Projected Voting Result will change every time a vote is cast manually.

=> Is this really true? If voter A would vote yes due to following but then manually casts a yes vote, then the projection would not be changed when A votes, right? Maybe this should say the voting result could change on every vote that is manually cast?

This voting mechanism would force all proposals to be finalized within the window of the Wait for Quiet algorithm even if the Projected Voting Result is an Absolute Majority.

=> Maybe this could be rephrased to something like “This voting mechanism would not accept proposals before the end of the voting period just because there is an absolute majority in the projected voting result” To me, this would underline a bit more that all proposals would at least take this time (except as added next if the majority of the current voting result is reached). Alternatively, one could connect with the next part and state that only in case of a majority in the current voting result, the proposal can be accepted before the voting period has finished.

[wpb]

Thanks @lara. I like all your suggestions. Later today I will work on editing the original post to make sure it reflects your suggestions. That way the first thing people see in this topic is the current thinking on what the proposal needs to say, yet if they really want to they can review the edit history as they read through the comments.

I will also post here again after my edits to the original post are complete.

[rubenhorne]

Love the proposal to be able to always claim the right to vote manually regardless of how your followees have voted.

[rubenhorne]

Another issue that has come up for me: I can’t vote in the minimum 4 day window if I miss a proposal that passes EARLY with a 50% absolute majority. I would love some way for my vote and rewards to still get counted if I still vote within 4 days, even if it is no longer possible for that vote to affect the outcome!

Theoretically, half of the NNS voting power could miss out on rewards for voting a little slower than the other half of the voting power for 100% popular proposals.

[wpb]

@lara @Manu

I have edited the first post on this topic to reflect our discussion so far. Please advise if you think it needs additional edits.

[wpb]

I think the proposal as currently stated ensures that you can still vote. Is there any specific wording you would like to see added that reflects your concern?

[rubenhorne]

Got it. I just wanted to offer another angle on the issue of what we could stand to benefit by changing the existing voting rules.

[lara]

Hi there, I would like to understand your concern a bit better.
Do you think that your concerns already applies to the current way of how voting works?
If so, could you elaborate on this?
It should already be the case that, even if a proposal is adopted and executed due to a majority, that other neurons can still vote on it and get voting rewards until the initial voting period is over (this voting period would just not be increased as wait-for-quiet increase will not kick in).
Would this resolve your concern or did you have something else in mind too?

[lara]

Thanks a lot for the work and the edits, I like the improvements!

One last comment for this year:
If I were to design this, I would like to spend some more time understanding whether for 3. the “trend” should consider the projected or the current voting result and what this means for different scenarios (last minute votes by attackers who are followees, who are not followees…).

I see that you already added “it is acceptable to modify the details if needed to develop a better way” (thanks!).
However, if you agree with this and we want to make sure that whoever picks this work up does not forget about this point either, one could additionally change the third point to:
" 3. In the Wait for Quiet algorithm, define the “trend” and carefully think about whether the algorithmic decisions should be based on the Projected or the Current Voting Result."
(Similarly, one could then generalize “but Wait for Quiet is based on Projected Voting Result” in the lower paragraph to “but Wait for Quiet could be based on either Projected or Current Voting Result”)

But this is just a suggestion that I thought could be useful to not loose any information until next year =)

[wpb]

I know your question is for @rubenhorne but I wanted to say also that I would like this functionality that you describe to remain even if the changes related to this proposal are implemented. I like the fact that people can currently still vote if they didn’t vote before the end by absolute majority.

[wpb]

I’m having a hard time thinking of situations where it would be better to base the Wait for Quiet algorithm on Current Voting Result instead of Projected Voting Result, but admit that there may be some solid reasons why to do it that haven’t surfaced yet. Therefore, I left the main text focused on using Projected Voting Result, but added additional comments that highlight the Note that enables Dfinity to use Current Voting Result instead if needed. The Note is intended to be interpreted broadly in the sense that there may be reasons to implement changes of any element of this proposal as long as they are consistent with the overall objective in a safe and reliable way and go into effect with reasonable swiftness.

BTW, thank you so much for all your contributions to this discussion. I really appreciate when Dfinity folks engage in forum discussions as you have done. Whether they are representing Dfinity or their own personal views as voting members of the IC governing body, I think Dfinity personnel have an important voice that needs to be heard by the IC community. It means a lot to have you offering suggestions and opinions.

[lara]

Yes, this was meant as an answer to @rubenhorne, thanks for clarifying!

I was not sure what he meant by

benefit by changing

and therefore I just wanted to point out that this should already be the case.
But yes, it is also good to clarify that this will remain even after your proposed changes.

[lara]

Thanks for the change, I think this makes sense and it satisfies my intention, i.e., ensuring that we don’t forget about this.

Thanks for your kind words.
And also thank you for taking on the effort to formulate this text and lead this discussion!

I wish you a good end of the year and happy holidays (if you observe)!

[rubenhorne]

Yes, this does resolve my concern. What probably happened in my case was that I showed up to vote after the 4 days were up, despite thinking that I had been within the window. Nice to know the mechanism I wanted is already in place.

[wpb]

@lara @johan @jwiegley @diegop @Arthur @skilesare

Do any of you have any other comments that need to be considered regarding this proposal? Are there any objections to it being submitted to the NNS for voting in 2 days?