Workstream Budget Proposal Process - v3

šŸ¤– DAO Governance and Vision
, , , ,
1

This passed proposal amends and hopes to improve and standardize the workstream budget proposal process for Gitcoin. This proposal was ratified by CSDO on 03/31/23 using the integrated decision making process, you can find the recording, clarifications and reactions here.

TENSION:

Currently, our 3-month budgeting and planning cadence is putting a lot of stress on our DAO. Some examples:

  1. A lot of time is spent by Workstream leads planning and preparing for budgeting, leaving less time to execute or evaluate.
  2. CSDO team members continue to mention the current process is not working for them.
  3. Budgets arrive +1 month after the start of the season.
  4. Budgeting has become increasingly emotionally challenging for contributors who feel they need to defend their job security every 3 months. We want to make sure we ensure continuity in funding for our ā€˜most important thingsā€™.

PROPOSAL:

This proposal seeks to amend the workstream budget proposal process for Gitcoin. The purpose of this revision is to add better accountability to workstream results and reduce the time spent on the budgeting process. This work is done in parallel with providing a plurality of funding mechanisms for Gitcoin, specifically outside of the workstream.

Tl;dr: Key elements of this proposal are:

  • Moving to a 6 months budget rhythm (keeping the season names as is for now)
    • One Snapshot vote, two Tally votes
    • 2 budget requests, 3 months apart
  • Reduced reserves (2 months, i.e 1/season), only used for remediation of price fluctuations, incl regular reporting
  • Focus on top delegate (most active/highest delegated) Stewards
  • Updated and unified template including an additional budget view (per initiative) for easy budget evaluation

DETAILS:

What changes:

1. We decouple prior season results from budget

  • We no longer refer to previous results. New budget requests should not depend on previous results, as accountability will be built in through milestone data (see below). In the longer term we also hope to add a number of DAO-wide KPIs.

2. We move from a quarterly to a semi-annual (2x per year) cycle

  • This means for example that the upcoming budget round will cover S18 & S19
  • There is only one Snapshot vote for the entire proposal. However, GTC will be disbursed in two parts, one per season, and will include one month of reserves with each season. Top delegates will normally vote yes on both Tally proposals. Advantages of this tiered disbursement: (1) this reduces the impact of GTC volatility on the treasury (2) this can be used as a backstop in case of serious spending misalignment.

3. We focus more on top delegate Stewards check-in

  • The idea is to have less discussion on budgets to fund our mission-critical, most important things and to evolve the wider Steward role into having more input on GCPs and other key strategic items throughout the year.
  • In our planning we have one week to organize calls with our top delegates to get feedback and buy-in on our budgets.

4. We will add more detailed line items at the project level (see template)

  • Project prioritization (high/medium/low)
  • Meaningful milestone data
    • Break down projects into highly detailed key Projects and Milestones, for as far as they are known at the time of the request
    • Workstreams should report on Milestones progress to CSDO/Steward Council on a monthly basis

5. We will strive to complete the voting process before each season starts

  • For our first run of the new process we will still be slightly delayed, but the idea is to have budgets in the multisigs +/- by the start date of the season.

6. We will all be using the same updated budgeting template to make it easier to evaluate and compare

  • Addition of underspend/overspend past season
  • Focus on Outcomes & Milestones
  • Triple budget breakdown:
    • Milestones
    • Staffing
    • Reserves breakdown and Rollover, incl link to reserves reporting
  • Template can be found here

7. We will request two months of reserves for the entire budget request, or one month per season.

  • Slightly decreasing the budget reserves can lead to more workstream accountability on doing healthy treasury diversification, and bring more transparency on unforeseen costs (through GCPs)
  • For the time being workstreams are responsible for managing fluctuations in price by diversifying into stablecoins whenever needed. In the long term we need a strategy for token holdings. For small changes in token price the buffer of 33% should suffice.
  • Reserves should only be used to cover price fluctuations, workstreams commit to reporting regularly on use of reserves, and will link this reporting into the next budget request.
  • Any revenue generated during the past season should be accounted for, flow back to the DAO or be rolled over into the next season
  • In case of larger changes in budget needs (hires, unexpected projects, ā€¦) the workstream can request more funds through a GCP.

What stays the same:

  1. Workstream leaders still need to prepare and get a budget approved
  2. The approval process remains the consistent (CSDO > Stewards > Snapshot Vote > Tally Ratification)

Example of a budget request timing (S18-19)

04/14 Objectives & draft review with CSDO (3h call)
04/17-21 Check-in with top stewards after sharing draft budgets
04/24 Integrated budgets on Forum
05/01 Budgets on Snapshot
05/08 Budgets on Tally
05/15 Budgets in multisig

