Gitcoin DAO Governance Process v3

Previous versions and discussions:

This document, written by @Pop, @kweiss and @ceresstation is the ratified process for developing, advancing and governing Gitcoin. It is a living document intended to be owned, modified, and enforced by stewards as well as the overall community.

The post is intended to anchor and showcase the different roles, flows and pathways that ensure the effective and smooth operation of everything we do in this community.

*Please note that if you have support questions, our Discord here is the place to ask, comments not related to the proposal in this thread will be removed.

Join the Gitcoin Discord Server!

Gitcoin Governance Process

Contents

  1. Governance Roles
    1. Stewards
    2. Delegators
    3. Contributors
  2. Rules and Values
    1. Code of Conduct and Rules of Engagement
    2. Values
    3. Enforcement
  3. Governance Processes
    1. Discussions
    2. Proposals
    3. Workstreams
    4. CSDO
    5. Funding
    6. Voting
      1. Proposal Discussion
      2. Moving to vote
      3. Quorum
      4. Gitcoin's Gov Alpha Details
      5. Edge Cases
  4. Changes to Governance
  5. Airdrops

Governance Roles

There are three named roles in Gitcoin governance: stewards, delegators, and contributors.

Stewards

Stewards

Stewards are community members who have volunteered to serve the community by exercising voting power that has been delegated to them and by leading workstreams.

Becoming a steward: Getting involved as a steward is easy. Anyone who wants to be considered to become a steward may state their intent here and express why they think they’d be a good fit to build and govern for the public good. Any community member may put themselves forward as a steward, but it is up to their fellow community members to determine if they want to delegate voting power to a particular steward. A new and improved steward flow is in the works and will involve better and more granular touch points on what being a steward is all about.

Stewards meet monthly to discuss, review and offer feedback on Workstream progress and DAO wide initiatives. There is also a steward council that serves twice a year. The council is made up of the most engaged steward in the DAO based on engagement metrics captured by the steward cards. The steward council also benefits from a steward council allocation for the term to be disbursed as additional voting rights among its members for their support.

Delegators

Delegators

Delegators are community members who hold GTC but want to rely on a steward to exercise their voting power for them by delegating their voting power to that steward.

Delegating your voting power: Anyone who owns GTC can delegate their voting power to a steward by visiting Tally. The current list of stewards and their activity level can be found here. Delegation helps ensure that the community’s thoughts and views are represented in votes. Delegations can be changed or revoked at any time.

Contributors

Contributors

Contributors are community members who dedicate their time, talent, and expertise to a workstream, helping it achieve its goals and its support of the purpose of Gitcoin DAO.

Contributing to a workstream: Workstreams that have been ratified, as defined below, will have their own requirements and processes. Community members who want to contribute to a workstream should read that workstream’s guide to contributing and interact with its contributors and leads. Most workstreams will be looking for new contributors on a regular basis. Community members who make valuable contributions will be awarded GTC.

Rules and Values

Code of Conduct and Rules of Engagement

The Gitcoin community has adopted a Code of Conduct that must be followed by all participants in the community and Rules of Engagement that set standards for participation on the forums.

Gitcoin’s purpose is to empower communities to build & fund their shared needs. Gitcoin draws its strength from its community of engaged participants, whether they are contributors, delegators, or stewards.

Values

The Gitcoin Governance Process is firmly committed to both the Code of Conduct and Rules of Engagement. In addition to these documents, the Gitcoin Governance Process is based on the following values:

  • Valuing the participation of every member of the community.
  • Offering a meaningful and fulfilling experience to participants.
  • Welcoming all opinions and perspectives.
  • Encouraging meaningful discussions.
  • Fostering a culture of collaboration and support.
  • Building new cooperative models.
