[PIP-11] [Meta Alert] Proposal to Formalize Proposal Process



I’d like to propose that we take a step forward in our self-governance and add an official community proposal process. I’d like to propose that the following steps be taken prior to advancing a proposal to official status on our snapshot.

Note: For the time being, I think it makes sense to empower the devs to circumnavigate these guidelines, especially in matters where time is of the essence.

Proposed Proposal Process, First Draft

  1. Discuss ideas in Discord, Telegram, and in the Governance channel on our forums. Collect opinions and insights and craft a thorough and well-aritculated proposal.

  2. Post your complete proposal to the “Pickle Improvement Proposals” category on the forums. During this stage, we encourage the community to suggest changes, edits and to write dissent pieces.

3. Rather than editing the initial proposal, the “proposer” will incorporate edits into new posts on the same thread until a version can be crafted that garners widespread community support.

EDIT_1 3. The proposer will edit the initial post to add or subtract based on contributions from the community. All edits must be clearly marked in the proposal.

4. The community will signal their support by using the <3 (heart / like) function. Once a version has been posted that has 20 “likes” (subject to change over time), the devs will officially announce (using announcements in discord) a 24-hour period to review the proposal prior to posting to snapshot.

EDIT_2 4. The proposer will include a poll to show support for their proposal. The proposal can be finalized once one of two metrics have been achieved: 1. 20 or more votes in the affirmative OR 2. Greater than 75% support, 48 hours after posting. Whichever of these comes first

EDIT_3 4. The proposer will include a poll to show support for their proposal. If after 24 hours, the proposal has received more than 75% votes in favor, the devs will announce it to the community. This triggers another 24-hour review period PRIOR to posting to snapshot. If a proposal never reaches 75% support on the forums, it will not be announced for official review and it will not posted to snapshot.

EDIT_4 4. The proposer will include a poll in the forum thread to gauge support for their proposal. In order for a proposal to be advanced to the official voting stage, it must meet three criteria:
a. Posted on forums for more than 48 hours
b. Received more than 20 votes on the poll
c. Received 75% “Yes” votes
Once all three of the above are met, a final 24-hour review period is announced.

  1. Both before and during this official 24-hour review period, community members may write “dissent” pieces and tag them as such on the same thread. The text from the post tagged with “dissent” that has the most “likes” should be included in the proposal on snapshot below the language of the proposal.

  2. All Community-created PIPs EDIT_6: that meet the criteria of “community action” should be posted to snapshot with the following details included:
    A) Text version of the proposal
    B) Text version of the most popular dissent piece (when applicable)
    C) A Link to the official thread for the proposal.
    D) The actual button language should be consistent every time as well except in cases where multiple options are presented in the proposal. Buttons will have the text:
    a) Implement this proposal as written
    b) Do not implement this proposal as written

  1. Once a proposal has cleared the 24 hour review period, it should be posted to “Core” by the dev team and announced on the announcement channel in discord.

How to get a community vote on snapshot
-Collect Opinions
-Craft Proposal
-Meet these criteria
1) 48 hours up
2) 20+ total votes
3) 75%+ votes in affirmative
-Devs announce proposal on Discord with 24 hour wait period
-24 hours to write dissent pieces
-Official voting begins. Proposal posted to snapshot including most popular dissent piece and two options: “Implement Proposal as Written” and “Do not Implement Proposal as Written”

EDIT_5 A Note On Community Proposals
As we work towards self-governance, it’s extremely important to understand the purposes and limitations of community proposals. Populist “wish list” items that do not meet the fundamental criteria of “community action” cannot be expected to progress. Here are a couple types of examples of what does not qualify as community action:
1- Personal / Real World Implications. For exmample: “Vote to Compel 0xPenguin to Change his Name to 0xPICKLE” might be popular, but it’s not why we’re here. “Vote to Have Devs Reveal Their Identities” is also not within the realm of community action.
2- Feature Requests. While feature requests may be voted on, they should not be considered binding, especially in cases where they may present additional risk, cost, or complexity.
3- Detrimental to the Protocol. An example of this would be something like “Vote to distribute the entire dev fund to the wallet addresses that vote YES on this proposal”. Self-explanitory.
This list is likely to grow over time, but the idea here is that we all work in good faith to understand the limits of community governance. I’d like to think I can speak for most of the active members here in saying that we trust that the devs will act in good faith at all times when considering these and any new limitations to self-governance.


Edit_6 (10/10) Added a phrase to make clear that proposals that violate the guidelines presented here and in other places will not be added to snapshot in any official capacity