Out of scope for this proposal

  1. A tool to do the reporting
  2. ā€œActualsā€ reporting process
  3. Project dashboards
  4. Ongoing operational support (budget facilitation)
  5. DAO-wide total budget cap

Reference documents

Thank you to @shawn16400 for contributing to this proposal and CSDO for valuable input and ratification.

6 Likes
2

So excited for us to tease apart strategy talks from the budget cycle. I know Iā€™m completely convinced that this group will over-deliver on the aggressive goals we set for ourselves for S18 and 19 and canā€™t wait to see what mountains weā€™ve scaled this time next year. Looking up at a wider horizon-line will accelerate us moving into that future.

Thanks for all your work on this @krrisis and @shawn16400!

2 Likes
3

Thank you for this proposal! It will definitely reduce the stress on the DAO as you have outlined here. My concern is on modifying the budget duration without changing the season duration. Usually they go in sync to effectively run iterative time-locked development, in this case the work is done on a different timelock (3 months) but budgeted for (6 + 2 months), which imo defeats the purpose of receiving feedback and iteratively improving.
a. Do you have any examples from other DAOs/org of this unsynced iterative update working effectively?
b. How about syncing the seasonal duration with this budgeting update?

4

I think this is a great point about feedback cycles and iterative learningsā€¦

@krrisis I know your focus for this post was about the budget itself, but perhaps we also want to put up a way-forward in terms of quarterly (seasonal) strategy reports?

Thinking here that each workstream commits to provide the following at the close of each season:

  • OKR ā€œscoresā€ or similar granular progress report
  • Top learnings - what worked/what went wrong in tl;dr fashion
  • Updated roadmap

If we are posting these on a regular basis, I think there could be a nice feedback loop for those who want to double click into any of the seasonā€™s events, as well as increased accountability for overall performance/aspirational goal-setting. (I believe we shouldnā€™t be 100% on our OKRs every time, for exampleā€¦ this would indicate to me we werenā€™t reaching high enoughā€¦)

Would love your thoughts if this satisfies the need for time-locked development practices @jengajojo and your thoughts on whether such strategy discussions will work well on this forum or deserve another format @krrisis and @shawn16400ā€¦ Big ask is that this not turn into a needless admin task- but something that integrates easily into the project planning and product roadmapping the workstreams already doā€¦

1 Like
5

Ale,
I see three parts of your suggestion, one on accountability (operational excellence), reflection and learning (continuous improvement), the final piece is tactical adjustments, aka progressive elaboration (we get smarter as we build).

Part 1 is addressed in the proposal, but not sure how well it is going to work. Accountability and reporting may be necessary depending on the granularity of the project work provided by the workstreams in the budgets. Said another way, moving to a project based format should elevate ā€œmilestonesā€ related to each project.

Recall one of the problems to be solved within the DAO is ā€œaccountabilityā€. By moving to a project based-format the individual project team would report progress on a monthly basis as Kris illustrates here:

If we have a combination of 1) meaningful milestones in budgets and 2) monthly reporting against milestones, ideally status updates would be on a monthly cadence vs. quarterly. We will see how it works out.

Part two and three are not really addressed in the budget planning document. Continuous improvement - the deliberate and reoccurring reflection to identify necessary changes (AKA kaizen) seems to be hit or miss in many DAOs. I see value in regularly scheduled after action reviews as a tool to deliver improvement, but my sense is there is little appetite for this kind of work in the DAO. But, I would love to hear if others see this as a need as wellā€¦

Related to updated road maps, this might be a bit of an adjustment for workstreams as we move to bi-annual budgets, but I suspect we will get better overtime (even in this unpredictable world). This we can easily build into the steward reporting cycle found here:

6

hey @jengajojo thanks for the question. When originally thinking about solving the budgeting problem was 1) assuming that whatever fix we put in place would not be 100% right from from the and 2) we wanted to limit the changes to what was 100% necessary.

To your point, we suggested early on that some workstreams may find the 6 month cadence difficult and a quarterly process might be more appropriate, thus perhaps we should offer both. In the end we abandoned the idea of a mixed cycle due to the potential confusion it might create, and we were not sure if a quarterly cycle might be needed. If at the end of this experiment we find the 6 month cycle is not quite right, we might resurface that idea.

Additionally, former proposed budget changes did not get much support partially because of the magnitude of change proposed (IMO). I think they were too ambitious and it died under its own weight.

This is a long winded way of saying we did not propose a longer season because 1) we are not sure if the 6 month change will stick and 2) we wanted to limit the scope of change.

So net: stick with us - because it might still yet change next season!! : )

1 Like