Proposal to include cycle_dao & ICDevs as default follow-target neurons to the NNS

Thanks for the clarifications and apologies for having misunderstood the proposal: re-reading your question I now see that it was clearly saying “governance proposals”. I think I was reading this as “proposals in the governance canister” rather than “proposals of topic governance”, this was totally my fault.

Does this address your biggest concern?

You are absolutely right, this eliminates my main concern!

If the minimum voting period (previously 24 hrs; now 4 days) changes again in the future, then this delay timer should adjust proportionally

It makes sense to me to apply this relative ot the minimum voting period. This minimum voting period is actually just a constant in the code, so it should be easy to express this relative to it and ensure that it would automatically be “adjusted” if we ever change the minimum voting period again.

One note on implementation: currently the process how votes are processed is independent of the proposal’s topic, i.e., when a vote is cast following is also triggered. If we now changed this behaviour for proposals of topic governance only, this would mean that vots are processed differently depending on proposal topics. I think this can be implemented by an extra check. I just want to point out that this makes the logic of how proposals are processed a bit more involved, which for example might make it harder to argue about and prove security properties. (Just another thing to consider in weighting the pros and cons).

If a lot of votes are suddenly cast, especially if they swing the outcome, isn’t that a signal that the vote really should be extended by W4Q?
Right, I think this could be a valid argument.

I guess I was wondering about the following scenario: Say there are many, close to 3%, yes votes and only one no-vote. However, the no-vote is coming from a neuron that has extremely many followers, so many that all the follower’s votes would add up to 50% of voting power. Now, should we view the actual result 3% yes + 1 vote no as the “trend” or the 3% yes + 50% no (that we know will take effect before the voting period ends) as the “trend”?
One could argue that everyone who knows the algorithm would know that the expected outcome is a no already. This could for example mean that if I want to vote no and follow this one neuron, I might abstain because I know my opinion will be reflected correctly. Therefore, when all the no-votes are then cast by the following that kicks in, we could consider that this is not really a “change in trend” as this was predictable. For this reason, one might argue that the voting time need not be increased in this moment.
What I mean is that we mainly want to increase the voting time to give people chances to react to new trends that might be surprising, but in that case the change in trend was predictable.
Therefore, I think it is a valid option to consider the trend with or without taking the following (even though not applied yet) into account.
Do you know what I mean? Do you think in this scenario only the effective current result should be considered as the “trend”?

Do you envision the Governance proposal type being executed by Absolute Majority in the future?

You are right. I don’t think proposals of topic governance are emergency proposals and rely on the fact taht they can be executed quickly with an absolute majority.
Of course it can still be that some of the future proposals will achieve the majority threshold, but I agree that this will be less likely and we don’t rely on this.

4 Likes

It seems that Governance proposals should be processed differently. Providing an opportunity for manual voting is one reason, but there seems to be other reasons that are being identified in other threads on the forum. For example, a lot of folks are talking about voting thresholds. I suppose if you start processing Governance proposals differently that other proposal types, then you can plan in advance for other types of changes that may come up for the Governance topic.

You provided a good example for why it is important to define the “trend”. I don’t think I have a strong opinion one way or the other at this time. I would probably prefer the side that is more conservative…meaning whatever enables people the best chance of casting votes in the long term best interest of the IC. I think you and your colleagues at Dfinity have been thinking about these voting mechanisms longer than anyone, so I would look for your guidance on the best definition of “trend”.

I really like the idea of displaying Current Results and Projected Results in the NNS app and on the dashboard. Current Results cannot be changed because votes have already been cast. Projected Results will change as more people and organizations cast votes. Hence, people can see the direction the vote is heading in real time…it will help them decide if they need to cast their manual vote to increase the probability of achieving their desired outcome. This seems like very important data that should be readily available.

With the feedback provided so far, I will develop a proposal and post it tomorrow as a new governance topic in the forum to begin deliberation. Some time next week I will submit the proposal to the NNS for voting. Thank you @arthur @skilesare @lara @johan @jwiegley @dralves @diegop for offering input.

1 Like

I only see one tricky thing about implementing your feature idea as stated: we don’t have “timers” in Governance, so there’s no way to say that something should happen once we reach a specific time threshold. What we do have is a canister method, invoked by a cron job, that acts as a heartbeat for the progression of proposals and the allocation of rewards.

If we attach your idea as another feature of the heartbeat, then we could aim for 75%-ish by invoking it on the 3rd day after the proposal begins.

This then happens in a governance function called run_periodic_tasks. The implementation would involve adding a call to a function here that loops through the open proposals, loops through the ballots of each proposal, and checks whether there are neurons that haven’t voted but whose followees have voted. This would necessitate building a followee graph – something we don’t currently have. Building that would be best done with a graph library (petgraph?) which could quickly identify all the “edges” representing votes that need to be auto-cast.

