This was my first reaction as well. I took a bit of time here to try and diagram in Miro
Just a first pass to summarize the process as I understood it from the post. Happy to incorporate feedback, or folks are more than welcome to fork/update as they like.
@safder a ton of thinking in here. well done wrapping your mind around several outages in the DAO.
In general, I encourage proposals to be smaller in scope to in order to
I know this proposal works in concert across the three areas, but I would see value in breaking this into two components: 1) budgeting and 2) performance evaluation. I think âforecastingâ is confusing strategic planning / goal / road map development and that is a separate process - which also needs work, but separately.
But. I know web3 is enamored with omnibus proposals so I am likely going to be banging my head against this rock for a while 
related to 3. Performance Evaluation section
This is a gap, thanks for calling this out.
Do these proposed questions integrate with the DAO Health Survey set to launch next week? If not, they should. Consistency across mechanism will help with comparisons. Based on the solid input @k3nn.eth gave us on the DAO health survey design, it would be helpful to get talentDAOs take on the questions. I could also thinking of linking into the DAO Health work rnDAO is doing atm. Happy to connect dots.
Monthly seems a bit heavy for the stewards - I would go with a quarterly assessment, but if you really want monthly data, we can do a continuous batch poll, for example. We could do 1/3 of our 200 stewards each month.
regarding 2. Resource Allocation
Part of me likes 6 months, but the overachieving-ambitious part of me (its a small part) wants to move to a jobshop project portfolio design where funding is allocated by project, not by arbitrary timefences. But, might be for later. I like 6.
This should be the case anyway - regardless of the budgetary cycle. I would pull this out of the proposal and build it into the ongoing seasonal deliverables for DAOops. Random side note, I donât quite get the secrecy around individual DAO compensation. Actually, I do as I have fought this battle in non-profits as well, but in the US, government organizations publish individual salaries as do many non-profits.
Example:
https://data.cincinnati-oh.gov/Efficient-Service-Delivery/City-of-Cincinnati-Employees-w-Salaries/wmj4-ygbf/data
Also - given payments are on chain - there is only an illusion of privacy, individual payments are figure-out-able.
Net: Just publish the data and let stewards chew on it. Way faster. (/end rant)
I agree professional treasury and financial management is a gap at Gitcoin. But I do not think this is the place to attempt to professionalize treasury management or building contingency plans for market drops. It has to be done, but not here.
In summary:
You put a ton of thinking into this and you scratched the surface of a LOT of improvement areas. I suggest focusing in on smaller bits, and knock them out of the park.
Additionally - I think you need to bring this to the Steward Council as a topic and get input from from that council of web3 wizards. It may not be a converging exercise, but if you scope this right, you will get some great input. Next free agenda period is Jan 23 - but we can call a ad-hoc meeting of those with relevant experience to review the topic sooner.
Great post Saf, lots of rich details here, and I would echo the points above about distilling key points (i.e., maybe an executive summary) and producing a helpful graphic to help people who donât have the time to deep dive on this (shouts out @kevin.olsen).
Going deep on one specific part here, I worry about the rhetoric regarding tying spending to GTC price. I know Iâm somewhat a heretic with my belief that token price has nothing to do with performance, but Iâm becoming increasingly convinced that token price is a terrible indicator for success, especially when the token is a governance token. This tweet from Messari about Yearnâs ATH TVL and ATL token price is something I think about often.
In the absence of super strong tokenomics (which we are currently moving quickly towards) there is no reason we should assume token price is currently any indication of success, which I view as an implicit assumption behind this idea you purpose.
The most recent pump of $GTC in early November, from my perception, had nothing to do with anything the DAO achieved.
I worry that this idea of âtying spend to token priceâ in the absence of strong tokenomics is a poor idea. Iâd propose we consider alternatives. For example, tying spend to revenue generation, or simply holding off on this until we have strong enough tokenomics to assume any price action is the result of something we are or arenât doing. There is currently a ton of work underway to address the revenue generation and tokenomics pieces, so Iâm optimistic weâll solidify those pieces in place in the coming months.
I might be completely wrong here, and perhaps tying spending to token price at this moment is a good idea.
However, Iâm personally highly convinced that token price is an enormous distraction, and we should focus on achieving a state where the DAOâs spend is not at all concerned with token price fluctuations, meaning that we either have enough stables to support operations, or better yet we have enough revenue to cover our costs via either strong tokenomics or a successful business model (hopefully soon!).
This is amazing, thanks for putting this together Kevin! To fill in the question mark, if thereâs a ânoâ vote to a workstreamâs proposal, this signals that Stewards disagree with how the workstream has chosen to respond to the forecast (Stewards donât think the proposed work would be valuable to the DAO) - this would require redoing the proposal integrating any feedback received.
In contrast, what we currently have is a monolith that includes all three of these components as one inseperable block.
Super appreciate this feedback - the current version thatâs been shared has been through several rounds of editing to get it to be as digestible as possible, but I agree itâs stil quite a mouthful. At this point, now that the catâs out of the bag, would it still be helpful to split this out further into two posts?
It does not - the thinking behind this was that the questions in the monthly review are centered around accountability, whereas the health survey is more around contributor experience. While there is some overlap between these, I think it makes sense to have separate metrics for each. Note that contributors are reviewing other workstreams (not their own), so again the focus is on accountability in both the contributor as well as the steward portion of the reviews.
I tend to agree here - I originally had this set to just the Steward Council (as they have a mandate to keep a closer pulse on DAO activities), but received feedback that it could be wiser to leave this more open. The Steward Council would mainly be the ones expected to complete this monthly, while it remains optional for other stewards. It was also designed to be a very light lift, with Stewards only expected to answer 10 questions on a 1-5 scale.
Yes, there are conversations to move in this direction post-protocol launch (as a heavier restructuring before then might be too large of a disruption). The good thing about this proposal is that in that case, we could easily adjust the resource allocation portion of this process while the other components remain largely the same (or receive minor changes).
Again, couldnât agree more here - I am definitely of the opinion that every DAO that truly aims to be accountable to its community should have fully transparent compensation practices (and many of the best do), but this is a hotly debated topic and the prevailing opinion is to keep these private. As a Steward, I would advocate for demanding greater salary transparency from the DAO, but as a contributor, this feels out of my control (I have voiced this opinion in the spaces I do have access to internally).
This came out of conversation with some Stewards - the biggest thing Stewards want to see from the DAO in the current market environment is contingency plans in case of another severe market downturn, and incorporating this into our budget feels like the most natural home for this (as this would affect all other aspects).
Yes I think an ad-hoc meeting with interested Stewards would be very helpful - especially since Iâm planning to be away the week of January 23. Iâve spoken to a couple of Stewards on the council and incorporated their feedback into this proposal already, but would love to get more feedback.
I 100% agree that token price is very loosely, if at all, tied to performance. I think the reason there is such a strong push to tie our spending to token price however (again, this section was included after a strong push from some highly engaged Stewards) is not because itâs being used as a measure of our performance as a team, but because ultimately what the DAO has to spend is GTC. With ~80% of our treasury consisting of our native GTC token, a sharp drop in token price (for reasons completely unrelated to performance) ultimately means we have significant less funding to work with. This component of the budget process serves as a âbreak in case of emergencyâ forcing function for us to pause what weâre doing, and consider adjusting priorities in the case that we suddenly have 50% less funding to work with.
Makes sense to me, thanks for clarifying.
I think this survey may be conflating two different respondents. If we are polling contributors, the proposal makes sense on a monthly cycle. If we are polling contributor-stewards, it makes sense. But it seems a stretch to ask non-contributor-stewards to be able to monthly weigh in on such questions as:
Please consider the Stewards primary touchpoint is a 1 hour meeting 1x a month and quarterly budget proposals. Without some other mechanism to provide greater WS visibility to stewards so they can answer the questions in a meaningful way, I think monthly polling will become an annoyance.
But, if someone really wants to give it a go, lets try it and see the results after 3 months. Or as mentioned before there are 200 stewards - you can do a rolling poll of 1/3 of the stewards each month and see what happens.
Sorry - did not mean to distract from the relevant passage in the proposal - which I forgot what it was and canât find the original reference because is was like 15 pages ago. For reference, see âI encourage proposals to be smaller in scope to in order to:â somewhere above
At this point, I am too long on this post and will try to pick up the rest later.
I think, at first blush, these changes look like theyâre moving in the right direction.
That said, Iâm a bit apprehensive about this proposal being framed as a complete redesign, incorporating many different little pieces all into one big proposal to change this super meaty process once & for all. (Itâs also overwhelming to try and evaluate it all as a steward.)
What Iâve seen work well in Gitcoin/CSDO governance to date is more iterative, smaller moves to test ways of working and then charge forward with them, or scrap them, depending on how each one goes. What I worry is that this whole thing gets passed as a proposal â and then parts of it ultimately work, but parts of it ultimately donât, and then it becomes unclear if the process redesign was a success or not.
I am wondering if there might be a way to make this proposal more modular/iterative?
To me, the forecasting/objective setting â resource allocation â performance evaluation metastructure is a no-brainer at the highest level, but Iâm not necessarily convinced on some of the specific details within each (mainly because this is all new territory and we just donât know whatâll work!) so Iâm wondering if you guys might start with a bit of a broader proposal on structure and then describe what youâll test within that structure each cycle, rather than implementing a granularly thought-out process once and for all.
Just food for thought.
Part 2:
This is building in the open looks like - we get all the messy bits of diverge, converge, and diverge again. I am just node = 1 so lets get a pulse check from the community. If we get less than 10 responses - the results would likely not be directional. Which is possible given attention span dips after a few pages (this comment will appear on page ~20)
(see âI encourage proposals to be smaller in scope to in order toâ above)
> READERS - PLEASE WEIGH IN ON THIS ANONYMOUS TEMP CHECK POLL BELOW
We should break this into smaller, more focused proposals
We should keep as one proposal and just figure it out
Undecided
Finally - as this gets closer to proposal execution, I would look for some input on the 1) cost of the work, 2) time allocated to get the work done 3) which workstream would take the lead (and cost) on which part and 4) how this intersects with or subverts season plans.
As a steward, I support the direction this is moving in and appreciate @safderâs earlier outreach with DAO members + other stewards to gather feedback on the design.
I agree with above comments about distilling this to a simpler proposal, which probably means omitting some some of the process and implementation details for now. I like what @kevin.olsen started with the Miro board and would like to see another iteration.
IMO, the design challenge is to have two feedback loops: one for the DAOâs essential intents and strategic objectives; the other for the DAOâs resource allocation across people and projects. These should be assessed independently even though they will often yield highly correlated health metrics / decisions.
Keeping them parallel also helps prevent the system from reducing a la Goodhartâs law to: monthly scorecards â votes of confidence â resource allocation decisions.
Finally, I would add that the level of coordination should ebb and flow based on the market cycle (or revenue projections): tight times call for tighter coordination.
This is a daunting undertaking. I know. Iâve been researching aligning strategy with operational execution for years. Coordinating efforts across a network of contributors is challenging without a central place to view the big-picture plan.
If you are looking for feedback, Iâll offer mine. This is another approach you can look at after implementing this current effort. Here is a quick video (<5min) that shows this approach.
The image below shows Gitcoinâs 2022 plan using modular and composable plan building blocks.
An important point, this âbig pictureâ plan doesnât exist anywhere (you know this). I had to visit a ton of online locations to assemble it. It is easily captured using plan building blocks.
If Gitcoin used this, contributors and the public could see the entire seasonâs initiatives in one place, easily understand whatâs going on because of its simple visual form, and know where to jump in and add value by searching for open opportunities.
I disagree. The token price pump started only a day after Messari published this report about Gitcoin
https://messari.io/report/governor-note-decentralizing-gitcoin
In that report, Messari said:
This proposed solution signals the Gitcoin leadershipâs confidence in the modules they have built
Some component of the token price will always be tied to the macro economy, macro crypto markets. And some will be tied to Gitcoinâs own performance.
Gitcoin should not turn nihilistic and assume that they have no agency over the direction of GTC.
Thank you for acknowledging this point!
This is a great idea.
Itâs so hard to follow the budgeting processes because workstreams are so bloated and they donât map to the DAOs goals. This makes it hard to see where the $1 million per month is going, and which outcomes they achieves. Since oversight is so complicated, this means there is not a lot of accountability to outcomes.
@a33titude brings up an important point.
Gitcoin has modular protocols. But itâs budgeting is not really modular at all! If funding was more modular and it were tied to outcomes, thatâd make it much easier to track what is worth funding and what is not.
TLDR I think a sign of a more mature GitcoinDAO would be if there was competition for modular teams creating outcomes.
Haha great to hear the budget process I put in place was horrendous.
I think some elements of the redesign are good - glad to see the workstream cards making progress as intended in my original work towards it with @Fred. That said, I echo A LOT of the sentiment from other stewards and the community that this proposal âincorporating many different little pieces all into one big proposal to change this super meaty process once & for allâ (@annika) is too intense.
As demonstrated in the process up until now, incremental changes and improvements tend to work better. A tree does not shoot up all at once. I advise breaking this down into phases that are not only easier to observe and measure but also easier to digest for everyone and rather than correcting a whole organism if it fails, you address the small part that can be improved.
Hey @safder as I was thinking about this - the power of web3 is open source and forking. Not reinventing the wheel everytime we need a new process, but rather scouring DAOland and looking for those who have solved whatever problem it is that we face.
I know this takes a ton of time, and none of us are gifted with enough, and so I recognize that. Have you been able to look to existing approaches to see if there might be solutions that we could fork?
I huge thank you for the thought that everyone put into this.
The good news & the bad news is that nobody gets forecasting â budgeting â accountability quite right afaik.
The better an organization is at forecasting - the more deterministic their results are - the closer they are to becoming a slow or no-growth organization. Variance is the enemy of forecasting. And yet rapid growth takes an organization that will âsense and respondâ quickly.
That said - driving blind without forecasts is sort of ill-advised for any size org.
My other priors include:
TL;DR -
Why?
One more point on external view - while it isnât in our essential intents - I do wonder if having as a goal or aspect of our mission helping to grow web3 itself could be useful. A few folks discussed this briefly on the broad stewards call recently. How this intersects budgeting is that it could be that we need to reinject some broader vision into our thinking as we appear to approach the goal of turning into a protocol our software and hence wonder whether we are not soon to become a hyperstructure, running on forever with or without all of us 
Jumping in and adding my two cents here. Iâm a fairly new steward but can see how this proposal is aiming to make the existing budgeting process more efficient. I enjoyed reading it @safder, it was very detailed and thought-through.
I think the overall goal of providing a six month cadence for funding makes sense so as to give workstreams a bit more runway in their planning. I also like the idea of using Workstream Health Cards to inform forecasting, which then informs resource allocation. Smaller-scope more frequent check-ins that lead into less frequent, larger scope decision making seem like a smart/standard way of operating.
I think a monthly check in might be a bit much for stewards however which is why I love @shawn16400âs idea of maybe checking in with 1/3 of stewards every month on a rotating basis.
Overall, I think this proposal is moving in a really great direction but would second the idea of breaking it up further and making it more modular, per @annika and @Popâs comments.
Really exciting to see the thinking around this process evolving in real time!
Super appreciate all the additional comments, all! The general theme that Iâm hearing is that while folks are aligned on direction, to implement this all at once and fully replace the exisiting budgeting system feels that itâd be risky + hard to change-manage and evaluate. This is very fair - internally weâve been looking at this for a few months so have had a bit more time to digest the various components, but even so, a more iterative process would also be easier on the team as we continue to remain focused on the upcoming protocol launch.
We discussed this during the CSDO strategy meeting earlier today, and the general direction weâre leaning towards is starting to experiment and iterate with the Workstream Health Cards (module 3 of this proposal). This component aims to resolve a number of tensions:
We discussed making a few amendments to this module (cadence/subset of Stewards participating etc) over the coming week, before sharing with Stewards during the Feb 1 Steward Council meeting. More will be shared here on the gov forum as this develops!
To respond to your concerns on this component @epowell101: this wonât replace OKRs being used to create targets at workstream and individual levels, however performance will not be evaluated against these OKRs (this is a known problem when using OKRs for performance evaluation).
Yes! I shared the research that I conducted during the internal design process - happy to share here too if thereâs interest (or DM you with this). I was unable to find anything innovative happening in the web3 DAO budgeting space - all DAOs are using some form of the traditional budgeting process, with changes being in cadence/using tools other than OKRs for planning. I think a lot of DAOs look to Gitcoin for operational best practices.
However, there is plenty of innovation in budgets in âweb2â Teal organizations; the framework I took inspiration from for this process is Beyond Budgeting - you can find a lot of high-quality academic research on this framework if youâre interested in deep-diving.
Not to rabbit hole - but the article on OKRs being problematic when tied to comp sort of says that specific tasks & self-set goals CAN be tied to comp reviews however you have to be careful in setting them & in reviewing them not to do so blindly - or in our language âautonomouslyâ or mindlessly. Otherwise, such OKRs can naturally lead to sandbagging and zero-sum behavior.
What Iâve done in the past that I think worked is to have a section of OKRs & 360s that was tied to teamwork & taking initiative & other activities that are more about values & collaboration - the very sort of things that sandbagging & zero-sum behavior would cause low scores on. It isnât perfect however it highlights the need to acknowledge the risk of errors of omission vs. commission dynamics.
TL;DR - I think that we are all looking to reduce the incentive to game the system. One approach is to have a section of the OKR that is explicitly about not gaming the system.
ALSO (added this a little later than the original response fwiw) - this may be conventional wisdom as opposed to a blinding insight - one approach is to tie any bonuses to the achievement of the overall organization as opposed to a particular department or workstream. For example, what Iâve done in the past is that there is a pool set aside for organizational achievement and then use an algorithm such that everyoneâs bonus is graded based on overall organizational achievement AND then VPs have their bonuses based mostly on organizational achievement as opposed to the achievement just of their org. Those that are in the org / department / workstream are somewhat more closely tied to their org success.
There are always tensions as you know @safder - a classic one is MQLs - SQLs - deals - NPS.
Speaking of which NPS is sometimes useful as a means to encourage a focus on building superfans and references. We would build that in as well.
