FIP-57: Guidelines for DAO governance procedures

Governance Process
#2

I support nearly all of these guidelines. some small nits:

I think this can be loosened a bit. sometimes snapshots occur out of order for unforseen reasons. assigning a FIP at time of last call might be better, or even just when a proposal has gained sufficient momentum for it to be clear that it will be voted on sometime soon

72 hours feels too long. I dont think any delay requirement is necessary, because snapshot passing means general consensus was already reached to some degree, and there is already a 1 day delay on voting once a proposal is submitted to the DAO

I think the reason for failure is really important here. there are failures over voters disagreeing, versus failures over some small problem in the snapshot that can be quickly fixed. for that reason I am hesitant to have a strict rule here

on strictness, I also think that these rules should be stated as extremely strong recommendations rather than strict rules because sometimes shit happens and it will probably take a few iterations before we can craft a perfect set of rules

overall I think it would be great to have these guidelines and have them prominently displayed so that people get a better idea of how FEI governance works and how they might participate

2 Likes
#3

Just want to point out this page in the docs : Fei Improvement Proposals (FIPs) - Fei Protocol, that can be used as a baseline for governance process improvement proposals.

2 Likes
#4

Thanks for pointing this document out! With the exception of the 48 hour last call, these proposals do not overlap with the FIP document points; these proposal are indeed meant to compliment and further refine existing parameters. ( I will remove the mention of the 48 hr last call, and directly reference this document you’ve linked as the “parent” parameters of my proposals)

Though in light of the Fei-Rari merger, clearly the snapshot process was not in accordance of those existing guidelines. I agree with Storm that these are meant to be “extremely strong recommendations”, but I also want to outline some of the measures where the community can take down FIPs that are clearly disruptive or non compliant; The original FIP document did not provide any recourses.

you raise a good point that there is already an timelock in onchain voting. Given that the authors should announce the intended time of on chain voting anyways, I agree that we can strike that clause out.

I included this clause, especially mentioning “original form”, with the intention of prevent rapid redeployment of the same measure multiple times in quick succession. Given the high percentage of FIPs that passes, every FIP that had outright failed usually have serious issues and requires extensive editing. Of course I am open to debating the language of this clause more, as I agree that it shouldn’t be an impediment to FIPs that are mistimed, or require minor edits.

#5

Lets make this 24h to be a little leaner.

I think from Last-Call is more logical, as we do it now.

Disagree, there is no reason to wait for an on-chain vote once snapshot has passed. The DAO vote time should be announced at least 24 hours before on-chain but that can be during the snapshot window.

I think we can leave this unspecified. FIPs should be able to be reposted pending discussions without too much process overhead.

I think this is great in spirit but a bit strong. As I’ve said before, I don’t think we should be strictly beholden to our processes but rather use them as guidelines to help facilitate better governance with clearer communication. Technically speaking, any of these guidelines can be circumvented, but proposals which do so should be heavily scrutinized by the community. This doesn’t mean they should be forced to comply.

1 Like
#6

I’d like to add processes for when the guardian can veto a proposal, as it shouldn’t be fully discretionary:

  • Unknown payload/proposer
  • Proposal which distributes PCV or incentives to voters on the basis of their vote (bribes)
  • Proposals which add admin control to untrusted accounts
  • Any veto authorized by a TRIBE snapshot that reaches quorum and has at least 24 hours duration (most applicable to OA)
  • A proposal which contains a security vulnerability, verified by a third party such as an audit firm or security researcher.

In addition, we should set the snapshot quorum officially to 10M TRIBE

2 Likes
#7

good ideas

a security vulnerability published by anyone (not just researchers/auditors) should qualify for a veto here

#8

Yes, point is it needs to be verified by anyone not a fei core developer imo to prevent conflict of interest

1 Like
#9

Status: Last call

after having incorporated recommendations from this thread, I present the following draft for a 48 hour last call to suggestions and review, in accordance to the outline itself.
…

In light of the recent controversies due to confusions over the governance process, I’d like to propose some governance guideline practices to ensure that future governance votes would proceed in an orderly manner that is satisfactory to everyone.

Fei Improvement Proposals (FIPs) - Fei Protocol is the currently standing rules of FEI governance, This proposal is meant to supplement the above proposal and incorporate some of the best long standing practices observed by the community. This proposal is meant to aggregate and codify the best of such practices and it is meant to serve as a reference for the future combined TRIBE DAO as well. These draft measures, if approved, are meant to serve as “official governance guidelines” rather than “written laws” for the future operation of the DAO.

Proposal:

  1. All forum proposals should engage in a 48 hour (as described in the original FIP document) last call before proceeding to snapshot. The last call should be announced in the discord governance channel for publicity; enlisting the aid of a mod if need be.

