But someone has to see them and vote on them for those proposals to even reach the minimum threshold, that’s what I meant when I said you’re minimising the burden to a smaller group of people. I’d imagine that there would be some sort of filter for manual voters that excludes proposals that didn’t reach the threshold yet. This is helpful for people that don’t want to be bothered with “spam” proposals, but also puts the power in the hands of a smaller group of people, because those people that actually look at every proposal decide which ones are able to proceed to the next stage and some (good) proposals might never reach the surface because of the smaller group of people that actually look at all the proposals dislike them.
1 Like
These are some great points. Before responding, lets take a step forward into the future of the NNS, assuming the IC is wildly successful. In this future:
- Hundreds of proposals hit the NNS every day. Maybe 200-300 are spam, but at least 20 are legitimate proposals.
- Some new proposals contain wasm and/or code that will hooked into the updating the actual governance code/constants of the NNS, meaning that many proposals are now more technical in nature.
- There are many more issues with canister content and censorship, in the sense that a canister may contain objectionable or copyrighted content and a proposal is created to take that canister down.
- Many more proposals are created to bring attention to various campaigns, or to preach a certain philosophy or vision for the future of the IC.
This future is therefore one full of proposals that have interesting ideas, are actionable or tightly integrated, with lots of spam mixed in.
Now imagine being an NNS voter in this environment. What is your voting strategy?
Are you going to take the time to read and vote on every single proposal (like a local political activist)? Are you going to follow a few trusted neurons to vote for you and check in every now and then to vote on a particular proposal you care about?
In the case where you choose to follow a few trusted neurons and sometimes vote, you’re putting the majority of your votes in the hands of those who’s judgment you trust, but then manually vote on a few specific issues that you care deeply about. In your own words, the followee system we currently have already…
I see this as an identical process to the incubation period, in that your votes can be cast by you or your followees to bring proposals out of incubation, but if you really want to vote on a specific incubating proposal → you can manually go in and vote on it. The only difference is that proposals that are live on the NNS last 2-4 days, whereas incubating proposals last up to 2 weeks, meaning voters have more time to exercise or refuse their voluntary support for an incubating proposal than a live proposal.
The 2% minimum support threshold also puts an onus on proposal creators to bring their proposals to the community (on the Developer Forum, Twitter, Medium, etc.) before submitting those proposals to the NNS in order to gauge support, gather feedback, and iterate on feedback from the community to improve the proposal further.
Proposals that skip this feedback step and are published straight to the NNS risk being ignored completely, but by not engaging with the community before suggesting a change to the system, the proposal creator is actively taking that risk. As noted in the “Additional Benefits of this proposal” section, this also has the side effect of incentivizing proposal creators to make their ideas for changing the IC public, which allows proposals to be viewed, challenged, and vetted to a degree in order to reach that necessary minimum support threshold and pass incubation.
Arguments Against
-
Proposal Creator: “What if I have a really great idea, but no one knows who I am and I have no support/voting power. Surely I have no chance of my proposal passing”.
Rebuttal to (1): Make your governance proposal idea public on the forums, tag a few prominent members of the community, engage people on Twitter. If your proposal is worth its salt, it would easily pass the minimum support threshold if got approval from this community. In fact, support from any one of @wpb, @Kyle_Langham, @skilesare, Bob Bodily, or DFINITY employees/alumni like @nomeata, @paulyoung, @claudio, or @kpeacock would probably get you past the 2% threshold.
-
This proposal puts the voting power in the hands of an even smaller group of individuals.
Rebuttal to (2): In the current voting system, we have those who vote manually, those who follow neurons for all votes, and those who do a little of both. Voting that takes place during the incubation period would have the exact same rules and therefore, the same “voting power dynamics” as voting on “live” proposals. This proposal just reflects the power dynamics of the current system.
It also incentivizes the voters who are most active and knowledgable in a particular area of the IC to engage with those proposals. As NNS Proposals become more diverse and specialized, certain NNS Voters may actually be more inclined to go in and manually vote for a proposal that covers an area they specialize in (say boundary nodes, or cryptography) to ensure that proposal passes incubation and receives a live vote.
-
No @justmythoughts, you weren’t listening! (that’s me
)
Introducing a filter hides proposals from the public and reinforces the voting power inequity of the NNS.
Rebuttal to (3): There’s no perfect solution here, but I think there’s a balance that can be reached between usability and accessibility. Asking NNS voters to read and vote on tens to hundreds of proposals per day just isn’t scalable, nor is it accessible. It wears out NNS voters, and doesn’t allow them to due the due diligence to read and vote on the proposals they most care about. We want people to make good votes, not rushed votes or even worse, give up and just default vote.
To build a system that scales for NNS voters, we have to build a system where they feel empowered to vote, and not overwhelmed. This means:
- Searching for and voting on proposals an NNS Voter truly cares about, or has expertise in
- Allowing an NNS voter to ignore a proposal or delegate their vote to a neuron they trust to do the proper due diligence on a proposal.
The NNS App already has filter functionality, but this could be extended to be able to search for proposals with a specific ID or topic name as the system scales up and more proposals come in. I actually see this search functionality not just for the incubating proposals, but soon for proposals that are live on the NNS (i.e. I’m looking for proposal 178988 that Wenzel just posted about on Twitter and the forums saying its live).
1 Like
You convinced me, I’d vote yes if you put this forward. You should work out a very detailed UI/UX before you put this forward and get feedback on it, this way we know exactly what we are getting and the foundation has an actionable plan.
2 Likes
@peterparker tagging you here as I would love input from you and the rest of the NNS App frontend team on the proposal in terms of difficulty of implementation, UX/UI suggestions, and any additional feedback you have.
I’d ideally like to understand various edge cases and potential concerns from DFINITY and flush out the UX/UI so voters can visualize the changes a bit more before voting.
For reference, I see this proposal as more of a long term fix (not a quick fix), so I’m willing to take the time and back and forth to get things right 
1 Like
To be honest with you, I feel like the subject of the proposal if a bit outside my field of expertise (frontend development) therefore not sure my two cents about it here would be really useful.
Being said, regarding the proposed “NNS App UI Changes” I would say nothing sounded like a technical red flag, adding information, list and filters sound reasonable from a frontend developer point of view. Only concern would be making the features understandable by anyone. From newbie to expert, it should be clear to anyone. But these are UI/UX related and that’s why we have a UX expert in the team 
.
2 Likes
@justmythoughts it seems like this is a good proposal to address spam that occurs for the purpose of advertisement and announcement. I would vote in favor of this proposal, but with the caveat described below.
I’m concerned about whether it would work to stop spam for the purpose of personal financial gain. We need to assume people will always select options that result in higher financial gain. Hence, I think they will be inclined to seek out and vote for the spam so it can make it into the system in a way that earns then higher rewards. Whales have incentives to do this themselves, but I think the smaller investors would also do the same to ensure the proposal meets the threshold. That means a lot of votes getting cast as yes when they might otherwise be willing to vote no. Personally, I think the solution that addresses this issue is proposal 55651 because it takes away the financial incentive for spam.
Hence, I see proposal 55651 as the solution for spam that exists for financial gain and your proposal as a reasonable solution for spam that exists for advertisement and announcement.
One point I’d like you to clarify…would people who vote during the incubation period be rewarded for their votes if the proposal makes it out of incubation? Currently I think the proposal says they would not be rewarded. It makes sense for them to not be rewarded if the proposal never goes live, but I don’t think it makes sense for everyone who votes when live to get rewarded but not the people who voted when it was in incubation. Could you please clarify and, if needed, update the proposal accordingly?
This still does not solve the core issue which is the incentive to spam proposals. If neurons are gaining higher rewards for voting on governance proposals it still opens the door for abuse. A group of large neurons could just continuously push proposals all day long through the incubation period.
If you increase the threshold to try and solve this you could eventually just end up with a clone of the NNS, plus increasing the threshold would make it harder to pass proposals in general. Meaning good proposals from community members may just vanish after two weeks along with their ICP. If they were not loud enough.
If you set rewards to be released weekly, it only creates patient spammers.
Now hiding away proposals also creates a loudest voice in the room type situation, meaning the most followed or most well known community members will always have more sway then the common neuron. We all know information is power and those that control the flow of it will effectively control what proposals are passed to the NNS. you run the risk of having the smaller voices fall into the ether. I really don’t want to fall back into a party system, The NNS at this time allows anyone globally to have their idea immediately present and available for voting.
I do think if there are hundreds of proposals being submitted all at once it could become overbearing but your are able to search for proposals via their I.D at this time as well.
I still think we need live reviewers. either we remove the governance rewards or we have live reviewers who filter for spam/quality. I had to remove my initial idea, I could not entrust a static mechanism to control for all error.
1 Like
You are both 100% correct! While this proposal addresses spam and quality control concerns, it does not remove the financial incentive if enough voting power wishes to pass as many governance proposals as possible.
If you read the Arguments Against/Potential Issues section of this post, under argument (2) I bring up your exact concern, and provide potential solutions. I favor solution 3 brought up in Community Discussion: Revise Governance Voting Rewards to Fix Proposal Spamming Rewards Exploit, which talks about fixing the governance rewards as a percentage of the overall voting rewards. This way, regardless if we have 0 or 1000 governance proposals that hit the NNS, the rewards payout is the same and both spammers and voters have no financial incentive to vote on spam proposals.
I chose not to include that in this proposal, as I feel that removing the financial incentive to pass spam proposals can be solved in a separate, but complementary proposal. There are many different ideas out there that tackle the financial incentives directly. I believe my idea to fixing the governance rewards over a week-long period will solve this issue, but it also received a decent amount of pushback and I believe it might be hard for the voters to digest such a big change all at once if the Incubation Period + Minimum Support threshold changes were tightly coupled with a change to Fix Governance Rewards.
Therefore, I want to continue gathering feedback from the community with respect to fixing governance rewards for the time being, and will later submit a distinct proposal that hopefully addresses these concerns. If you have any ideas/concerns regarding fixing the governance rewards and removing the financial incentives to vote on spam proposals, please leave those comments in Community Discussion: Revise Governance Voting Rewards to Fix Proposal Spamming Rewards Exploit.
2 Likes
Are you suggesting that an NNS voter would search just for a single live proposal to vote on? What about the other 100-1000 that hit the NNS? Would they auto reject the rest, rely on default followers?
The issue with not providing an initial quality/spam filter layer is that voters are then required to vote on every proposal that goes live on the NNS if they want to receive rewards.
Therefore, this system does not scale as the number of proposals submitted to the NNS increases, and just opens up incentives for NNS voters to not do their own due diligence on all the proposals due to the sheer number of them. In fact, it creates incentives for developers to create NNS voting bots that default reject or accept all open proposals. We want quality over quantity to be presented to voters, and to create a system that scales well in terms of accessibility for each user, not over burdening NNS voters.
In terms of your concerns about this proposal consolidating NNS voting power, I will direct you to this response I gave to @cryptoschindler, who shared similar concerns.
@wpb Good question. I had not clarified this specific detail, but will give my interpretation of how I imagine things working out.
All votes cast on incubating proposals count towards reaching the 2% minimum support threshold. Once a proposal reaches the minimum support threshold, any votes that were cast in support are now applied as “Approve” votes towards the live proposal. This means that a vote of support during the incubation period automatically applies as a vote of support if that proposal reaches 2%, and subsequently any voters that supported the proposal during the incubation period are rewarded at the end of the live vote.
Let me give two examples for clarity:
- Example 1:
- Voter A votes in support of incubating proposal P1. Voter B does not vote to support incubating proposal P1
- P1 reaches the 2% minimum support threshold, and goes to a live vote. At this point the proposal time remaining for P1 is reset, and wait for quiet rules are applied in order.
- At this point, Voter A’s vote of support of P1 while it was incubating will be applied to the live vote for P1. Voter A will receive rewards regardless of if the live vote passes or not, Voter B will need to vote on P1 to receive rewards
- Example 2:
- Voter A votes in support of incubating proposal P1. Voter B does not vote to support incubating proposal P1
- P1 fails to reach the 2% minimum support threshold within the 2 week incubation period, and drops off the ballot.
- Neither Voter A nor Voter B receive and governance rewards.
This proposal is very similar to (Proposal to restrict rewards qualification to a threshold and restrict visibility) in many ways, but differs in how incubating proposals are treated differently than live NNS proposals in the following ways:
- Incubating proposals stay open for 2 weeks, whereas live proposals stay open according to wait for quiet rules
- Incubating proposals can only be approved (or ignored), whereas live proposals can be approved, rejected, or ignored
I see the major difference (in terms of backend implementation) as the amount of time that proposal is available, and ensuring that reject votes cannot be cast until an incubating proposal goes live.
I’m curious what the community thinks about automatically counting a support vote on an incubating proposal as an “Approve” vote on the live proposal should that proposal reach the 2% minimum support threshold. The alternative would be to make voters vote again the proposal when it goes live, which I don’t believe is necessary. I’m inclined towards the former, but this isn’t a make or break decision in my opinion. I’ll update the initial post to clarify once there’s more consensus and feedback around how this will work.
2 Likes
I like the simplicity of Proposal to restrict rewards qualification to a threshold and restrict visibility and I’ve asked the board to let me move forward with submitting it. It is a stepping stone to this more in-depth proposal anyway. As @cryptoschindler said, it mostly works now. A few changes will get spam off the big board and anyone who puts forward some effort to get their motion considered will get their full time of diligence. You can think of mine as the equivalent of the Robert’s book of order, which might be a decent thing for us all to take a look at, where on a board someone has to ‘second’ a proposal before everyone considers it. The bar is low, but it is off the ground.
3 Likes
I think it makes sense either way.
I do like the idea that the incubation period is just a time of waiting for a threshold of voting power to “second” the proposal to make it go live. Offering to second the proposal doesn’t mean you have to
vote in favor. It could just mean you think it is a proposal that is worthy of full consideration by the voting body.
1 Like
I think this plan is very bad
-
Do you know the state of the NNS before the weight of the motion proposal was increased? You can check it out, #34839 proposal. In fact, Not even 2% engagement without great incentives,Even less likely to reach a 2% approval rating
-
If you look at the voting curve of the motion proposal, you can see that many people actually have more than 2% of the voting weight, and setting a 2% threshold will only give certain people privileges
also
-
It cannot solve the reward problem, I only need to change the content, you can let the whales have enough reasons to support my proposal to get the benefits. You can check my early proposal
-
It cannot solve the Attack proposal. If most voters will view the incubation-based proposal, then the latency design does not solve any problems, it will still become the broadcast of the community,
If most voters do not need to see the incubation proposal. The incubation proposal will only be manipulated by the giant whale. (34839 proposal forum post has more than 200 replies, there is no 2% participation)
Wow, I’m just reading your proposal now. We have thought very similarly on this, I think my proposal provides a practical way to do this: Multi-stage Governance Proposals, Starting w/ Stage 0 and Stage 1
1 Like
Haha yes they are nearly identical, glad you came to a similar conclusion!
Feel free to take some of the ideas from my proposal and incorporate them in with yours, I’d actually rather someone like you end up submitting the end proposal b/c of your reputation in the community.
To solve the financial incentives for passing governance proposals (our solutions just help with visibility and advertisement), I recommend reading through this proposal.
This proposal actually stems from some earlier ideas in this community discussion, where I had the idea for proposals that hit the support threshold to be released live to the NNS at a beginning of the following week in order to allow voters to have some control of their own individual voting schedules, which would in turn promote more manual voting and time for people to do their own due dilligence on proposals.
2 Likes
From a UI/UX perspective I would like to see:
-
a neuron scoring system. A high quality neuron will have a high score, i.e. historical proposals from this neuron has passed at a high rate and vice versa. The score should also depict how many proposals a neuron has made, how many of these has passed, how many has been turned down and maybe how high pass rate and turn down rate has been on average.
-
indicate if a neuron is submitting a proposal for the first time
-
drill down in historical proposals from a specific neuron
-
more ideas?
All these type of filtering and sorting tools to slice and dice would be great from a voter perspective imo.
Thanks for you thoughts and ideas regarding neuron visibility, but I wonder how different that is from just using the internet computer dashboard to look up a neuron.
(I believe this link is for the ICDevs neuron)
The NNS team could consider integrating IC dashboard links into the NNS, but then you’re coupling those two services (what happens if the IC dashboard goes down, like ic.rocks did last year).
It’s important to realize that “high quality” and scoring is subjective - I don’t think we should penalize neurons if they had ideas that were previously unpopular. Every new proposal is a new idea and a fresh slate, but one can still see how the neuron voted in the past.
@justmythoughts let me clarify.
Nuron voting history <> Neuron proposal history. One could use the internet computer dashboard as you propose, but for the sake of simplicity, I would argue that it would be wise to have the overview easy accessible in the NNS.
I also agree with the fact that a high-quality neuron is subjective, but I am not referring to penalisation here. What I am proposing is rather statistical by nature. Generally speaking - the number of total proposals, number of passed proposals and number of rejected proposals simply gives you a direct glimpse of how a specific neuron has “performed” historically. I am simply suggesting metrics to add to a filtering tool. If the proposal from @lastmjs gets traction we would still need tools to identify the proposals that we want to transition from stage 0 to stage 1 without having to read throw each and every proposal. Given many proposals (where many will be spam) we need to find a way for quicker/easier identification of the proposals that are of “not too low quality” → high “quality”. First-time proposers should of course also be considered.
I believe an MVP for stage 0 and stage 1 voting should first be agreed upon and after that discussion around tools/traits to actually filter out relevant proposals should come later. To dismantle spam one needs to incentive people for doing right and that reward needs to be greater than other voting options because people will always maximise rewards by nature. How to solve that is however much easier said than done!
1 Like
This is good. We just need to make it so incubating proposals are hidden by default