The Gitcoin Governance Process puts these values into practice through:
  • Respect and courtesy: All community members must show respect and courtesy to other community members.
    • We are an inclusive community.
    • Respect the privacy of community members.
    • Extend respect and courtesy to people who might be community members, not just current community members.
  • Discussing topics, not each other: Discussions can get heated, but when we disagree, we disagree on topics, not on people.
    • Accept differences in opinions.
    • Do not attack people personally.
    • Discussions should be additive & productive, not reductive.
    • Respect redundancy as a new path to solving the same problem.
  • Building together: Building public goods and compassionate technology requires openness and honesty, not gatekeeping.
    • Work together in a spirit of collaboration and co-creation.
    • Make efforts to bring newcomers into discussions or workstreams.
    • Accept others’ differences.
    • Acknowledge our own flaws.
    • Collaborate without coercion or force.
  • Building transparently and for the public good: Public goods should be built in a way that is visible and accessible to the public to the greatest extent possible.
    • Work in public to the greatest extent possible.
    • Release code under open source licenses
    • License work using the most permissive licenses possible.
    • Provide regular updates on workstream milestones and abide by accountability flows.
  • Accepting accountability: If you agree to serve as a steward, lead a workstream, push forward a proposal, or make a contribution, you are responsible for following through. Accountability is critical to Gitcoin’s mission.
    • Be timely in delivering work, making contributions, and meeting goals.
    • Expect to be held accountable for what you deliver (or do not deliver).
    • REMEMBER DAOS ARE MADE OF HUMANS.

Enforcement

Everyone in the Gitcoin community must abide by the Code of Conduct and Rules of Engagement. Gitcoin has zero tolerance for:

  • Hate speech.
  • Personal attacks or threats (online and IRL).
  • Aggressive tone, threatening language or imagery.
  • Sharing illegal or explicit material.
  • Spam.

The Code of Conduct and Rules of Engagement apply to all community members and are enforced by stewards who have chosen to take on moderator duties.

If you see something in the Gitcoin community that violates these rules, flag the post. All flags are confidential.

Governance Processes

The processes described below are how the Gitcoin community proposes, discusses, and decides on initiatives that will be taken on by the Gitcoin DAO in its mission to sustain digital public goods.

Discussions

Most governance discussions must take place on the official Gitcoin forums. This is to ensure the community has all the information it needs to make an informed decision about proposals, and to provide transparency into what was decided, what was done, and why. Certain discussions, which are often cross stream governance discussions, would also take place in CSDO

Proposals

Proposals can vary broadly in their stated goals and requests.

  • They may ask the community to endorse a specific policy and procedure (e.g. “Should Gitcoin Grants allow VC backed projects?”), or ask the community to build something (e.g. “Building a new software tool” or “Writing improved documentation”).
  • They may have no funding requests attached (e.g. “Should we adopt a new Foundation for the DAO”), or make an explicit request for funding (e.g. “We would like to create a workstream focused on building a decentralized architecture for Gitcoin Grants”).

Workstreams

Workstreams provide a place for discussion, collaboration and advancement of specific areas of work.

Workstreams are the atomic units of how Gitcoin advances its purpose. A workstream is a group of people actively working on tasks that align with Gitcoin’s purpose and essential intents. As such, ratifying workstreams sets boundaries on what is and isn’t in scope for Gitcoin DAO’s governance.

Anyone may start a workstream and gather momentum behind it by posting on the forum. Until a formal proposal for a budget is made, this workstream is considered “informal.” A workstream can be as broad or narrow as its initiators like, but workstream proposals must satisfy the following criteria or risk being removed by mods:

  • Have a clear objective that aligns with Gitcoin’s purpose.
  • Distinguish itself from or explicitly state its improvements on existing workstreams.
  • Propose clear budgets and timelines for producing outcomes and all in line with the budget proposal flow.

Workstreams have five potential states. Each of the five states and the requirements for a workstream in each state are outlined below:

