[Proposal] Introduce an incubation period and minimum support threshold for governance proposals

@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 :slightly_smiling_face:

2 Likes

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

3 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

@MrPink13 and @wpb

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.

1 Like

@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) 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

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

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

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

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

2 Likes

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.

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

@namyIC

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

In the context of the recent antisemitic spam proposal that was just submitted to the NNS, that all voters are now forced to view and vote upon or face loss of voting rewards, I’d like to resurface this proposal.

It would be fairly easy for a malicious interest to spam the NNS with such proposals to make a mockery of the current user experience that forces voters to see and vote upon every single proposal (including governance proposals) that hits the NNS.

The goals of this proposal are:



I’m open to alternative solutions that protect voters from being mandated to vote on every proposal, no matter how unpopular it is. As ICP receives more attention, we need to think hard now about how scaling the viewing and voting of NNS proposals will work so that this abuse does not continue.

Due to the content of the proposal, for many this is already is a more serious problem than the original spam issue, which was an embarrassment to the ICP community.

2 Likes

It would be great if this kind of mitigation strategy could be implemented for spam that is submitted for advertisement or attention. Some proposals should definitely not make it past the min threashold.

1 Like

I think this is a smart idea if the incubation duration do not delay progress of potential or authentic projects and if other parameters other deterrent parameters can be met before Incubation.