A notable exception would be technical rollouts, or routine contract upgrades such as FIP-48, which can be forwarded straight to On-Chain voting/OA timelock if there are no dissensions. Other measures which are already approved in principle by a DAO vote such as individual LaaS funding, can be allowed to move forward directly to OA/snapshot.

  1. During the “Last Call”, each FIP should clearly state what every voting option would be. The last call post should also indicate any edits which have been made from the original due to the discussions in the forum.

An exception can be carved out for proposals that see no dissensions or edits from the original document. In which case the last call is simply a 48 hour countdown announcement.

  1. Only the author(s) of the original forum discussion post should make the snapshot for that particular motion, or allow somebody else to do so with explicit written permission in that original thread.

  2. Upon the passing of a snapshot vote, the poster should announce in their original discourse post, or on discord governance, the specific time they intend to forward the proposal for on-chain voting/Optimistic Approval. If a particular snapshot is a “temperature check” and not meant to be executed directly, it should be clearly indicated by its authors.

Routine protocol upgrades can be exempt from these requirements.

  1. If a proposal outright fails, the author should indicate whether they intend to repost the FIP after editing its contents with community input. A failed FIP should go through the entire process of a new FIP, including another last call, etc.

  2. If a proposal passes, but the authors feel that an edit to its contents are merited before proceeding with onchain voting/OA; the authors should clearly indicate so as soon as possible. The authors should clearly outline every edit from the proposal that has passed the snapshot. This is particularly relevant for the Fei-Rari merge snapshot, and I encourage the community to comment on needed changes for the Fei-Rari merges.

  3. The DAO guardian should be able to veto existing votes if they satisfy the following criterias:

  • The proposer or payload is unknown.
  • Proposal which distributes PCV or incentives to voters on the basis of their vote (bribry proposals)
  • Proposals which add admin control to untrusted accounts
  • Any veto authorized by a TRIBE snapshot that reaches quorum and has at least 24 hours duration (mostly applicable to OA)
  • A proposal which contains a security vulnerability, verified by any third party such as audit firms, security researcher, or community members. Such vulnerabilities should not be disclosed by Fei Core developers in order to prevent conflict of interest.

……………………

The voting choices will be:

  1. In favor
  2. Oppose

If successfully passed on snapshot, these guidelines would be pinned on the discourse forum and written into the snapshot website for Fei, as a supplementary document for the original FIP guidelines. They would serve as official guidelines for the governance process.

Proposals that blatantly disregards these guidelines should be rapidly informed as such by community members. If the authors do not respond to these valid inquiries of procedure, the proposal will be publicly announced as “procedurally in arrears”, and upon community discussion, might be subject to sanctions such as non execution by OA approval, or veto by guardian.

#10

overall looks good, will support :+1:

again for 5 I wonder if snapshots failing due do a commonly agreed upon desired correction/amendment should have to go through 48H of last call again. perhaps those types of situations deserve an exception

it’s ok for vuln’s to be disclosed by core devs, what should be required is external validation by credible non-core devs

#11

I agree with storm! Looks good but lets shorten last call to 24h and allow for some parallelization e.g. it can be announced during a currently failing snapshot.

#12

I stuck with 48, because the current document Fei Improvement Proposals (FIPs) - Fei Protocol, explicitly called for at least 2 days. We’d have to amend that document as well, if we want to move for 24 hours instead.

@storm, I’ll refine the language of the final clause to reflect that.

#13

24H seems a little short, but how about this to make up for it: when last call is called, it sets off a 24H countdown. and then every further change during the last call period resets the 24H timer? so things have to be set in stone for 24H to start

#14

Perhaps and all snapshots should have a “more discussions” option

#15

I dont like that very much because multiple choices can significantly complicate votes

sometimes it’s justified but not always

#16

this countdown reset idea is very interesting, and imo probably closest approximation of parliamentary procedures. My only concern is it might be too difficult for most users to track accurately.

I feel adding an sentence along these lines would be sufficient: “if the proposal is significantly amended during last call, the author should respect the flow of the discussion and delay snapshot accordingly.”

1 Like
#17

I want to make sure that this is loud and clear in whatever processes we put in place. I think we can soften the language and be pretty clear that these are social guidelines not an absolute rule.

For example even if the guidelines say 48h last call, a sufficiently non-controversial proposal can do around 24h with no scrutiny. I think a balance of process and flexibility is key here.

Other than this last point, I’m in 100% favor and very glad to see @cozeno step up to steward strong governance practices for Tribe

#18

A few things:

These draft measures, if approved, are meant to serve as “official governance guidelines”