Informal - Workstream has not made a proposal:
Initial Proposal Must be posted on the forum when the initial proposal is made.
Team Who is proposing this project? What are their qualifications?
Mandate What is the mandate of this Workstream? What will it try to accomplish? Does it have an initial goal?
Proposal Stage - Workstream has made formal proposal to governance for budget:
Funding Proposal Must be posted on the forum and linked in the Snapshot proposal when a funding proposal is made.
Vision How does this project advance Gitcoin’s goals or align with its values?
Initial Target What will be delivered by the workstream using this funding?
Budget What amount is required for the workstream to achieve the initial target, and how will it be spent?
Milestones What are the key milestones for the initial target?
Timeline What is the timeline for completing the initial target?
Steward Responsible Who is the steward managing the project and accountable for its outcomes?
Official Team Who is committed to working on this project and what are their responsibilities?
Active - Workstream budget and target has been ratified by governance:
Workstream Updates Must be posted on the forum.
Midpoint Report What has been accomplished during this season thus far (halfway check in point)?
Renewed - Workstream has been renewed or is receiving continuous funding.:
Renewal Proposal Must be posted on the forum before a request for renewed funding is made.
Initial Funding Assessment Was the initial target met? Was the project completed? Was it completed on time? Did it meet expectations? If the workstream failed to deliver on something, why, and what will be done to avoid those problems with the renewed funding?
Renewal Targets What will be delivered by the workstream using this funding?
Renewal Budget requirements What amount is required for the workstream to achieve its new target, and how will it be spent?
Steward Responsible Who is the steward managing the project and accountable for its outcomes?
Team Updates Are there any changes to the team working on this project?
Archived - Workstream has been sunsetted.:
Archival Must be answered by workstream or governance when considering archiving a workstream.
Performance on Mandate Has the workstream achieved its mandate, failed in achieving mandate or no longer able to achieve mandate for various reasons?
Necessity of Workstream Is there more work to be completed under the initial mandate? Can another workstream take said work over or will the work not be completed if any outstanding?
Eligible Leadership Is there a steward willing and able to take responsibility for spinning down this workstream?

Examples of Workstreams:

Public Goods Funding: Helping rally the community to fund public goods, setting criteria for matching rounds, and finding ways to get Gitcoin involved in funding new digital public goods.

Fraud Defense and Detection: Defend Gitcoin (Grants & DAO) from threats to its legitimacy, credible neutrality, and sustainability.

Memes, Merch and Marketing: Using merch, memes and marketing MMM creates public goods, new projects, fun stuff that generates curiosity and hype around public goods, Gitcoin, open source software.

If you have ideas for a new workstream, please suggest a workstream on the forums.

Cross Stream DAO Ops (CSDO)

Cross Stream DAO Ops has formed as the day-to-day governing team of the Gitcoin DAO. This group is composed of two members from each workstream, with Gitcoin Holdings and the Gitcoin Foundation also given two “seats at the table.”

The goal of this group is to discuss, review and ratify DAO wide initiatives and goals while ultimately building a base layer of coordination amongst the workstreams in a consent based manner. This group meets weekly and ensures DAO wide decisions are made with representation from each workstream. Examples of past ratification include:

  • Normalizing budgeting cadence (seasonal budget reviews)
  • DAO-wide Travel Support Policy
  • Gitcoin DAO Purpose and Essential Intent draft

Funding

Workstreams are not funded by default. A workstream that desires funding must apply for that funding by making a proposal during an appropriate season or call for budget proposals.

The flow for budget proposals is being updated based on steward and workstream leads feedback

Proposals to the Gitcoin DAO are made to request funding from the Gitcoin DAO treasury, and the requests should be denominated in GTC with a conversion to USD presented in the proposal at the time of posting. A template for how to structure those requests can be found here. Here are also a few examples of past successful budget proposals:

Workstreams can define their own structure for paying contributors and leads, though we do have DAO-wide suggestions available. Workstreams are encouraged to set out a payment structure before work begins, clearly setting out who gets paid, how much, for what work, and how disputes are settled.

Workstreams can seek other sources of funding, including Gitcoin Grants, whether or not they have been funded by the Gitcoin DAO.

Once a workstream has been funded, it is eligible to participate in Cross Stream DAO Operations (CSDO). More details are available above on CSDO.

Voting

