Governance Process Summary

Hi, following some discussion on the Discord, I would like to formalize the governance process. There isn’t much changes, it is just a description and getting on the same page as to what the process is.

STEP 1: RFC
Start a new conversation under the RFC tag and post it here. The message should contain:

  • Background - what are your observations and identified issues?
  • The core of your proposals - what is your idea on how to improve the state of the art?
  • Dependencies - What is needed to introduce the change?
  • Risk assessment - What can go wrong?
  • Open Questions
    (template)

STEP 2: Discussion

  • message #:brain:brainstorming-and-:bulb:ideas channel on Discord to draw people’s attention to the RFC.
  • monitor the discussion and gather feedback on BOTH Discord and in your forum topic.

STEP 3: Proposal

  • Give it about two weeks before you post, in the same topic thread, your proposal.
  • The proposal should be a refined RFC that includes all the suggestions from the discussion.
  • Change the tag to “Proposal”.
  • Give it another week to see if there is any final feedback.

STEP 4: Snapshot
Move into a snapshot vote. The snapshot vote can be created by any wallet that has at least 50BAL.

Note 1: the template for the RFC/Proposal can be also found here
Note 2: The timing in Step 3 is very arbitrary - if there is immediate consensus, you could move to a Proposal after 7 days. Don’t do it too early, tho - you can lose valuable input from someone who was out on holidays or wasn’t paying attention.

TIP Make sure to facilitate the discussion. If you are not getting much reactions, make sure to bring the proposal up on Discord and maybe even tag people whose feedback you’d like. (just don’t tag randomly, just because someone has been active on the forum or Discord - these are likely to be ignored)

Comments?

2 Likes

This makes sense. Do we have any thoughts on a process for expedited proposals, when there’s something more time sensitive?

Vast majority I could see going through something like this, but historically there have been a couple examples where a proposal has needed to move faster than this process would allow, usually to fix something that’s not working properly for some reason (e.g. an unforeseen consequence of an earlier proposal).

Wish I saw this thread before writing my most recent discussion thread, oh well. That would probably be in a “pre-RFC” stage (“Ideation Stage”) where we want to settle on something to go to RFC, maybe? As it’s not a single idea to be implemented yet but discussion of different approaches that could be taken.

Thinking further, I’m less sure of the 50 BAL minimum requirement for proposal posting too. I think this is likely to result in Snapshot getting spammed (which doesn’t look too good) & also has the potential for lots of proposals to go up which are driven by reactionary concerns, that then have to all be voted against creating significant overhead for governors.

Is a half-way from the current system to say that a proposal needs to be sponsored & posted by either a Balancer Labs team member or Baller? That means it’s broader than currently, but not anyone can post something up.

Perhaps also something that a proposal has to go through the correct process to be valid, regardless of how a snapshot vote turns out.

Fair points! IMO we can always decide to increase that 50 BAL threshold if there is indeed spam. But for starters we should try to be as inclusive as possible, and not letting people with good ideas but little BAL post proposals on snapshot would be a pity.

Also, I think our Baller @jnapier (please correct me if I’m wrong) said he would be up for making sure snapshot spams are deleted and also that the proposal process we settle on is respected (e.g. a proposal should not be posted directly on snapshot without going through the previous steps). If @jnapier misbehaves or goes rogue (which I doubt but we should always consider happening) governance can elect another Baller or community member to take on that role.

problem is if jnapier’s on vacation and someone submits a snapshot that passes with 1000 BAL or something. We can always ignore it but still, not the greatest look imo.

Also think including a poll in discussions and minimum threshold of yes votes / majority in favor makes sense.

Even dodgy votes sitting on Snapshot for hours looks bad though. I think it’s important that there is pre-vetting before Snapshot, looking at projects with decent governance they all seem to have that at the moment to some degree.

I agree that anyone should be able to go through the entire forum process regardless of their wealth or level of involvement, just think publishing the vote on Snapshot should have a quality & process check involved. It’ll save things like proposals going up with the wrong time settings, weird vote options, bad formatting, etc too.

When people see something to vote on, on Snapshot, they should be able to assume what they see is final and important to vote on.

1 Like

All great point @bakamoto20 and @DavisRamsey !

Is there a way for the submission for review/vetting to be done on snapshot directly (unvetted proposals wouldn’t appear publicly) or would this be done on the forum thread?

@bakamoto20 could you please share some more of what you’ve seen as standard processes at projects with decent governance?

I think I answered on Discord, but to continue the discussion here: I am wondering if we want to have a money limit or maybe some kind of amount of community contributions - eg. you have to be actively contributing/participating in discussions and then you can request being added by one of the existing members? Cause it should be simple to have a group that is responsive enough and starts the vote whenever someone reaches out. We could have a discord channel for it or an airtable of sorts.

Some other remarks from Discord included @DavisRamsey pointing out that currently anyone can make proposals, so it is about moving to snapshot only, so it makes sense to have some barrier there. I am about to propose setting up a bounty for a badging system. Maybe we could use badges (an NFT you get for certain activities) to grant access to snapshot?

1 Like

Haha! A difficult question as I don’t think anyone has it perfected, everyone’s learning. Aave’s is very clearly defined which I like, although my criticism there is it requires someone submitting a proposal to get into the weeds of Github and such: it’s nice for non technical users to be able to run the process end-to-end via a forum then go onchain/to Snapshot for a vote at the end I think (bringing someone from a team trusted by the community to action the final component).

I suppose the argument on the flipside is that it’s not fully decentralised, and opinions could feed into whether proposals go to votes or not, but if something is popular enough to gain traction on the forum, you’d get a lot of backlash if someone refused to let it then go to a vote, such that I think it will be fairly self-regulating.

I don’t have strong views on chorums and voting methodologies really, other than mainly having seen examples when chorums are set so high that it creates problems passing anything. If more community members are able to & choose to run the proposal process end-to-end (where previously proposals were primarily Balancer Labs/partner - led), we should probably look at setting this. Perhaps by reviewing past votes?

1 Like

I think that having an open application process to receive the rights to open snapshot votes makes it as democratic as we need. We don’t need everyone to have the rights. Just people that actually want to do it and a group big enough that a person with snapshot rights is just one tag away.

My proposal: you earn a snapshot right after participating in 5 or more proposal/RFC discussions. There is a channel on discord #snapshot which will serve as a request for opening voting space. I will create a tag on discord for people who have snapshot rights, and they can be tagged by the author of the proposal.

Does that sound like a fair solution?

2 Likes

Snapshot’s API now uses GraphQL for querying results of past votes. Unless I’m mistaken, this could make it quite simple to see how many proposals someone has voted on. This would be an automatic “does this person hold BAL?” check (ignoring the cases where they have delegated voting power; not sure how to handle that case yet) and then we could have some threshold of “you must have N votes under your belt to post a proposal.”

Pro: this is fairly easily queryable without adding the need for a sourcecred or human filtering
Con: someone could still have a voting bot swarm with >N votes.

I would assume a voting swarm would likely have a low amount of BAL on each account, so maybe we could say N votes and 5BAL? And perhaps a small but high enough minimum nonce check?