Please suggest edits and changes.
All feedback welcome.
As currently there’s no set formal procedure for any CGP guidelines, I thought maybe we can put something together.
We can use this forum to discuss CGP proposals.
Broadly, any proposal made should atleast have the following:
VII. Pricing and terms.
VIII. Additional notes.
As, CGP will be a very simple implementation of onchain allocation of funds via decentralised voting. I was thinking, we as a community can debate and see what’s the best way forward.
One idea I have is, first we/anyone make a proposal here on the forum following these above guidelines.
If the proposal has deliverables then we first here on the forum approve it/disapprove it off-chain. If approved here, the proposal’s ‘who’ works on it and delivers the ’ Deliverables’ set in the proposal.
Once delivered, then he/she/they makes the proposal with the amount specified here, on the current round of on-chain voting. And we as a community ensures that this proposal with the agreed amount wins the vote.
I can probably give example as well, if it’s not clear.
it would also be good to explicitly talk about testing strategy. For instance can we have a framework that makes it easy to validate a proposal? Or show that a proposal does not introduce bugs to the core of the system.
Also what happens if a badly implemented proposal gets voted and merged. What does the process for fixing it look like. I understand that this would vary depending on what the proposal covers but that implies we have different categories of proposals. What are those categories?
I think you are mixing 2 things. My OP is regarding the use of common goods funds proposals, which once CGP is functional ‘winner takes all’ voting every 10k blocks (i think) not the protocol upgrade proposals voting which I think currently is every 6 months.
But I will let maybe @nathan to answer your very important question
You are right there are two potentially different things there.
There is the voting for upgrading the protocol and there is voting to allocate some token to the execution of a proposal. My initial comment assumed the former though I think it is also valid in the latter.
For instance, I might want to propose to improve the UX of the wallet or to add new apis to the zen.js library. These two things do not necessarily change the protocol in any way though the proposer might be able to demonstrate how this would bring benefits to a group of users.
If the proposal is for software then I would expect it to contain some test strategy or plan or mitigation for failure modes.