# Gitcoin DAO Governance Process v2 - updated

[Pop]

Previous versions and discussions:

• v0 here.
• v1 here.
• v2 visual overviews here.

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.

Join the Gitcoin Discord Server!

Gitcoin Governance Process

Contents

1. Governance Roles
2. Stewards
3. Delegators
4. Contributors
5. Rules and Values
6. Code of Conduct and Rules of Engagement
7. Values
8. Enforcement
9. Processes
10. Discussions
11. Proposals
12. Workstreams
13. Funding
14. Voting
    1. Proposal approval
    2. Moving to vote
    3. Edge cases
    4. Conflicting votes
15. Changes to Governance
16. Airdrops

Governance Roles

There are three main roles in Gitcoin governance: stewards, delegates, and contributors.

Stewards

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

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

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.

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 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.

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, 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).

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.
• 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 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.

Governance Processes

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.

Discussions

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

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

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

State	Detail
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.

If you have ideas for a new workstream, please suggest a workstream, or just dive straight into discussions.

Funding

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.

Voting

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:

1. Funding proposals : A workstream requests funding from the GitcoinDAO treasury.
2. Ratification proposals: The community or a workstream asks the community to approve something it wants to do, like issuing Gitcoin Grants.
3. Governance proposals: The community is asked to ratify proposed changes to policy or procedures, like updating the Gitcoin Governance Process document.
4. DAO proposals: 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 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.

Moving to 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.

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.

Soft Quorum

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

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) 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.

Changes to Gitcoin Governance

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

Airdrops

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.

Pre-Ratification Feedback

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.

[phutchins]

This is a fantastic start on covering many of the important topics when spinning up a workstream.

I would like to discuss how the initiator or creator of a workstream should propose compensation for themselves. It would be great to hear thoughts on how that could work and we could create examples to bring it to life.

To start the discussion, here is a possible approach and some problems…

Static Pay (mocks how it would work in a normal employment situation)

• Lead proposing the workstream composes a budget
• Budget includes proposed monthly/bi-weekly/weekly pay at a certain rate in USD
• Depending on prior experience applicability:
  • Prior experience directly applies: Lead includes resume and pay range data for applicable skillsets
  • Prior experience partially applies: ?
  • Prior experience does not apply: ?
• After establishing a track record delivering on the goals of the workstream in a timely manner and responsibly managing funds, the lead could propose an increase in pay
  • This could be done by the lead iniating a review of some sort by the DAO resulting in a scale that diretly relates to a realignment of compensation
  • It might be such that certain members of the workstream and DAO could initiate this process as well if they want to recognize great performance or identify lacking performance

In the case that a leads prior experience only partially applies or does not apply, there might have to be a probationary period or have pay locked pending frequent reviews over time. As time progresses, those reviews could become less frequent and finally cease.

I would love to hear thoughts on this approach then we could create an example with numbers, dates, etc. around it to better illustrate how it would work.

[JTraversa]

@Pop

Conflicting Votes

From time to time there may be conflicting proposals, to avoid issues, the 5 day window above can also serve as time for anyone to list their preferred alternative option on the forum. Each proposal on an associate topic will have a [TOPIC] block placed in its title.

After that time, a vote will be put forward including all options available to move forward with. This will ensure that everyone has the ability to surface their preferences while keeping decision timelines reasonably short,

So I’d like to take some time clarifying this. Based on mentioning the 5 day window, the implication here is that the conflicting proposals would be present at the same time on the forum, and if that is the case this makes a lot of sense.

However, what about in the case of two proposals that have both managed to get to snapshot, asynchronously. An example being the recent AKITA debacle which had two separate, conflicting, snapshot votes within one week.

I understand the extenuating circumstances surrounding that instance, it would just also be good to try to account for this issue in the future.

Should there be a statute of limitations on repeated votes for a given issue?

Assuming there are two opposing snapshot conclusions, should there be a third vote to resolve their dispute?

I think it would be worth figuring out the official stance on this issue to prevent repeatedly creating votes until ones desired conclusion gets accepted.

[lefterisjp]

hey Simona, thanks a lot for taking the time to write all this down. Let me make some comments.

@Pop

Everything is open source anyway so building compassionate tech requires openness and honesty, not gatekeeping

When you say everything here what do you mean? Grant recipients? Things we build etc? Because this is actually not true and something that bothers me from the start about gitcoin and its mission statement changing away from opensource to defining “public good” software as something quite vague allowing pretty much anything to be called a public good.

@Pop

Any forum proposal must:

• receive input from at least 5 stewards
• be live for at least 5 days

I think this should be increased to 7 days and if not that then specify that 5 days should be Monday - Friday. Weekends should not count for this.

Additionally we should ping all stewards in discord (so there is an active notification) to come and comment on the proposals. Otherwise if none knows there is a proposal they won’t bother commenting.

@Pop

Accountability

I agree with this, but I think we should also add a clause in there for someone quitting their role, no questions asked. Sounds too harsh without such a clause.

