Changes for the “Wait for Quiet” mechanism (W4Q) require updating the governance canister. As it stands, the DFINITY foundation wants to propose on the developer forum that we extend the W4Q period from its current 24 period. We want to see what people think. We want to explain the current thinking, hear ideas, answer questions.
Yes, this topic is a bit light in details from my end ( 
that is on me, as I am catching up). I will update as @timo and @lara weigh in on what they are thinking.
Could you also post in this topic how the algorithm for W4Q works? I haven’t seen that documentation yet.
The current wait for quiet algorithm is relatively simple, it proceeds as follows:
This means that a vote flip 1 hour into the proposal would change the deadline to 24.5 hours, or 1 + (12 + (24 - 1) / 2).
It also means that the maximum deadline possible is 48 hours, if vote flips kept happening near the end to cause repeated extensions: 48 + (12 + (24 - 48) / 2) = 48.
To put that all into plain English: The deadline is 24 hours, but may extend linearly out to 48 hours, with extensions made to fit that linear path only when the majority flips.
I’ve made a Google Sheets document to show how the deadline may evolve based on such flips here: Wait for Quiet - Google Sheets
W4Q allows to pass proposals with simple majority (majority of all votes cast) instead of absolute majority (majority of all eligible votes). One problem with simple majority is that if the voter turn out is low then it may be possible for a large voter to “snipe” the election. This means the following: say the large voter wants to vote “yes” but an absolute majority actually wants “no”. The first votes come in and the trend is towards “no”. A large part of the “no” group doesn’t bother voting because of that. The large voter waits until the last second before the deadline and turns the relative majority around to “yes”. When the “no” group realizes this it is too late. Given more time the “no” group could have increased their turn out and re-established a relative majority.
The current W4Q takes care of election sniping only. It does not have any other sophisticated features such as, for example, a stochastic model for “quiet” that could be used to speed up elections and close them as early as possible. In the current W4Q, “quiet” is simplified to mean “not flipping”, which is enough to mitigate sniping.
The rough idea behind the formula given above by @jwiegley can be summarized as follows:
The proposal that is being made here doesn’t have anything to do with how the W4Q algorithm works but only with the fact that it is possible to pass a proposal with a simple majority. The proposal is to increase the original voting period from 24h to something larger so that there is more time to detect malicious proposals.
I’m glad you clarified the proposal is about the duration instead of the W4Q. I thought the proposal was to change the wait for quiet algorithm to allow votes that keep flipping to go on longer. I have gone through this topic thread again and now I cannot figure out what is the proposal. What action or change is being proposed?
You might want to edit the use of the term absolute majority in this sentence since the term Absolute Majority has a formal definition in NNS governance (greater than 50% of total voting power, which immediately ends the vote since the vote can no longer be flipped).
I agree this is a good reason to consider changes to how the Simple Majority voting mechanism works. I also feel like this is a reason why there should be a bonus for voting manually since that would encourage active voting and this situation would be less likely to occur.
If the question is “should we allow more than 24 hours for a vote?” then I agree yes. Or something like what @skilesare suggested where a vote has to be scheduled a week out and you can set how you would like to vote in advance (aka “vote early”). As it stands, voters have to check in daily to vote on motions, which I think places an unrealistic time expectation on people. What if they have emergencies, care duties, job responsibilities, vacation, weekends, weddings, day of worship etc.? Do we really expect every neuron holder to respond to every vote on such short notice? I think we need a mechanism that lets voters check in as infrequently as once a week on a day of their choosing to review proposals, weigh the arguments, make a decision, set their vote, and then be done. Otherwise, the votes we get will miss a lot of the community.
One way to do this could be to change P in the W4Q to from 24 hours to 168 hours.
The proposal is to increase the original voting period for all proposals. Here, original voting period refers to the time that proposals are open for voting before any W4Q-triggered extension kicks in.
I meant there’s an absolute majority out there that wants “no” but not all of them actually vote. In other words, there would be an absolute majority of votes if they all voted.
Maybe at least twice a week for now? We can still move to once a week later on. Since the IC is in beta we might want to be able to move faster. In a year or so the speed of change will surely slow done.
Is DF looking for the community to make a recommendation on what the original voting period should be for this proposal? If so, then how about 3 days? After 3 days of voting the wait for quiet algorithm can kick in.
I think another way to address concerns with motion proposals that occur too quickly and giving people time to vote is to have them go live on a common day of the week. For example, all motion proposals can go live on Thurs. If the original voting period is 3 days, they we would have Thurs - Sat each week to research and vote on motion proposals for that week. The deadline to submit a motion proposal could be midnight Wed and anything that doesn’t meet that deadline would go live the following week.
To be clear, the change that we propose in this thread is that we want to increase the initial voting period from 24h to 4days, as well as increase the maximum delay that wait-for-quiet can add from 24h to 4days.
This would mean that whereas now a proposal has a min. deadline of 24h and a max deadline of 48h, it would after this change have a min. deadline of 4d and a max deadline of 8d.
So this thread is to ask the community for feedback on this proposal.
If you would suggest 3 days, maybe you find our proposed 4 days also acceptable ?
I fully agree that 24h is just too little to carefully inspect and vote on a proposal, this is what motivated this change.
The proposal with regular days for posting motion proposals is an interesting suggestion. I would propose that maybe we can think about this separately, i.e., as a possible future extra measure?
Thank you for this clarification @lara. It is now clear to me and I agree with the proposal as you have stated.
I also agree that my suggestion to have regular days for governance proposals does not need to be considered as part of this proposal. It can be a separate topic for consideration later.
Motion is now live: Internet Computer Network Status
Can we just from now on, ALL fillAT LEAST a SWAT analysis for EACH PROPOSAL ?
Follow Swizerland model of democratic decision making
Hi all,
it seems that there was some confusion around the details of this motion proposal.
I am sorry for that and acknowledge that I should have provided more information regarding the motion’s intent and context earlier.
Let me try to provide some extra information now that hopefully helps to clarify things.
What the motion proposal is about
Each proposal that is submitted to and stored in the Network Nervous System (NNS)’s governance canister has an associated voting period. Currently, each proposal is at least open for 24 hours and at most open for 48 hours.
We propose to increase the minimum voting period for proposals to 4 days (now 24 hours) and to increase the maximum delay that wait-for-quiet can add to the voting period to 4 days (now 24 hours). This means that the maximum voting period would be changed to 8 days (now 48 hours).
What the motion proposal is not about
The motion proposal does not propose to change the wait-for-quiet algorithm itself or any other aspect of how proposals are decided. It only proposed to change these two constants.
More details on how proposals are processed
When a proposal is initially created, it is assigned an initial voting period. This is currently set to 24 hours (the proposal suggests to change this to 4 days).
Once a proposal is stored on the governance canister, all eligible neurons can vote on it. A proposal can be decided in two ways:
As a slight catch, the governance voting algorithm also applies wait-for-quiet. The idea of wait-for-quiet is to decide proposals quickly when all voters agree, but increase the time that neurons can vote for proposals that are controversial. That means that the voting period can be dynamically increased, depending on the neurons’ votes.
In particular, each time a proposal’s outcome is turned (either a Yes-majority is turned to a No-majority or vice versa), the proposal’s deadline is increased. However, each proposal’s voting period is currently at most increased by 24 hours, i.e., each proposal is currently open for at most 48 hours (the proposal suggests to change this to a maximum increase of 4 days, i.e., a maximum total deadline of 8 days).
Consequences
I hope this helps clarify some details.
Thanks all for bringing up concerns & questions and please let us know if you have additional ones!
For future readers, the proposal passed: Internet Computer Network Status
Hi all, I am very happy to report that the governance cansiter has just been upgraded with the changes that have been decided in the above motion proposal (see this proposal).
Proposals now have an initial voting period of 4 days (96 hours) and a maximum voting period of 8 days!