Budget Proposal Process for Gitcoin DAO - v2

[Pop]

Original Accountability flow Jan 2022

Tl;dr

- Reasoning behind rework of the flow
- New format
- Consultation
- Evaluation
- Timeline S15

Summary

This proposal seeks to amend, improve and standardize the budget proposal process for Gitcoin DAO following extensive feedback across the steward council, the steward circle and workstream leads/contributors. The purpose of this revision of the accountability flow is to integrate the lessons learnt in S14 and ensure the new budget proposal process delivers the most value, alignment and collaborative consensus across the DAO. It is designed to ensure that any funding requested by workstreams is in service of and in line with the Purpose and Essential Intents of the DAO, improving transparency, accountability and accessibility when it comes to proposal review processes.

Motivation

A process to uncover, refine and define the purpose of Gitcoin DAO became a necessity as discussions around what should and should not be funded in S14 started to intensify. It became very apparent that any budget request must be made in alignment and with direct contribution to the purpose of the DAO.

As a constantly iterating and innovating force in the web3 ecosystem, improving the accessibility and transparency of DAO flows is the next level in better coordination. For our DAO ecosystem to flourish, it requires a mindful effort to improve on current tooling and to support better ways for DAOs at large to enable governance engagement and accountability across the board.

Current proposal framework

Proposals currently vary broadly in their stated goals, format and monetary requests.

This v2 of the Accountability flow aims to establish a better standard template to facilitate review and discussion. It aims to take the alignment started in the run-up to S14 and bring all Gitcoin DAO activity around a clear, transparent, quarterly dynamic for better alignment, contribution and transparency across the organism.

New budget proposal framework

As observed in S14, most of the proposals ended up being amended at least once so a better distinction between stages should make the process far clearer. All budget proposals should follow the following format & flow.

STAGES:

1. The first stage of a budget proposal will be a DRAFT

• the draft proposal will be posted on the forum showing [DRAFT] in the title and shared in the first steward call of the new season (ex. [DRAFT] Public Goods Funding budget request)
• the DRAFT proposal will then enter a period of consultation lasting two weeks. Feedback and discussion will happen both on the forum and in the stewards council call and should involve input from the community, stewards, the council and other workstreams. Workstream feedback is highly encouraged at this stage as cross-stream support could become a key piece of the evaluation flow.

2. The second stage of a budget proposal will be INTEGRATED

• Any feedback from the steward calls and the DRAFT post will be integrated in this proposal and published to the forum - this is to ensure clarity in amendments, changes and evolution
• this stage can be on the forum for one week

3. The third stage will be ACTIVE

• a proposal will move to ACTIVE after the consultation period ends and all feedback is integrated. This ACTIVE proposal will be setup directly on Snapshot and be setup with the following format:

- [WORKSTREAM] S# Budget Request
- Full amount - GTC and USDC Equivalent
- Tl;dr - one paragraph
- Main season objectives
- Link to INTEGRATED DRAFT for all info

The Snapshot will be live for a period of five days.

4. The fourth and final stage will be RATIFIED

• a proposal is RATIFIED once it reaches Tally and the funds are moved into the multisigs
• ANY proposal moving into a Tally should PASS. All decisions on yes/no are made in the ACTIVE Snapshot phase.
• Format: XXX workstream S# funding request ratification

The Tally vote will be live for a period of five days.

5. The fifth potential stage - should a proposal be “denied”

• In the event of a proposal being denied, a new proposal can be created using the following template. The purpose of the template is to create a clear delineation between maintaining status quo only (current operations and fulfilling OKRs for the season vs any expansion)

FORMAT:

• Which EI (Essential Intent) is the WS in alignment with (ratified current version here)
• A tl;dr section at the top of the proposal summarizing the main focus for the season.This is for increased transparency and a smoother decision making process.
• A milestone report containing goals achieved during the previous quarter. The milestone report should include:
• who are the current contributors (marked as FT or PT)
• funds spent to date/season & overall
• any funds carrying over to the next quarter
• notable achievements for the quarter
• Proposal body
• Mentioning initiatives, objectives, and metrics
• Budget breakdown

Example Proposal Template:

EI

Add the Essential Intent(s) respective Workstream is focused on.

TL;DR

Text section goes here.

Amount

State budget ask in GTC & USD equivalent. This section should include the following note:

The GTC total will be adjusted based on the current market value at the time this proposal is moved to Tally. The vote will be to send the requested $USD amount in GTC at the lower of the current price or the 20 day moving average, whichever is lower.

Milestone Report

Initiative/Dept Objectives Past Season Value Delivered

Proposal Body

Focus on essential work for season you are requesting budget for ONLY

Initiative/Dept EI Objective Current Season Key Results

Budget Breakdown

Budget Category
(Dept/team) Goal/OKR relevant to EI for season requested Amount GTC Amount USD