Not difficult, but not trivial either. Might involve a new library dependency to build the graph, so we’d have to monitor the increase in canister code, or hand-roll just the graph handling functions we need if we want to keep it really small.

4 Likes

@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

  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.
  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

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?

9 Likes

This looks ideal. I don’t know about the technical challenge of implementation but it facilitates individual voting and avoids the invisible time limit followee vote. I love it actually as I usually vote personally because I have a ton of small neurons and one large one that follows cycle_dao. cycle_dao is my fallback voter

3 Likes

I don’t see any technical hurdles that would prevent implementing such a proposal.

2 Likes

I like it. Thanks for laying it out so clearly.

2 Likes

I assume that what you propose here subsumes the discussion here. Is this correct?
I will therefore read in more detail and comment on your proposal under this link, please let me know if this is not the case!

1 Like

I recommend eliminating all default neurons and putting your own neuron IDs on your own website

Yes, that link you referenced is where I more formally started a deliberation on this topic as a separate topic from cycle_dao and IC devs wanting to be named Followees in the NNS app. It would be good to offer your responses in that new thread. Thank you so much for all your consideration of this proposal.

1 Like

I think the other proposal will be addressed and then we’ll come back to this one. I still think for the community it would be great to have a process for adding Neurons to the interface and ICDevs would love to be one of those.

1 Like

Right. Thanks for this clarification. I didn’t mean the other thread subsumes the full discussion but just the discussion about the proposal for waiting with following to kick in (I thought for this sub-question it makes more sense that I give my input on whatever is the latest discussion).
Sorry for being imprecise and thanks for clarifying this!

1 Like

We just published the first version of a policy document for a community neuron we will be creating for the ICP Maximalist Network. It is intended to be a neuron that people can select as a Followee. The neuron has not been created yet, but soon it will be announced and promoted. We will also be submitting a proposal to the NNS to get it listed as a named Followee in the NNS app similar to what cycle_dao and ICDevs will be doing soon.

Please read the policy document and let us know if you have any questions, concerns, or suggestions. Our community is active in the telegram link… Telegram: Contact @icpmaximalistnetwork

ICPMN neuron policy document:

4 Likes

The neuron for the ICP Maximalist Network has been created and the neuronID is 4966884161088437903. It is currently following DF or ICA on all topics. After elections of voting members for this neuron next week, the Followees that are assigned for Governance topics will be updated. To learn more about the ICP Maximalist Network, please join us on Telegram at Telegram: Contact @icpmaximalistnetwork

3 Likes

This is so great ! Look forward !

1 Like

The cycle_dao, ICDevs, and ICPMN organizations have agreed to submit their proposals on Monday, January 10 of next week at approx the same time. The proposals will request for each organization to be added to the list of named Followees in the NNS dApp.

The Proposal to Enable Manual Voting Throughout the Entire Voting Period of Governance Proposals will also be submitted at the same time.

4 Likes

Below is the text we currently plan to submit for the ICPMN neuron proposal…

Title: Motion to Add the ICPMN Neuron to the Named Followee List in the NNS dApp
Summary: The ICP Maximalist Network (ICPMN) proposes that Dfinity Foundation shall add the ICPMN Neuron ID 4966884161088437903 to the list of named Followee options in the NNS dApp. The neuron shall be labeled as ICP Maximalist Network in the list.

The ICPMN neuron will be representative of the enthusiasts, end users, investors, developers, project leaders, Dfinity and ICA members, and other IC ecosystem contributors who participate in our community. A primary objective will be to ensure that our neuron can be trusted to always vote on all proposals. The neuron will be configured to follow our elected voting members on all Governance proposals and to follow Dfinity Foundation (DF) and/or Internet Computer Association (ICA) on non-Governance proposals.

Ownership and configuration of this community neuron as well as voting member expectations are described in the policy document published at Followee Neuron for ICP Maximalist Network

You can join the active ICP Maximalist Network community on Telegram at Telegram: Contact @icpmaximalistnetwork

Motivation for this proposal - At ICP genesis, the NNS was configured to set ICA as the default Followee for the Governance topic for all neurons. DF and ICA are currently the only named neurons in the list of available neurons in the NNS dApp and people configuring their neuron can easily select these neurons to follow for voting. In an effort to accelerate decentralization of the internet computer, DF and ICA are going to be removed as default Followees for Governance topics and voting rewards will be weighted by proposal type. Hence, there will be a new need for people in the IC community to find other neurons to follow in order to continue getting paid their voting rewards. It is desirable to have a diverse and reliable selection of Followees listed in the NNS app to make it easy for people to find Followee options. Several organizations are responding to this challenge including cycle_dao, ICDevs, and ICP Maximalist Network, each of which represent special interests within the IC community. It should be noted that all neuron owners are encouraged to vote manually on Governance topics that you consider to be important even if you select Followees for the Governance topic. Manual voting is the only way to guarantee that your neuron votes according to what you believe is in the long term best interest of the internet computer.