The Gitcoin community makes decisions by voting on proposals. Anyone who holds GTC is able to cast their vote themselves or delegate their voting power to a steward.

Typically, proposals will fall into one of three categories:

  1. Funding proposals : A workstream requests funding from the Gitcoin DAO treasury.
  2. Ratification proposals: The community or a workstream asks the community to approve something it wants to do, like issuing matching funds to Gitcoin Grantees at the end of a Grants round.
  3. Governance proposals: The community is asked to ratify proposed changes to policy or procedures, like updating the Gitcoin Governance Process document, adopting the Foundation, etc. or the community is asked to vote on structural changes to how the DAO operates.

Proposal Discussion

Before a proposal can go to a vote, it must be posted in the appropriate category on the forum for review and comment by the community.

Proposals brought to the forum must be in the format required by the Gitcoin Community Proposal (GCP) template and address the considerations set out in Table 2: Required Information, above.

Once it has been posted in the forum, a proposal must:

  • Be available for review and comment for at least 5 days, and
  • Receive input from at least 5 stewards not connected to or working with the proposal/with workstream (any stewards part of the proposal should also be disclosed).

A proposal that does not meet the requirements for formatting, required information, length of review, or input from stewards will be removed from Snapshot voting if an attempt is made to hold a vote.

Moving to Vote

Once a proposal has completed Proposal Discussion (outlined above), a formal vote can take place.

There are two kinds of votes, off-chain and on-chain:

  • Off-chain voting takes place on Snapshot and is required before any vote can be moved to an on-chain vote (if necessary). The vote period is 5 days. Use this template for reference
  • On-chain voting is required in addition to Snapshot voting for proposals that would move GTC from the DAO treasury or make other key changes to the structure of the DAO. Gitcoin will be using Tally to upload on-chain proposals. The vote period is 5 days. Use this template for reference.

No one person should ever vote NO on Tally as all proposals that make it on Tally are classed as passed. This minimizes gas costs and fulfills the goals of Snapshot. In the event that one person votes NO, then all stewards should be rallied to push the vote through as per Snapshot decision.

In both off-chain and on-chain votes, voting power is directly proportional to the amount of GTC a user holds or has delegated to them.

IMPORTANT : Snapshot will be used for final decision making on any proposal that does not require moving funds from the treasury or involves technical (ie. smart contract) changes to the DAO.

IMPORTANT: Once a proposal has evolved to a Snapshot vote, said proposal should no longer be edited. If any significant edits are made to a proposal (i.e. removing more than a typo) once the voting on Snapshot has started, community members or stewards can demand the vote to be removed and to be started over. If an edit is made after a proposal is passed (or is discovered at a later point), the Snapshot vote will only cover what has been stipulated in the original proposal at the time the Snapshot vote was launched.

Quorum

In order for a proposal to succeed, a minimum of 2.5 million GTC must participate in the vote. Any changes to quorum requirements must be ratified by the community. Each vote DOES require a quorum or the vote is not considered valid. It is the proposal creator’s responsibility to ensure they are soliciting votes from the community and reach quorum.

Gitcoin’s Gov Alpha Details

GTC governance is a fork of the COMP/UNI governance systems. It uses Governor Alpha and Timelock. A helpful Dune Analytics dashboard can be found here.

Gitcoin: Governor Alpha contract address | Gitcoin: GTC Timelock contract address

Governor Alpha is the governance module of the protocol; it allows addresses with more than 1,000,000 GTC ( proposal threshold ) to propose changes to the protocol. Addresses that held voting weight, at the start of the proposal invoked through the getpriorvotes function, can submit their votes during a 40320 Ethereum blocks voting period . If a majority, and at least 2,500,000 votes ( quorum votes ) are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.

Timelock extensions add a delay for governance decisions to be executed. The workflow is extended to require a queue step before execution. With these modules, proposals are executed by the external timelock contract, thus it is the timelock that has to hold the assets that are being governed.