• Visual breakdown (this will be created by @ChrisDean in collaboration with each workstream - an automation/templating of this endeavour will hopefully be in place by S16)

CONSULTATION:

The consultation, evaluation and ratification period for proposals is to be extended from the cadence of ~15 days experienced in S14 (and before) to a longer process as of season 16. This means that DRAFTS would be presented at least one to two months before the end of the previous season.

This is to enable ample discussion, feedback sessions and engagement across the decision making apparatus.

Types of discussion:

Workstream: xx

CSDO: xx

Forum: Comments and feedback should be recorded on the forum as in previous seasons

Stewards Call: a space for discussion involving the stewards - this will involve the steward/workstream allocation we discussed for better insight

Steward Council Call: a space for strategic discussion amongst council members to address any pressing or problematic requests

EVALUATION:

*NOTE: not all WS will match ALL EIs

*Any budget request scoring under 4 average across stewards/community may need to revise budget request

Financial Evaluation:

A visual report of the budgets for all WS against the treasury will be provided and WS will have it accessible to include in their proposals. A more complex forecasting report could evolve from here where we genuinely look at short | medium | long term.

Timeline

Key dates for upcoming season (S15) :

07/25-08/08 - Review DRAFT proposals

08/08 - INTEGRATED proposals on forum

08/15 - FINAL proposals on snapshot

08/22 - FINAL proposals on tally

S16 learning & dates coming up in v3

[DisruptionJoe]

@Pop

The fifth potential stage - should a proposal be “denied”

In this stage, will it be required to do a full 2 weeks again on draft and one week of integrated before snapshot? Perhaps the only rule here is that the new proposal must be up for 5 days unchanged before going to snapshot. This way the onus is on the workstream to take feedback for as long or short a time as is needed.

@Pop

EI

Add the Essential Intent(s) respective Workstream is focused on.

Essential Intents align much more closely to Initiatives within workstreams rather than workstreams. Perhaps this should change. Or perhaps we simply change this to be at the inititive level

Example = FDD
Operations = FDD OS: Maps to Financial Stability & DAO Organization
Initiative 1 = Grants Eligibility: Maps to Grants Program Success
Initiative 2 = Contributor Fraud: Maps to Grants Program Success
Initiative 3 = Protocol Research: Maps to Protocol Adoption & Growth

I think the evaluations would be best to apply to the initiative level as well.

[seanmac]

Thanks @Pop. If I’m reading this schedule right the draft budgets are supposed to be up on the gov forum July 25, which is yesterday?

Based on previous discussions, in MMM, we are targeting having a draft budget for review and internal discussion by EOD tomorrow, July 27 and then discussing on Friday with workstream leads before posting to the forum?

Does that align with your expectations and understanding? I believe this timeline was communicated by @krrisis and @samspurlin.

If so, how does this change the schedule proposed here?

[krrisis]

Heya Sean,

What you’re saying is correct. Review period was originally starting in the week of 07/25, but as we only have our WS strategy call this Friday, review period actually starts on 08/02.

[bobjiang]

Thank @pop for the updated budget proposal process!

Like the EI (Essential Intents) alignment parts the best.
With EI (mission driven), all the WS would go to the same direction.

looking forward S15.

[tjayrush]

@Pop

Workstream feedback is highly encouraged at this stage as cross-stream support could become a key piece of the evaluation flow.

I would change this sentence to “…cross-stream support will become a key peice…”

Any feedback from the steward calls and the DRAFT post will be integrated in this proposal and published to the forum - this is to ensure clarity in amendments, changes and evolution

It would be very helpful if the changes are made notable so the reader is not required to re-read (and re-grok) the entire revised proposal. This might not be easy to do in the forum, but perhaps revised proposals could have a section called, “Things modified in this revised proposal” summarizing the changes.

This means that DRAFTS would be presented at least one to two months before the end of the previous season.

This is a great idea. I was thinking about suggesting not only this, but that the workstreams actively SIGNAL their intentions in the forum. “Hey DAO, we’re thinking of shutting off project X which will lower our ask by Y amount,” or, “Hey DAO, we’re thinking of adding project X which will increase our budget by Y amount.”

This could be done prior to the budget proposal going into “DRAFT,” so that people are familiar with the changes from previous rounds.

The way it works now is that these budget proposals are “dropped” on the community. If it was more of a continuous thing with SIGNALS, it would be easier to digest when it drops.

The Evaluation Section

I am so happy to see “financial sustainability” explicitly listed as part of the Evaluation section.

I wonder if you considered including a similar section in the Budget Proposal Template.

Force the workstreams to discuss how their work becomes (if it can become) financially sustainable, or if it can’t become financially sustainable, then how it supports the efforts of other workstreams that are. If a work stream isn’t one of those two things, it should go away sooner rather than later (in my opinion). Note that I’m not saying financially “profitable”. I don’t care about that. I care about financially sustainable.

