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.
Rules and Values
- Code of Conduct and Rules of Engagement
- Governance Processes
- Changes to Governance
There are three named roles in Gitcoin governance: stewards, delegators, and contributors.
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 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 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.
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.
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.
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.
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.
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.
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 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 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.
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
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.
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:
- Funding proposals : A workstream requests funding from the Gitcoin DAO treasury.
- 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.
- 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.
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.
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.
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.
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.
There are multiple edge cases outlined below that you can explore.
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
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.
Any changes to the Gitcoin Governance Process must be ratified by the community in an off-chain vote at a minimum.
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.