Queue After a proposal has succeeded, any Ethereum address can call the queue method to move the proposal into the Timelock queue. A proposal can only be queued if it has succeeded. The waiting period begins when this function is called => 172800 seconds (2 days).

Execute After the Timelock delay period, any Ethereum address may invoke the execute method to apply the changes from the proposal to the target contracts. This will invoke each of the actions described in the proposal. The function is payable so the Timelock contract can invoke payable functions that were selected in the proposal.

The minimum time to vote, pass, and execute a proposal is 10 days and 8 hours approx.

Edge cases

There are multiple edge cases outlined below that you can explore.

Conflicting Proposals

Conflicting Proposals

Conflicting proposals are proposals that are active at the same time and address the same issue.

In the case of a conflicting proposal, the 5-day proposal discussion period can also serve as a time for community members to provide their preferred alternative. Conflicting proposals will all be marked with a [TOPIC] block in its title on the forum.

After the proposal discussion period has expired, a vote will be put forward that includes all the possible options from the conflicting proposals.

Conflicts of Interest

Conflicts of Interest

In any case where a steward or community member votes on a proposal that directly benefits themselves (e.g. voting to pass their own workstream budget) that steward or community member’s vote will be considered invalid by default. Any steward may raise a claim of conflict to be addressed prior to a vote being finalized on Tally should this apply.

If a conflict is found, any related vote must be redone and may be considered passed so long as the steward in conflict abstains and the quorum rules are met.

Changes to Gitcoin Governance

Any changes to the Gitcoin Governance Process must be ratified by the community in an off-chain vote at a minimum.

Airdrops

Over the course of time, Gitcoin Grants has become a significant pillar of the ecosystem - in which more & more projects are reliant for support.

Because Gitcoin Grants has had 1mm+ lifetime crowdfund contributions, it has become a source of data about which projects the community values, and who in the ecosystem is supporting these projects.

Any Airdrops that come to Gitcoin contributors have been on a “don’t expect it, but be thankful if it comes” social norm.

We expect that community contributors are informed about, and participating in, the process through which governance passes proposals. We expect that community members are graceful in accepting airdrops, but are not acting entitled to them unless a governance proposal passes that specifically entitles them to an airdrop at a specific time.

Any disrespectful, harassing, entitled, or trolling behaviour related to airdrops is against this code of conduct.

15 Likes

Great to see an update of this document.

A couple of things that stands out to me:

  • I still think we should redefine the “Receive input from at least 5 stewards”-requirement. A small edit to something like “Receive input from at least 5 stewards not connected to the proposal” would be a great start.

  • I feel like using the terminology “soft vote” and “hard vote” for Snapshot and Tally is quite misleading. If things haven’t changed from earlier version of this document governance is happening on Snaphot, exclusively. Anything that reaches Tally has already been discussed, proposed and ratified by the Stewards and should therefore always pass.

  • Is the concept of “soft quorum” no longer being used?
    This document states that “Any change to the quorum requirements must be ratified by the community” which AFAIK hasn’t happened.

  • MMM created this dashboard recently with information of our Gov Alpha set up. Part of it could be added to this document for (much needed) clarity regarding how on-chain proposals on Tally actually works. See excerpt below:

"GitcoinDAO Gov Alpha details*

GTC governance is a fork of the COMP/UNI governance systems. It uses Governor Alpha and Timelock.

Gitcoin: Governor Alpha contract address | Gitcoin: GTC Timelock contract address

Governor Alpha is the governance module of the protocol; it allows addresses with more than 1,000,000 GTC ( proposal threshold ) to propose changes to the protocol. Addresses that held voting weight, at the start of the proposal invoked through the getpriorvotes function, can submit their votes during a 40320 Ethereum blocks voting period . If a majority, and at least 2,500,000 votes ( quorum votes ) are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.

Timelock extensions add a delay for governance decisions to be executed. The workflow is extended to require a queue step before execution. With these modules, proposals are executed by the external timelock contract, thus it is the timelock that has to hold the assets that are being governed.