A suggestion to add to the Template:

I really want there to be a “best practices” section as part of the Template instructing people to avoid the use of ACRs (ACR == acronym). Every time I read a budget proposal, I get lost within 10 seconds because it’s ACR-heavy.

ACRs are impossible for regular humans to understand. Having said that, ACRs are useful. Suggestion on the template: If you use an acronym, please spell out its full name the first time you use it followed by the ACR in parenthesis.

We in the Group Against Acronyms (GAA) hope we can stop using un-explained acronyms in order to make our budget proposals easier to understand.

I used to teach business writing. This was part of lesson one. Not everyone reading your proposal is in on the lingo.

Summary:

Great work. I think all of this is super important. Don’t use ACRs.

[linda]

This looks great! Thanks for putting it all together. I’m excited about the improvements.

[krrisis]

Adding the updated template for the upcoming seasons as created by @tigress for illustration/visualization.

This is the [draft¦integrated] funding proposal for the [Workstream] requesting funding for Season 16 (1 November 2022 through 31 January 2023). In addition this proposal outlines what we plan to accomplish during S17 (1 February 2023 through 31 April 2023).

Even though we are planning for two seasons, Stewards will be asked to release the budget in two equal tranches. 50% now for S16 and 50% later for S17. If you have any questions regarding this process, please contact the workstream leads.

Essential Intents

[Outline your alignments to the EIs]

TL;DR

[Summarize]

Based on what we learned in Season 15, we will … [add reflection]

For more context regarding our vision, the current state of the workstream and more please refer to the [supplement document link].

Amount

[Workstream] is requesting [Amount in USD] for S16. Additionally, at the End of S16 we will be requesting [Amount in USD] for S17.

This budget does not include the additional 60 days of reserves per season. A breakdown of the budget can be found at the end.

Gitcoin Season	Season 15	Season 16	Season 17
Season Budget	$	$	$
Season Reserves	$	$	$
Unspent Reserves % 1)	100%	100%	100%
Treasury Request 2)	$	$	$

1) The amount of GTC requested and the value of the reserves will be adjusted based on the current market value at the time this proposal is moved to Tally using the lower of the current price or the 20 day moving average, whichever is lower.

2) The Treasury Request amount is an estimate using the price of $2.00 GTC to calculate the total of the reserves rolled over from Season 15.

Milestone Report for the past Season

Legend
Success
Incomplete, will hit goal or priority change
Incomplete, will not hit goal
Canceled - out of workstream’s control

Initiative/Project	Always-on [YES/NO]	Key Results	Value Delivered
[Initiative/Project] [Objective - 1 concise sentence]	YES	Key Result Key Result Key Result	Delivered Value XYZ Failed because ABC Waiting for KLM
[Initiative/Project] [Objective - 1 concise sentence]	NO	Key Result Key Result Key Result	Delivered Value XYZ Failed because ABC Waiting for KLM

Objectives and Key Results

[Your intro here]

Help? More about the terminology like Initiative, OKR, Project etc.

In addition, we are outlining our Always-on Commitments as well as Shared Commitments with other workstreams and/or teams of GitcoinDAO in the [supplement doc link].

List of S16 OKRs

Initiative/Project	Always-on [YES/NO]	Metrics	Key Results / Likely Deliverables / Projects
[Initiative/Project] ([Refer to EI]) [Objective / 1 concise sentence]	YES	* Metric A * Metric B * Metric C	- Key Result 1 - Key Result 2 - Key Result 3

List of S17 OKRs

Initiative/Project	Always-on [YES/NO]	Metrics	Key Results / Likely Deliverables / Projects
[Initiative/Project] ([Refer to EI]) [Objective / 1 concise sentence]	YES	* Metric A * Metric B * Metric C	- Key Result 1 - Key Result 2 - Key Result 3

Budget Breakdown

View: USD per Initiative/Project

Initiative/Project	Amount USD	%
[Initiative/Project] ([EI])	$	80%
[Initiative/Project] ([EI])	$	20%
Total	$	100.0%

View: USD for Always-on only!

Summarizes all initiatives and projects that are considered as Always-on:

Always-on Initiative/Project	Amount USD	%
[Always-on Initiative/Project] ([EI])	$	80%
[Always-on Initiative/Project] ([EI])	$	20%
Total	$	100.0%

View: USD per Category

Budget Category	Description	Amount USD
Core Contributors	Role ([Name]) Role ([Name]) Role ([Name]) Role ([Name])	$
Trusted Contributors	Role ([Name]) Role ([Name]) Role ([Name]) Role ([Name])	$
Hiring, Bounties, HIT Roles	New Role ([Name]) Bounties	$
Total		$