Previous versions and discussions:
This document, written by @Pop and @ceresstation is a suggested process for developing and advancing Gitcoin Community dynamics, governance flows and everything that comes with it. 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 kickstart discussion around the different roles, flows and pathways so that we may ensure the effective and smooth operation of everything we do in this community. We’ll move this over to get ratified after discussions are complete
*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.
- Governance Roles
- Rules and Values
- Code of Conduct and Rules of Engagement
1. Proposal approval
2. Moving to vote
3. Edge cases
4. Conflicting votes
- Changes to Governance
There are three main roles in Gitcoin governance: stewards, delegates, 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 heading workstreams.
Becoming a steward : Getting involved in 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.
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 the Steward Dashboard here. From there, they can choose from the current list of stewards. 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.
Contributing to a workstream : Workstreams that have been ratified, as defined below, each have their own requirements and processes. Community members who want to contribute to a workstream should read that workstream’s guide to contributing. Most workstreams will be looking for new contributors on a regular basis. Community members who make valuable contributions will be rewarded in GTC.
Gitcoin’s mission is to build and fund digital public goods. Our work toward this mission is a positive-sum multiplayer game. It requires that we internalize and act upon shared values and common knowledge while respecting and learning from our differences. It requires that we treat each other respectfully as peers. Gitcoin draws its strength from highly 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, 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.
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).
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.
- 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 would like to become a moderator, please reach out to myself, Scott on Discord.
If you see something in the Gitcoin community that violates these rules, speak to a moderator. All complaints to moderators are confidential.
The processes described below are how the Gitcoin community proposes, discusses, and decides on initiatives that will be taken on by GitcoinDAO in its mission to sustain digital public goods.
All 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.
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, 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 and collaboration on specific areas of work.
Workstreams are the atomic units of how stewards coordinate. A workstream is a group of people actively working on tasks that align with Gitcoin’s mission to sustain digital public goods. As such, ratifying workstreams sets boundaries on what is and isn’t in scope for GitcoinDAO 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 mission.
- Name a steward who is directly responsible and willing to take ownership of the objective and accountability for meeting it.
- Distinguish itself from or explicitly state its improvements on existing workstreams.
- Propose clear budgets and timelines for producing outcomes.
Workstreams have five potential states:
Table 1: Workstream States
|Informal||Workstream has not made a proposal.|
|Proposal Stage||Workstream has made formal proposal to governance for budget.|
|Active||Workstream budget and target has been ratified by governance.|
|Renewed||Workstream has been renewed or is receiving continuous funding.|
|Archived||Workstream is concluded, defunded, deprecated, no longer active.|
To move into a subsequent level of formality, a workstream must satisfy the criteria in Table 2: Required Information:
Table 2: Required Information
|Workstream Stage||Required Information|
|Proposal Stage||Must be posted on the forum when the proposal is made.|
|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?|
|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||Must be posted on the forum.|
|Weekly Report||What has been accomplished this week?|
|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?|
|Archival||Must be answered by workstream or governance when considering archiving a workstream.|
|Performance on Mandate||Has the workstream achieved its mandate?|
|Necessity of Workstream||Is there more work to be done under this specific mandate?|
|Eligible Leadership||Is there a steward willing and able to take responsibility for 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.
Sybil Defenders: Analyzing Gitcoin data and brainstorming long-term identity and mechanism design solutions for Sybil-Resistance.
Progressive Decentralization: Finding ways to modularize and simplify Gitcoin’s architecture for the community to use in perpetuity.
Public Goods Prototyping: Finding ways to use Gitcoin’s new architecture to build novel solutions to ecosystem problems.
Workstreams are not funded by default. A workstream that desires funding must apply for that funding by making a proposal.
Proposals to the GitcoinDAO are requesting funding from the GitcoinDAO treasury, denominated in GTC.
Workstreams can define their own structure for paying contributors and leads. 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 GitcoinDAO.
It is recommended that workstreams pursue funding from the DAO treasury, and that projects find ways to interact with workstreams directly, treating other funding sources as supplemental, reactive funding from the community.
The Gitcoin community makes decisions by voting on proposals made by workstreams. 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 four categories:
- Funding proposals : A workstream requests funding from the GitcoinDAO treasury.
- Ratification proposals: The community or a workstream asks the community to approve something it wants to do, like issuing Gitcoin Grants.
- Governance proposals: The community is asked to ratify proposed changes to policy or procedures, like updating the Gitcoin Governance Process document.
- DAO proposals: 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 Proposal Discussion section of 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.
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, a formal vote can take place.
There are two kinds of votes possible, depending on the subject matter of the vote:
Off-chain voting or “soft voting” takes place on Snapshot. Votes on Snapshot are weighted by the number of GTC delegated to the address used to vote.
On-chain voting or “hard voting” is required in addition to Snapshot voting for proposals that would move GTC from the DAO or make other key changes to the structure of the DAO. Gitcoin will be using Tally to upload on-chain proposals.
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 technically structural changes to the DAO.
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.
To reduce duplicate voting, an off-chain vote on a proposal that did not reach quorum will be deemed to have reached quorum if the difference between the number of votes cast and the quorum is less than the number of votes that would be required to change the result of the vote.
Soft quorum does not apply to on-chain votes.
Example of soft quorum:
A proposal receives the following votes:
- Option A: 1,500,000 votes.
- Option B: 499,999 votes.
Additional votes needed for quorum = 500,001
Additional votes needed to change result = 1,000,002
The vote is 500,001 votes short of reaching quorum, but even if all 500,001 of those votes were assigned to Option B, Option A would still be the clear winner. We assign Option B with those shadow votes and deem Option A to be the winner.
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.
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) the 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.
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.
Airdrops may come, but you are not entitled to an Airdrop.
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.
This version of the Gitcoin Governance Process is a living document. If you have comments, please provide them as soon as possible. Once this document is ratified, this section will be removed and any changes will need to go through a Snapshot vote following the process described above.