If possible, I’d like to use this thread as a meta-experiment on how this could all work out. Please use your like button to signal that you would support the proposal as written. Please suggest edits if you have them and please write dissent pieces tagged with “DISSENT” at the top if you disagree with the very nature of this proposal.

I’m a bit self-conscious about number 7. It may be that the right solution is to have the community member post to “Community” but the devs still announce. Curious your thoughts.

Thanks in advance!

  • Submit the proposal as written
  • Do not submit the proposal as written

0 voters


I’d actually like to suggest an edit to my own proposal.

  1. Rather than editing the initial proposal, the “proposer” will incorporate edits into new posts on the same thread until a version can be crafted that garners widespread community support.

I think that this may become too cumbersome and will require folks to visit the same thread again and again. I’d like to instead propose that the initial thread be edited to include popular suggestions.

1 Like

sure - edit the original but state that it is an “edit” for tracking purposes.

DISSENT! Okay just kidding, I just wanted the opportunity to use it

I think that’s pretty much what we’ve already discussed a few times but appreciate you summarising/formalising. Couple of thoughts:

  • rather than using the heart and dissent, why not have the forum PIP include a poll with the same proposed options as the snapshot? I think you can do polls here … (Testing)

  • I think there should be a mechanism for the core team to have a weighted say on the proposal before it becomes an official PIP. Short term for any proposals that have a fundamental impact on the project (eg community propose the Dev fee should be 0% therefore the Devs can’t afford/want to continue). And longer term on anything relating to pJars or things that require fundamental coding updates … Because well they have to do the bloody work and need to be happy it’s feasible/reasonable.

Otherwise let’s go, crack on.

Poll: does this work?
  • Yes
  • No
  • Maybe
  • Pppiiiiiiiiicccccckkkkkkkllllllleeeee

0 voters

I’ve incorporated all your feedback into the initial post!

This whole process is getting meta af but I’m loving it. Please signal your support for the new process by voting in the poll attached to the initial post.

Thanks so much for your input guys, it means a lot!

1 Like

Hi there!

I admit, I don’t know exactly how the snapshot-voting is evaluated, but I feel the snapshot voting could be given more meaning by having one more option. The purpose of that is to introduce some sort of “quorum”-threshold. That needs to be defined aswell, of course.

The additional option could be “Withhold vote, a.k.a. I support the majority vote by making it reach quorum”. Just a suggestion.

Further more, I feel there should be a process for what to do if a proposal is not accepted. Just starting the whole process again, might be ineffective. Maybe directly add another option to the snapshot voting “Do not implement this proposal as written, reiterate discussion”? Only if there is an indication, that there is interest but the details are wrong the proposal is allowed to be made again?

Yeah I spent quite a bit of time trying to figure out if a third option would be helpful. I want to avoid introducing too many layers of complexity at once though. To be entirely transparent, it’s likely that we’re going to have a group of contributors that are highly engaged in governance, and a large number of folks who do not participate.

  1. Quorums:
    Implementing quorums and the like at this stage could stall progress. The purpose of quorums is to make sure that proposals are only allowed to go forward when a large enough percentage of the community has had a chance to review. I believe that we accomplish that with this proposal be creating a review process that spans several days.
  2. Adding a third option:
    I like this in theory, but I’m not sure if it’s required given the assumptions of this proposal. If we think about this critically, these are the actual opinions that one could have about a proposal:
    a. I support this as it is
    b. I sort of support this but not as stated
    c. I do not support this at all
    d. I don’t have an opinion on this

With my proposal as written, anyone who did fell into category A would vote in the affirmative, and anyone that fell into B or C would vote in the negative, and anyone else would abstain. This only works if the assumption is that any failed vote would be immediately picked up in governance and refined until a version is presented that has support

I know this has been a bit rambling, but my personal feeling is that the two category system is sufficient and that with time, we’ll start to know that a “no” vote doesn’t mean “this is dead” , it means that it will be discussed further, refined, and proposed using new language.

I hope that helps describe the reasons I feel that we should stick with two categories for now.

As a caveat - I think that a category “Abstain” would be an interesting thought experiment. It would show what portion of folks had encountered the proposal but did not feel strongly either way. While think is interesting, I’m not sure that it provides anything valuable to governance at this stage.

Yes totally agree this needs resolving but is a separate discussion.

This works.

The other option on voting, given that the initial post gets edited, is to insert EDIT polls in subsequent posts … But that might be over-complicating given this is just a signal for a snapshot vote.

