Thanks for these ideas.
Originally my concern was that if there is a new post for each proposal it might be harder to find them. But indeed, maybe we could have guidelines for naming and e.g., have a new topic or so so that these posts are easy to find.
we hit a road block on posting to the forum due to current restrictions
do you know what is blocking this exactly alread? I assume that this is some sort of bot protection? I am happy to look more into whether this would be easy to change.
Thanks, that a very good catch!
Indeed, I confirmed that the type âupdate unassigned nodes to latest replicaâ is now under the topic âIC OS deploymentâ and would not be part of the topic âParticipant management & Node Adminâ. I will try to edit my original post to reflect this.
Jesse, you got my vote serđ«Ą
Thanks for raising this concern @dfisher and @wpb.
I think it is also interesting to consider how this could be achieved without additional incentives. For example, as @wpb mentioned, it might have an effect if some larger neurons just sit out a few proposals (e.g., if they anyways have a clear outcome). Or indeed it could be an outcome that it is better to have a larger team behind a known neuron. Or different smaller known neurons could span together and e.g., vote most of the time but follow the other known neuronâs vote in case where they missed a proposal⊠I am not saying that any of these are necessarily the best solution, these are just a few ideas to illustrate that it could be interesting to also think about processes etc and not only features to address certain problems.
In any case, I agree that this is an interesting problem to consider, but also think it does not take away the value from this initiative. I agree that this could be discussed in the context of the longer-term solution or as a follow up to the priodic rest of following - which is more targeted at this âsideâ - e.g., at motivating voters to change their following rather than at motivating voting neurons.
Hi,
I am very interested but the compensation is quite low. The workload can vary and the compensation needs to reflect that.
I think this is already reflected to some extent - the estimates that we got from engineering teams were rounded up. It is also deliberately kept a bit open how many commits should be reviewed in depth to account for the fact that it is not possible to go into the same depths every week.
Also, can the engineering team provide some example reports for each task so we can understand the standard of work you require. This would really help us gauge the total workload.
We donât currently have such an example. Maybe as a first step it could help if you look at an example by CodeGov to have a better feeling for the effort? I think what is shared in detail is also something that might evolve. But I expect that the larger effort will be to actually read and interpret the proposal - maybe to undersand this better you could look at a few concrete proposals from the topic that you are interested in?
Also some statistics of expected proposals per month would be helpful.
I think a good estimate for this is to look at the number of past proposals. To do so, you can e.g., go to the dashboard and filter the proposals for a certain topic and average over the last few months and years. We also did so for the estimates. I donât have the exact numbers handy anymore, but I think it roughly the average proposal per week was:
Does applying as an individual hurt oneâs chances for selection? It is confusing on how much manpower you expect for the amount you are willing to pay.
As mentioned by others, maybe a group of people will have an easier time to ensure no proposals are missed. Other than that I canât think of a reason why one person would have a disadvantage, but in the end this will be up to the voters.
Thanks I think this is another thing we can think about, but might address another goal.
Note that for some of the topics you donât need a PhD in cryptography. For example I think the topics âParticipant Management & Node Adminâ can be learned with less technical knowledge.
Sam, as suggested by Lara, Iâm providing a few links to our reports that can be found posted in the CodeGov community on OpenChat. Feel free to browse around all you want. These reports are in public channels. All CodeGov reviewers are expected to write a report that summarizes their finding from their reviews. Each reviewer does it a little differently.
IC-OS Version Election
Proposal 130083
System Canister Management
Proposal 130821 - Governance canister
Invite code to the CodeGov community on OpenChat
Current Codegov team members include @Zane @ZackDS @Lorimer @hpeebles @cyberowl @massimoalbarello @ilbert @tiago89. They have all been excellent resources about reviews of these types of proposals. Perhaps they can give additional advice if you reach out to them.
Hey @NathanosDev would you mind explaining the issue as you discovered from discussions with DFINITY? Why did we decide we canât automate submitting our final summary report to the forum through the GaaS App? Was it restrictions on automated posts? Or was it the difficulty in finding the right forum post? Or both? What is needed to enable this kind of automation?
We need an API key that only the Discourse admins can generate.
Iâll throw out another idea of a process that you could consider @lara âŠ
DFINITY controls the ICA neurons, but ICA was originally intended to be an independent organization and it has significant voting power through 40+ neurons. You could take the total voting power of ICA and divide it equally among all the known neurons that are selected by the NNS to participate in this grant program.
Whoever actually controls the ICA neurons could configure those neurons to follow each elected known neuron on the specific topics where they are elected. This would give these elected known neurons a meaningful voting power that is cast when they vote as soon as the program starts. As time passes, if the elected known neurons change, then the following can also be changed for these ICA neurons. In other words, this change in following doesnât have to be permanent.
DFINITY could commit to not voting on the specific proposal topics that are included in this grant program. After all, DFINITY is the sole contributor to the changes that are implemented under those proposal topics. Wouldnât it be nice if the adoption of those proposals were largely influenced by known neurons other than DFINITY? This would drive changes in follow patterns, especially among people who only care about voting rewards.
If DFINITY depends on voting rewards from these proposal topics, then they could always vote for most of the proposals with DFINITY owned voting power (not the ICA neuron) according to the votes cast by the elected known neurons. Not voting on a small fraction of these proposals is probably enough to drive changes.
DFINITY can still vote if they find a sudden need to reject a proposal after it was submitted. To my knowledge, there is no need to rush a rejection since nothing changes.
Since DFINITY still controls the ICA neurons, they can even trigger a manual vote on these neurons if it is a critical proposal. I would think that can address any security concerns associated with needing an absolute majority on critical proposals.
The ICA neuron maturity could also be used to fund this grant program (assuming DFINITY or ICA isnât using it for other purposes already). There is probably considerable maturity associated with ICA neurons that could substantially improve the incentives for this grant program.
The ICA neurons could play a central role in helping advance decentralization of the NNS on technical topics since they were originally conceived for this type of decentralized purpose anyway. Itâs not a perfect process, but it seems to get us much closer to decentralization. Itâs also 100% process related that doesnât depend on any code changes. Hence, it could be implemented immediately. It also seems like a reasonable baby step on the path to full decentralization over a long time period.
Hi all, I am applying for the protocol canister management category.
For those who donât know me Iâm LĂ©o, ex-DFINITY. I worked for DFINITY for about 2 years as a software engineer. I contributed to various projects such as ckBTC, ckETH, and ckERC20. You can check out all my commits here. I submitted about 35 canisters-related proposals and reviewed even more.
I am also a contributor to WaterNeuron, which aligns with this initiative of having more external contributions to governance. Hence I will vote with what I think is best for the long-term interest of ICP. Feel free to send me a message on the forum or on X if you have any questions.
Ideally, you want to use the voting rewards directly to incentivize this behavior. Here, weâre acknowledging that voting rewards are a bit useless and redirecting some to the grants. Taking into account that weâre printing about half a billion dollars in rewards per year, we probably want to make them useful.
Thatâs exactly what the long-term solution is likely to look like (as I understand it). These grants are just a short-term interim solution to get the ball rolling and encourage some new faces and competition into the mix (as exemplar followees). I think this is explained in the announcement.
Taking into account that weâre printing about half a billion dollars in rewards per year, we probably want to make them useful.
I think your right to point out the privilege and responsibility that followees hold. There are certainly cases where they should be held to a higher standard - I hope this will happen over time. But first we need more skilled people to get involved, and we need to incentivise people to follow neurons that can evidence that they do a better job than other neurons. On a related note, you may find this weekâs IC-OS proposal interesting in this respect â
I think @skilesare is onto something with his suggestions. I think ultimately weâre going to need consequences for irresponsible voters (but then weâd need a way of bating/detecting irresponsible voters, and this would come with a whole load of implications - but I still think itâs going to be needed in some shape or form). Competition is pointless without a selection pressure.
Hi Austin,
This is going into the âshould we motivate with a carrot or with a whipâ?
I always tend towards the âcarrotâ alternatives, the âwhipâ options frequently have unexpected effects, especially under a context where the âdemanderâ actually has little power over the âsubjectsâ.
Allow me to exemplify, imagine such a system goes live, I am afraid that:
we will put a responsibility onto Node providers, that they are not prepared to assume. Wouldnât they feel frustrated? How would that affect in terms of some of them leaving or new ones not joining? We are putting a significant stress (because itâs not easy for them), without any real power over them.
If the motivation is only âavoid being slashedâ, arenât you afraid that their efforts will stop as soon as that is ensured? They can hire a team whose only purpose is to detect and avoid any âbasic flawâ, but what about helping the Dev teams with comments / requests for clarifications? What about requesting that all significant changes are in the logs? What if a reviewer sees a potential bug / downtime / security issue?
In the end, the question is, do we (as NNS) want the best possible review service (because they avoid bugs, downtime, security, misalignment) and want to design a system that provides for that, or we just want to prevent bad behaviour. I think your solution was targeting the latter, while I feel the NNS wants the first.
Do you agree that the problem should not be a responsibility of Node Providers, because itâs not under their zone of expertise? so we shouldnât suddenly add / request such a significant responsibility into them, for sure it will go wrong.
Hope these arguments help somehow improve the final design.
Hi @lara ,
Apologies for the delay in replying, only now had a good opportunity to dig deeper into this thread again.
Will try to answer all questions below:
Our worry is more on the final design, not these grants phase only. If you are already splitting into smaller teams and each having known neurons, we assumed the final design would be for NNS to payout bigger amounts to higher VP known-neurons and smaller payouts to lower VP / individual known-neurons.
But from your replies am seeing this might be more âequalâ payments for âequalâ work and try to spread out over as many teams as possible, with maybe a rotation system. We can definitely leave this discussion for a future thread 
The âcore teamâ / âcouncilâ should be small, and be facilitators of the reviewers. Many initiatives can be done by the reviewers themselves, but the finding of funding / requirements, project management, will probably be from the core team.
I am only worried that already on this grants phase we have and are capable of paying for this coordination team, that pays back by generating efficiencies between the reviewers.
Probably the best decision for now is to assign this responsibility to CodeGov / Wenzel and see how it evolves until the final design is ironed out.
Hi @lara ,
So, after reading the discussions so far and thinking things deeper, would suggest the following changes for consideration:
Addition of a âFacilitatorâ Grant, ~1500$-2500$ a month, expecting a team of 2 or 3 part time man-power, responsible for:
Increase significantly the amount for IC-OS proposals (~2x-3x) OR already define layers of expertise and increase the number of teams. While the other grants are âattractiveâ, think the IC-OS is completely off / âunattractiveâ. A few reasons / diffs:
Decrease the amount payed to Protocol System Canister reviews to 1500$~2500$ a month. I find the amount of work and expertise needed to be more fair in that range.
And thatâs all. Looking forward for this weekâs discussions and eventual final design before code gov applies. Thanks again for this work. 
For example Participant management & Node Admin there ~18 proposals per month and and offer of $750. Or $41 at 90% voting rate. Some months have less and some have more proposals.
You cant just consider the total time to complete each task, You also have to consider that this work is being done to support the ecosystem and not as part of someoneâs full time priority. So yes the work is somewhat easy but to get it done one has to get it done with competing demands for that time. Thatâs why there is an issue of low participation on these topics. And its not like one can schedule to do the work over the weekends because voting periods end on different days. Let us properly reward the work and those that will commit to it. This isnât Dfinity hiring an employee.
Lets not get carried away by saying work is easy yet very few are actually doing it.
Iâm 100% with youâŠI almost always prefer carrots to whips. The problem with the current DFINITY stack is that everyone is 100% dependent on DFINITY to produce and bless a replica/system canisters/hardware spec. If we want participation then we need responsibility. If the node providers just want to get rewarded for providing the hardware, I guess that is ok, but they are the next logical piece in the stack because they actually have to run it. It seems to me that they SHOULD be experts in what they are running if they are getting paid to run it. I mean that is mostly a carrot: Youâre going to get paid for running high-quality replica software that doesnât have bugs.
With ETH2 clientsâŠif you run the wrong software your stake gets slashedâŠbut that is a rarity and most of the time youâre getting paid yield on your stake.
The other option is to encourage the building and running of multiple replicas and to pay software teams if their replicas are chosen by the nodes. Generally, some kind of market forces for the production of quality code that encourages many people to become experts is what we should be going for.
Hi all,
Have been talking internally, and me, as a member of ICP HUB PT (https://icpportugal.com/), would like to inform of our intention in supporting this effort in any way that is needed.
Depending on how many applicants we have for each topic, we can apply to the most needed topic. We expect to apply to either Node Admin or Subnet Management.
We are setting up a decentralized neuron that will follow 3 key staff members that are committed in looking deeper into any topic we assume responsibility over. Then we will also use our social channels to bring awareness to any relevant proposal and why we voted the way we did.
Will wait for more developments in this thread and once an application formalises, will inform here.
Thanks and have a great day 
Thanks everyone for their applications, inputs, and questions.
We edited the original post / proposal slightly as a response to the feedback.
You can see the difference by using the forumâs function to see the edits, but I will also list the main changes in the following to make sure they are clear.
We are looking forward to many applications - please feel free to also forward this to others who might be interested!
Have a great rest of the day!