Proposal Rules and Guidelines
This section is designated for the final versions of proposals which have been previously discussed in the Community Discord, DAO Discord, or the general forum. Any other proposals will be deleted. Based on the feedback from the community, a Snapshot vote can be called.
NOTE: see our Governance Framework documentation for more details on our governance process.
Distinction between an RFC and KIP:
A RFC (Request For Comment) is likely to be done either by a) an external organisation seeking a partnership with Klima that hasn't been done internally or proposals in the initial stages where the comments provided will inform a more formal proposal that follows.
Layout for RFC
Currently there is no formalized procedure for RFC discussions under General. Each RFC will have its own format, but should follow the general structure of KIPs laid out below:
- A summary of the proposal comments are being requested on.
- A section explaining the background of the organization or context of the proposal.
Rules for KIP Publication
- Include a KIP (Klima Improvement Proposal) number in the post title, followed by a colon (":").
- Add a poll option in your proposal.
- Ensure the proposal has been discussed on Community Discord, DAO Discord, or General Forum prior to posting in this Proposals section.
- Be ready to engage with the community e.g. by answering their replies, addressing their concerns.
Criteria for a Snapshot Vote
- The proposal should be live for at least one day.
- The proposal should receive at least five posts from different members to ensure sufficient engagement.
- The author should indicate clearly when the Snapshot vote shall commence (see the Template section below).
Template for Forum KIPs
A simple description of the proposal's end result and desired change; should be no more than a few succinct sentences.
Explain why this proposal is necessary or useful for the protocol. The author is encouraged to add visual elements such as charts to support their arguments.
Lay out your proposal - explain how it is going to tackle the issue at hand and present the action items.
The polling process begins now and will end at HH:MM UTC on DD/MM/YYYY. Assuming the forum proposal is approved, it will advance to Snapshot.
For: Action taken if this proposal is accepted.
Against: Action taken if this proposal is rejected.
Layout for Snapshot KIPs
Since Snapshot limits the length of proposals to 14k characters, and the formatting options are more limited, it is advised to only include enough content from the forum KIP to communicate the essential elements of the proposal. Then we simply provide a link to the forum KIP for reference in the
Discussion input box.
Note that just like Discord and the Forum, Snapshot supports Markdown syntax, so you can format the proposal appropriately.
Best Practices for KIP Publication
To keep the shipping of KIPs efficient and avoid a backlog of KIPs, the following guidelines should be respected.
Batch KIP Publications to Minimize Voter Fatigue
Set certain days and times for when KIPs can be expected to be published so that there is coordination within the DAO, and within the community on when to expect governance decisions can be posted, allowing a smooth transition between KIPs and Snapshot and avoiding voter fatigue from many KIPs being posted on subsequent days.
Proposed time: 17:00 BST
Proposed days: Monday and Thursday
The benefit of the time provided is that this is when office hours on Thursdays occur and so that there will be many ‘active’ community members around and the people on stage can answer any questions around any proposals.
Mondays and Thursdays allow a smooth transaction between posting:
Monday at 17:00 BST: KIP X posted to forum and allow 3 days to discuss
Thursdays at 17:00 BST: KIP X posted to snapshot , KIP Y posted to forum, both for 4 days of discussion/voting (to take into account weekends)
Following Monday at 17:00 BST: KIP X finishes snapshot, KIP Y goes to snapshot and KIP Z can go to the forum.
This will allow for a smooth continuous flow of governance proposals
Internal Review Prior to Posting
KIPs should be posted to the forum only after a member of the Core Team has reviewed the proposal. The proposal should also be reviewed by the Policy Team for clarity and accuracy prior to posting on the forum.
Avoid Bias in Polling Options
The polling options should aim to avoid biassed language that might influence the outcome of the poll.
Note: The above are guidelines to adhere to in an ideal world. However, it is understandable that this may not always be possible.