Most of us have a lot of other responsibilities and having flexible roles would be paramount.

Perhaps this would be more regarding the actual role’s definition. More like a real-world contract. So what would you need to do and how many hours per day so that you know what you are signing up for and the workstream knows what to expect.

Personally I think I will just try to participate actively in governance as much as I can and try to help in workstreams if I can in some capacity.

@Pop

Suppose a proposal gets 1.5m votes in favor of Option A and 500k votes in favor of Option B. We add an additional 500k “shadow” votes to Option B to hit quorum (2.5m) and find that the vote is still strongly in favor of Option A. Soft quorum is hit and the proposal moves forward.

But if it’s:

A: 750k B:750k C:750k for a total of 2.25m then no soft quorum is reached, right? Since nobody has a clear majority and can’t guess where the shadow votes would go?

@Pop

Conflicting Votes

I would also like a clarification on the exact situation that happened with Akita. That was two conflicting votes. The first got ratified but then not executed and then another one came up completely ignoring the results of the first.

I would like to see some clear rules so that this does not happen again.

[linda]

Thanks for sharing this! Everything sounds really reasonable to me.

[bobjiang]

Thanks a lot for your detailed proposal, I would like to know more role-specific actions like

• what can delegators do?
• what can stewards do?
• how to involve in a workstream? (how to name this role?)

another suggestion is:
could we have a picture to illustrate the workstream lifecycle? e.g

• preparation (get comments from at least 5 stewards)
• make proposal on forum
• if meet criterial, then goto snapshot
• approve or reject
• continuous update (outcome and budget etc)

Last but not least, thanks again for your efforts

[php]

Great input and thanks!

The Renewal/Archive is a key part, I really like it.

Proposal to * receive input from at least 5 stewards - maybe we can consider to add something like : 5 stewards (that come from at least 2 different organisations, not coming from the same family etc)

[krrisis]

I think this is great Philip, thx for starting this! Although I think it merits a topic on itself, which could be fleshed out the moment workstreams are defining how to pay their contributors. That will also help to make it more practical? Not sure if it really needs to be included in the overall governance process though.

[krrisis]

Great proposal, thx for all the work on this simona!

I think this is pretty comprehensive and a great start to use as guidance for now, until some real-live situations require it to be adjusted.

A few thoughts:

@Pop

Any forum proposal must:

• receive input from at least 5 stewards
• be live for at least 5 days

Agree with @lefterisjp that this should be changed to ‘weekdays’ or ‘workdays’. I like the combo with also needing input by at least 5 people, and would definitely keep the requirement of both, so that nothing passes without some solid on-topic feedback that shows they have read the entire proposal. If not enough feedback, even if it’s just a simple ‘this all looks great’, the proposal remains open and has to wait.

@Pop

Workstreams requesting a budget for a project by default are assumed to be requesting a budget from the DAO treasury, denominated in GTC. However, this path for funding is not the only one available to a workstream or projects therein , and does not preclude workstreams or projects initiated by workstreams from maintaining a Gitcoin Grant or leveraging other coordination tools.

Is there any link that can be added here to how you actually request funding or what the format is for this (maybe an example of one that has passed already if any)? Or is this just by making a proposal on the forum as well?

@Pop

Individiual

Just a little typo here

@Pop

The code of conduct will be 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, or Yalor on Discord.

If you need help, don’t hesitate to add me.

Again, thx so much for creating this from scratch, this is epic!!

[joincc]

Great proposal, and I really like “Soft Quorum” idea.

I think we should add condition for “shadow” vote: original total votes must have minimum number (i.e. 1.5m votes) , or “shadow” vote must less than original total votes.

For example, original total votes is 1m, Option A: 900k votes, Option B: 50k votes, Option C: 50k votes, Option D: 0k votes. After we add 1.5m “shadow” vote (500K->Option B, 500K->Option C, 500K->Option D), vote is still strongly in favor of Option A. Soft quorum is hit and the proposal moves forward. But original total votes is too low(1m).

@Pop

We define soft quorum as follows: If a proposal would have passed in any scenario where the number of outstanding votes required to hit quorum were distributed to other options, stewards must act as though the proposal hit quorum. This is true no matter how many options were available in the poll in question.

[gmcmullen]

Hi people - this is my first post in the Gitcoin community. Hopefully fresh eyes will see some things the grizzled veterans have missed.

Overall I think this document is a great start. As a non-technical newcomer with a working knowledge of DAOs, I was able to parse it and figure out how the process works. There are a few areas where more detail would be helpful, and a few things that were missing and should be added. The document could also benefit from an edit for clarity and readability. I’d be happy to take a stab at that before the next version if people think that would help.

On to the comments:

@Pop

Governance Roles

There are three main roles in Gitcoin governance: stewards, delegates, and contributors.

Becoming a steward : Getting involved in a steward is easy, anyone who wants to be considered simply has to 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 pledge their intent to be a steward, but fellow community members will delegate voting power according to their own views.