Yeah I think that we should respect the fact that we’re not dealing w/ a huge population of voters and make this as simple as possible. The main purpose of this was to create a system that provided:

  1. A clear path from ideation to snapshot
  2. Enough time to formulate / refine / debate the ideas
  3. A platform for dissenting opinions to be referenced in the actual snapshot proposal.

The idea of introducing options other than “Yes” and “No” is an inspired one and while I don’t think it’s an outright bad idea, I don’t personally feel that it’s necessary and I believe that it adds unnecessary layers to the process. Every option I stated above can be boxed up within “Yes” or “No”.
a) I support this as is - Vote Yes
b) I sort of support this but not as stated - Vote No
c) I do not support this at all - Vote No
d) I don’t have an opinion on this - Abstain from voting

When considering the process used in the US to get a question on a state ballot, they include:

  1. Enough time to debate this prior to voting
  2. A platform for dissenters to articulate their opinions prior to the vote
  3. The actual ballot includes a paragraph from both sides articulating their arguments
  4. Only two options: Yes, or No.

It’s for all these reasons that I believe we should wrap up the multiple options into Yes or No and trust that failed votes that showed broad support (just not as written) will return to the forums to be further sculpted.

This is actually a good opportunity to test out this whole process. We’re continuing our trek down META lane – If one of you feels strongly enough about this (we should have more than just the two options) then write up your reasons, tag your post at the top as “DISSENT” and we’ll include it in the vote!

This is turning into quite the experiment in self-governance and I’m really enjoying it! Thanks for your contributions.

1 Like

Two pieces of feedback I heard from the community that I incorporated into my latest edit:

  1. It was suggested that a hard number for likes was arbitrary and didn’t scale w/ the platform. Instead of saying “After 20 votes “yes””, I only included the 75% show of support.
  2. It was also suggested that the 48-hour period PRIOR to the “official” 24 hour period might be unnecessarily cumbersome. As such, I’ve updated it to 24 hours.

The net result is summarized here:

In summation:
-Collect Opinions
-Craft Proposal
-Reach 75% Support after minimum 24 hours
-Devs announce proposal on Discord with 24 hour wait period
-24 hours to write dissent pieces
-Posted to snapshot including most popular dissent piece and two options: “Implement Proposal as Written” and “Do not Implement Proposal as Written”

While I do feel that 24 hours is not a ton of time to hammer out the finer details of a proposal, I think this will lead to folks who do not COMPLETELY support a proposal as written instead voting NO on the poll initially and only after sufficient edits are made, changing their vote to “YES”.

The net effect of this will be that only those proposals that need no (or very little) edits will be cleared within the first 24 hours.

I’ve requested that the devs announce this proposal to the community so we can move it forward and collect dissent pieces (if needed) prior to posting to snapshot tomorrow.



Bump. Added edits 4 and 5.

Edit 4 once again tightens restrictions to include a quorum (20 total votes on forums) and lengthens required time to 48 hours.
Edit 5 adds some necessary caveats that detail the boundaries of community action.

NOTE: If you haven’t voted (yes or no), please do so!

Voted. Let’s formalise this :smiley:

Thank you Sevenz! #PicklesDoPolitics

1 Like

I know we are trying our own process here but it is worth looking at an already working system that has a good format to drive discussions YIP-0. This would be an easy starting point. I don’t have time to do much digging / a more formal proposal at the moment but wanted to drop this here anyway.

1 Like

Thanks @jintao!

I definitely reviewed that prior to drafting this. Some of the ideas I presented are borrowed from Yearn, some from real world politics, and others are based on the specifics of our platform. If there’s anything in particular from Yearn that you think we should implement, please let me know!

1 Like

Yeah, sorry I did not point that out in my post. I meant he format for posting a PIP for example just so they are all looking similar and easier to read from PIP to PIP.

1 Like

Just a question that has been niggling since yesterday …

Is this PIP11 process only for community led proposals? Do proposals the core team want to put forward get to bypass the process?

I ask because PIP12 went straight to forum and snapshot simultaneously. I know PIP11 hadn’t passed at the time so maybe that … Or maybe it was just @BigBrainBriner going rogue :cowboy_hat_face:

Not necessarily an issue but worth clarifying I think. Maybe there is benefit in core team having bypass powers to move things along quickly if there is solid benefit in doing so.

Just to clarify - this PIP for formalizing the proposal process only applies to community proposals:

This process supplements what the core team has been doing thus far in announcing proposals (usually after extensive consultation with the community). Hope this clarifies things :slight_smile:

1 Like