3 Likes

Below is the text we currently plan to submit for ICDevs…

Title: Motion to Add the ICDevs.org Neuron to the Named Followee List in the NNS dApp
Summary: The ICP Maximalist Network (ICPMN) proposes that Dfinity Foundation shall add the ICDevs.org Neuron ID 14231996777861930328 to the list of named Followee options in the NNS dApp. The neuron shall be labeled as ICDevs.org in the list.

The ICDevs.org neuron will be representative of the application, service, and protocol developers building on the Internet Computer. A primary objective will be to ensure that our neurons can be trusted to always vote on all proposals. The neuron will be configured to the guidance of the ICDevs.org Developer Advisory Council on Governance proposals, with backup followings for governance issues not relative to developers. The backup following will be decided by the Developer Advisory ICDevs.org Committee. The neuron will follow Dfinity Foundation (DF) and/or Internet Computer Association (ICA) on non-Governance proposals but will reserve the right to vote on non-governance proposals that affect developers. Voting by the Committee is subject to US 501c3 laws and restricted by the bylaws of ICDevs.org that can be found at ICDevs.org and thus the Executive Director has been granted the right and responsibility to refer issues to the ICDevs.org board if they may violate US law or the bylaws of ICDevs.org. In these rare cases, the board of ICDevs.org may choose to abstain from the vote on that issue or to ratify the vote of the Committee.

Configuration of this neuron, as well as voting member expectations, are described in the policy document published at ICDevs.org

You can join the ICDevs.org Developer Advisory Committee by following the instructions at ICDevs.org

Motivation for this proposal - At ICP genesis, the NNS was configured to set ICA as the default Followee for the Governance topic for all neurons. DF and ICA are currently the only named neurons in the list of available neurons in the NNS dApp and people configuring their neuron can easily select these neurons to follow for voting. In an effort to accelerate decentralization of the internet computer, DF and ICA are going to be removed as default Followees for Governance topics and voting rewards will be weighted by proposal type. Hence, there will be a new need for people in the IC community to find other neurons to follow in order to continue getting paid their voting rewards. It is desirable to have a diverse and reliable selection of Followees listed in the NNS app to make it easy for people to find Followee options. Several organizations are responding to this challenge including cycle_dao, ICDevs, and ICP Maximalist Network, each of which represent special interests within the IC community. It should be noted that all neuron owners are encouraged to vote manually on Governance topics that you consider to be important even if you select Followees for the Governance topic. Manual voting is the only way to guarantee that your neuron votes according to what you believe is in the long term best interest of the internet computer.

3 Likes

Below is the text we currently plan to submit for cycle_dao…

Title: Motion to Add the cycle_dao Neuron to the Named Followee List in the NNS dApp
Summary: cycle_dao proposes that Dfinity Foundation shall add the cycle_dao Neuron ID 5967494994762486275 to the list of named Followee options in the NNS dApp. The neuron shall be labeled as cycle_dao in the list.

cycle_dao aims to advance the needs of the internet computer ecosystem. To understand what these needs are, cycle_dao monitors social media & the DFINITY developer forum, engages with the DFINITY Foundation, canvases different segments of the community, and conducts focus group interviews. The cycle_dao neuron follows other neurons to ensure its participation in every vote, but itself votes on all governance topics. Explanation of voting decisions can be found at Blog | cycle_dao.

The cycle_dao neuron is currently controlled by 11 council members representing different interests in the Internet Computer community through Axon.ooo. A quorum of 3 members is required to execute a vote. Council membership changes periodically depending on the availability of members. Some or all members may elect to withhold their identities in the future in favor of anonymous participation.

We welcome you to join us by following our neuron and Twitter: https://twitter.com/cycle_dao

Motivation for this proposal - At ICP genesis, the NNS was configured to set ICA as the default Followee for the Governance topic for all neurons. DF and ICA are currently the only named neurons in the list of available neurons in the NNS dApp and people configuring their neuron can easily select these neurons to follow for voting. In an effort to accelerate decentralization of the internet computer, DF and ICA are going to be removed as default Followees for Governance topics and voting rewards will be weighted by proposal type. Hence, there will be a new need for people in the IC community to find other neurons to follow in order to continue getting paid their voting rewards. It is desirable to have a diverse and reliable selection of Followees listed in the NNS app to make it easy for people to find Followee options. Several organizations are responding to this challenge including cycle_dao, ICDevs, and ICP Maximalist Network, each of which represent special interests within the IC community. It should be noted that all neuron owners are encouraged to vote manually on Governance topics that you consider to be important even if you select Followees for the Governance topic. Manual voting is the only way to guarantee that your neuron votes according to what you believe is in the long term best interest of the internet computer.

4 Likes

I object to this proposal, like IC_xxx and cycles_DAO and NNS_DAO, whose names are extremely misleading.