Delegating your voting power : Anyone that wants to delegate GTC to a steward can visit the dashboard here and choose from the current list of interested parties. Delegation goes a long way in ensuring everyone’s views and thoughts are well represented. Delegations can be changed at any time.

Contributing to a workstream : Workstreams that have been successfully ratified, as defined below, will constantly be looking for new contributors, and over time just like in any DAO members who do well will be rewarded and given more stake in the future they’re helping to build.

This section explains the how, but not the what. It could use brief definitions or explainers for each of the roles, not just how to do them. This is one area that is probably clear to experienced community members, but a governance document should be usable by beginners too.

@Pop

Governance Process:

Note: All meaningful governance discussion should take place on this forum to ensure the community has full transparency

The Gitcoin governance process is the act of proposing, discussing, and deciding initiatives for GitcoinDAO to take on around the mission of sustaining digital public goods. As currently scoped, workstreams provide a place for discussion and collaboration, leading to proposals which are then voted on by the community.

Proposals can vary broadly, they can be qualitative / procedural (e.g. “Should Gitcoin Grants allow VC backed projects?”) and 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”).

This section might benefit from adding a brief step-by-step roadmap to the governance process as a whole, with links to detailed discussion of each point later in the document. Something like:

1. Create workstream
2. Develop proposal
3. Discuss proposal
4. Vote on proposal
5. Report on progress

An illustration might be even better

@bobjiang

could we have a picture to illustrate the workstream lifecycle?

@Pop

Moving to Vote

Once a proposal has met the above criteria, a formal Snapshot vote can take place.

In either this section or the Proposal Approval Process section directly above, there should be an explanation of how the move to the Snapshot vote occurs. Who decides if the criteria in the Proposal Approval Process have been met, and how? Who triggers the vote, and how? Again this might make perfect sense to someone who has been around the community for a while, but to a newcomer this is a black box.

This section could also be expanded to explain how voting works - what tokens are eligible to vote (ie. can you vote tokens purchased after vote is called?), how delegation works ie. (how to delegate, who can be delegated to, changing delegation…), what thresholds are required for certain kinds of votes (ie. simple majority or supermajority?), etc.

Finally, this section should set out how off-chain results are implemented. Who is responsible for sending tokens from the treasury?

@Pop

Conflicting Votes

From time to time there may be conflicting proposals, to avoid issues, the 5 day window above can also serve as time for anyone to list their preferred alternative option on the forum. Each proposal on an associate topic will have a [TOPIC] block placed in its title.

An explanation of what is meant by a conflicting proposal would be helpful here, along with some consideration of who gets to decide if a proposal is conflicting and how that decision is made.

[gmcmullen]

@Pop

Soft Quorum

From time to time, votes might narrowly miss hitting quorum. To facilitate better governance and avoid making participants repeat votes unnecessarily, a soft quorum rule is instituted. Soft quorum only applies to Snapshot voting given that we cannot execute on-chain votes if quorum isn’t met.

Is this handled automatically by Snapshot? If not, who is responsible for checking for soft quorum?

[Pop]

Whomever the proposer is basically based on voting % on Snapshot but stewards will typically check as well - as an example, the GR10 funds proposal got 2mil and on Tally quorum is 2.5 mil - hence soft quorum on that

[Fred]

@Pop

Any forum proposal must:

• receive input from at least 5 stewards

If anyone can become a Steward by delegating GTC to themselves - how do we keep this requirement sybil-resistant? Or is that a non-issue?

[ceresstation]

This is a good point, eventually we should probably figure out a way to more formally define / gate stewardship. I know some folks are working on steward health reports and maybe we can use some kind of activity / participation based metrics?

[seedphrase]

Hi all,

Great post and subsequent conversation on the various parts of the Gitcoin DAO governance process. I’m looking forward to seeing this get ratified.

The MMM Workstream has been working on graphics to accompany the governance process outlined above. We hope these graphics will make it easier to grasp the various parts of how Gitcoin DAO works and operates. Please feel free to comment and provide feedback if you think these can be improved further.

As described in the post above:
“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.”

1. This first graphic illustrates several Gitcoin DAO Workstreams in various parts of their lifecycle:

2. The Workstream lifecycle is divided into separate states. To move into a subsequent level of formality, a workstream must satisfy a set of criteria. This second graphic illustrates the lifecycle of a Workstream:

3. Active Workstreams consists of:
   (i) Formalized team and a directly responsible Steward(s) (shaded circle).
   (ii) Contributors (unshaded circles).

Contributors and Stewards can be part of multiple workstreams.

Workstreams are not funded by default and can have other forms of funding besides the Gitcoin DAO.

4. Stewards may lead workstreams and vote on governance proposals. The voting power of a Steward is equal to the amount of GTC being delegated towards them by Delegators.

5. GitcoinDAO is a liquid democracy and Delegators may change which Steward they delegate towards at any time.