If this is the case, what’s the point of making this a FIP? I suppose it’s useful as “officially adopted guidelines by the Fei-DAO”, but if it’s not binding, and if the practices aren’t mandatory, I question why this should be a FIP (and not just social enforcement)

Additionally, this proposal makes mention of the forum and the Discord, and how posting should be done. IMO this isn’t very in the spirit of decentralization - the forum and the Discord are both controlled by Fei Labs. I think generalizing this to be more about expectations about communication timelines (wherever this communication may occur) would be a better and more forward-looking way to go about this.

1 Like
#19

While, on the one hand, I agree with Joey that Fei is still in its nascent stages, and we shouldn’t be handcuffed to some set of governance procedures in the way the US senate might be. On the other hand, I agree with Caleb in spirit that there should be some measures of enforcement. I felt in particular that the FEI-Rari merge governance process was somewhat less than ideal, and I proposed these measures particularly to prevent a reoccurrence.

Personally I believe that the enforcement clauses (ie, non execution by the OA, admin takedown), should remain, and potentially should be used. But enforcement should not be absolute, and the great majority of “non-compliance” due to simple oversight should just be allowed to slide.

#20

the Snapshot has passed
https://snapshot.fei.money/#/proposal/0x554de2c36f5d42f99e7fd5d6444f41553aeb782cad7a0195d7ff0c010e6ae855

making one minor amendment per discussions in discord:
replacing “A failed FIP should go through the entire process of a new FIP, including another last call, etc.” in clause 5 with:

“if the edited points required of the failed FIP does not exceed a majority of the original proposals, then the FIP may keep its original FIP number, add “FIP-xx amendment 1” to its title, and may proceed directly to last call. Though if the edits required as so substantial that a majority of the original proposals have been changed, the FIP number would be scrapped and it should restart from scratch on the forum.”

Seeing that this FIP requires no on-chain execution, a version of these proposals will be pinned to this forum, and later be referenced in the Snapshot website

#21

per recommendations from Joey, the final language of the proposal has been tightened up and had some of its draft deliberativeness taken out of it. It is meant to read less as a legislative draft, but more as technical parameters in style. Here are the final edits, no points of substance have been changed:

#########################

Fei Improvement Proposals (FIPs) - Fei Protocol are the currently standing rules of FEI governance, With the passing of FIP-57, the following guidelines will compliment the above document:

  1. 48 hour last call before snapshot. The last call should be announced in the discord governance channel for publicity; enlisting the aid of a mod if need be.

a. A notable exception would be technical rollouts, or routine contract upgrades such as FIP-48

  1. During the “Last Call”, each FIP should clearly state what every voting option would be. The last call post should also indicate any edits which have been made from the original due to the discussions in the forum. If the proposal is significantly amended during last call, the author should respect the flow of the discussion and delay the snapshot accordingly.

  2. Only the author(s) of the original forum discussion post should make the snapshot for that particular motion, or allow somebody else to do so with explicit written permission in that original thread.

  3. Upon the passing of a snapshot vote, the poster should announce the specific time they intend to forward the proposal for on-chain voting/Optimistic Approval. If a particular snapshot is a “temperature check” and not meant to be executed directly, it should be clearly indicated by its authors.

a. Routine protocol upgrades can be exempt from these requirements.

  1. If a proposal outright fails, the author should indicate whether they intend to repost the FIP after editing its contents with community input. If the edited points required of the failed FIP does not exceed a majority of the original proposals, then the FIP may keep its original FIP number, add “FIP-xx amendment 1” to its title, and may proceed directly to last call. Though if the edits required were so substantial that a majority of the original proposals have been changed, the FIP number would be scrapped and it should restart from scratch on the forum.
  2. If a proposal passes, the authors should indicate if they like to make non-substantive edits as soon as possible, and outline every edit from the proposal that has passed the snapshot.
  3. The DAO guardian will veto votes if they satisfy any of the following criteria:
  • The proposer or payload is unknown.
  • Proposal which distributes PCV or incentives to voters on the basis of their vote (bribery proposals)
  • Proposals which add admin control to untrusted accounts
  • Any veto authorized by a TRIBE snapshot that reaches quorum and has at least 24 hours duration (mostly applicable to OA)
  • A proposal which contains a security vulnerability, either disclosed by core team or community member, and verified by any third party such as audit firms, security researcher, or community members.

Proposals that blatantly disregards these guidelines should be rapidly informed as such by community members. If the authors do not respond to valid inquiries of procedure, and outright circumvents governance practices, the proposal could be subject to sanctions such as non execution by OA approval, or veto by guardian/DAO.

2 Likes