Queue After a proposal has succeeded, any Ethereum address can call the queue method to move the proposal into the Timelock queue. A proposal can only be queued if it has succeeded. The waiting period begins when this function is called => 172800 seconds (2 days).

Execute After the Timelock delay period, any Ethereum address may invoke the execute method to apply the changes from the proposal to the target contracts. This will invoke each of the actions described in the proposal. The function is payable so the Timelock contract can invoke payable functions that were selected in the proposal.

The minimum time to vote, pass, and execute a proposal is 10 days and 8 hours approx.

5 Likes

I did remove this given the amount of GTC being delegated is much higher now. We should def discuss if there are concerns.

One thought is that this v3 will be “ratified” as part of the asset transfer and other things, so we can vote to make changes and adopt it then (if we feel so inclined).

3 Likes

Agree with this from Fred. Add more requirements:

Disclose who (stewards) are involved in this proposal.

4 Likes

I think we typically see a pattern of naming people involved but being able to easily discern who is commenting and who is involved might make it even more transparent

Going to bump this thread up given that we have had lots of revisions and would love more commentary from others.

2 Likes

I propose we remove “made by workstreams” from this sentence as that is not a requirement.

2 Likes

Edit made on this, @Fred - it indeed can involve proposals made by many other sources

2 Likes

This is a great item to have. Last time the dates for deliberation were extended without a forum post and it was very difficult for me to explain to contributors what was happening.

Mandate: “Defend Gitcoin (Grants & DAO) from threats to its legitimacy, credible neutrality, and sustainability.”

1 Like

Would be good to add the time for voting here

3 Likes

So a few additional comments while (finally) reading through this:

So afaik this governance process is not ratified, not this version and not previous versions when I check snapshot or CSDO notes. I hope however that the comments below by me and others will be integrated and that a v3 can be officially ratified.
To make this easy we could split this up in parts if needed and ratify these parts (in csdo or by stewards)
Could we put some next steps & a deadline on this?

*meet monthly

Other point on stewards - could we write out more on what the steps are to actually become an active steward? this should prob be a post/proposal in and by itself

I fear that this is now outdated and that we should reference our Purpose & Intents.

Same for this

This is not the case for CSDO discussions, which are often governance discussions, so maybe we should add this and link to CSDO?

Link to purpose & intents instead?

We have not been doing this afaik, wouldn’t know who that steward is for daoops or other workstreams so maybe we can take this out?

The difference between is a bit unclear to me, I also don’t think we have used these, maybe they can be merged?

I would change this to ‘into the appropriate category’, as we will have a budget proposal, partners and grants category . Proposals will fall in one of these categories, depending on what it is.

It would be good to specify a little bit more on what is expected for tally. I eg do not vote on Tally if the threshold is already passed (no gas waste) but some people vote no on tally bcs they voted no on snapshot. Tally should just be about passing the budgets that are approved so such a scenario makes no sense. Eg a whale no voter could make a tally proposal fail that passed on snapshot.

(cc @ceresstation )

Hope we can effectively do this for this version, or an updated one that includes comments.

Strong agree on both points.

Thanks for all your work on this @Pop @ceresstation & @kyle !
Hope this feedback is useful.

3 Likes

As we can see, the process is always evolving and I do not feel this is a bad thing - it should not be static. I think we either edit this or we indeed issue a v4 seeing as so many things have changed - Purpose and EI, categories on forum as these have literally emerged in the last week.

2 Likes

This version is now updates to include Purpose and Essential Intents of the DAO, edits, clarifications, further detail as per comments there by @Fred @krrisis @bobjiang @DisruptionJoe and should be ready for ratification.

Thank you all for your input.

3 Likes

I think it needs to be explicit and clear that there is nothing wrong with working on a proposal in private before starting the public conversation. Every conversation would be too much to keep up with, but a well thought out proposal would be good.

Also strongly agree.

1 Like

already included in amended see above

1 Like

I am going to lock this thread given there is a vote to ratify. We do not want this change once it is being voted on and/or approved.

1 Like