Visualization of the budget draft above. I intend to post these under each budget and keep them updated as proposals incorporate feedback and changes. Please reach out if you have any questions or input.
Hey @Fred, why does the prev seasons budget ask chart, show, ~$80k as s15 ask? It should be ~$260k right?
The Budget ask + Reserves ask is $260,353 (the light green line in the graph).
Reserve ask is $180,000
Budget ask (without reserves) is therefore $80,353.
i.e if the workstreams would not ask for 60day reserves the budget ask would be $80,353.
The projected spend can be found just under the Objectives; $406,254
Okay i think there is some confusion here across the board and i will breakdown the numbers to hopefully make it make sense.
Our projected spend for S15 is $406,254… This is not inclusive of reserves as that is not a projected spend.
Here is a breakdown that might clarify this all for you (same table in the proposal):
We had a good call today with Chase. One of the items we discussed was reducing the budget for salary on the new hire by 1 months pay given that they likely wouldn’t be recruited and starting until September at the earliest. Chase was in agreement and is going to make that reduction in the requested budget. Thanks for a good job Chase!
Echoing Anne’s comment, great call with Chase this week.
Overall the budget is very thorough, the feedback process has been great, and Chase and Moonshot are doing all the right things to be good stewards of the DAO funding they are requesting to fulfill their mandate. I’m fully supportive of their budget and the process thus far.
As a take-away from our feedback session, the stewards on the call highlighted that the Moonshot work is experimental and likely to take more than a single quarter to realize value. To help map that longer value delivery onto the quarterly budget cycle, we discussed the benefit of having Moonshot provide a broader context for their work, including more venture-oriented metrics to anchor their experiments around aspirational value generation (TAM, TVL, etc.). We recommended that the budget is updated to include a commitment to build this context documentation in S15 and to provide that context going forward starting with their S16 budget proposal.
Overall feels like a credible proposal that reflects a tightened focus on essential intents AND on the needs we are uncovering from partners, i.e. Optimism.
It is a pretty familiar pattern to see “solution engineering” teams build hand in hand w/ partners software that may or may not end up being applicable beyond that partner or customer. As such I think the name and image of “Moonshot” may understate your value somewhat because at least in my experience - solution engineering or similar roles such as DevRel as you mention - are fundamental. They both make big customers successful and often get to build the first versions of innovative stuff.
That leads to an actual question - do we have bandwidth for the next Optimism? Do we anticipate a similar effort to add capabilities for the next large partner or end user?
Also - is Optimism contributing to the code as well? If so, how are we managing that collaboration? Is there a shared open source backlog I guess and a workflow for design review and so on?
One cautionary tale from open source is that sometimes we can crowd out potential contributors because we don’t have time to wait for them to get up to speed. ne thing we did in the past is we “metriced” teams based on issues that they opened that a non-employee picked up. The goal here is to align everyone to do the extra work to leave clear footprints so the community can really take off. Are we ready for explicit “community contribution” metrics? As you know there are a legion of them projects look at of course such as new contributors, contributor activity, and quality of contributor activity.
A couple of final questions:
- is the plan that MACI is handed off to GPC? if so, when?
- are we able to track which issues result in non Gitcoin PRs?
- why 2 PMs? I’ve seen PMs able to handle 2 small teams, and these are small teams (i.e. only 2 devs). Do you need 2 PMs for 4 engineers?
- in your role as first customer shipped & DevRel - is there any overlap w/ others in Gitcoin? Do we have devrel engineers elsewhere helping contributors & users get up and running, close their first issue, and so on? I’m not assuming it would or should sit in Moonshot.
- could you metric what success looks like in your role as first customer shipped?
Anyway, very exciting evolution of your role and congratulations on your collaboration and innovation.
Sharing the appreciation for the great call with Chase last week. Though the proposal itself is clearly written, the opportunity to dive a little deeper is always helpful.
Overall, I think the Moonshot S15 budget is lean and that its focus on composable modules that support G2.0 is the right direction. Something I appreciate about Moonshot, is the team’s nimble decision making – the most recent example being pausing modular conviction voting prototyping in favor of more essential work. I hope to see more workstreams demonstrate this way of thinking in S15.
My one hangup is the need for a new Sr. PM/Co-Workstream Lead hire. During our call, Chase explained that this hire would compliment the skills already existing on the team. In the grand scheme, this is a relatively minor seasonal cost at around 6% of the overall budget, but it’s also unclear whether Moonshot will find that person this season or if they’ve explored other ways of solving this problem outside of a direct new hire. Which raises another concern. Though I respect the strong stewardship over the DAO’s treasury with the conservative budgeting of this line, I’m concerned that Moonshot won’t actually find the profile of candidate they’re looking with what’s budgeted. The current U.S. average for this role is around $145k vs. the annualized $97k budgeted. DAO Ops just went through a similar exercise where the level of experience we needed didn’t align with what we budgeted for the Treasury Lead role. Ultimately, with @kyle’s support, we found other ways to make good on our S14 commitments to the DAO, but it was a lessoned learned, so I share it here (and hope I’m proven wrong) .
I’ll end by saying, I’m looking forward to seeing all that this lean, mean team accomplishes in S15 and beyond.
Moonshot has taken the feedback from stewards and have integrated the following feedback:
- Updating hiring budget for only 2 months of budget for the person to be hired rather than 3 full months. This was due to the fact that we wont be able to hire this person until September at the earliest. Dropping the budget by ~12k
- Expanded on the person to be hired to highlight what skillsets and experience we are looking for
- Included a commitment in the Season 15 goals section to highlight MC documenting and sharing a longer term vision that can be used for broader alignment on these quarterly budgets
With that said, this proposal has now moved to “INTEGRATED” and still open for all the feedback in its state!
Thank you for the detailed response and questions regarding our S15 budget! I think you raise fair points and actually highlighted a lot of the value Moonshot looks to add in the coming season. Below i have answered some of your more specific questions and feedback items.
Our capacity to start will be used in working on Quadratic Voting which will be important to Optimism and other partners that want utilize Quadratic Voting while running their grants rounds. So, we wont have the capacity immediately to take on the next module for a key partner. With that said, we expect to stay close to GPC and build a prioritized backlog of valuable work GPC learns about through their design partner research. This work will feed the two teams as they complete these initiatives and expect similar level of efforts for composable modules.
So in season 14, the partnership with them was focused on an experiment for Retroactive Public Goods funding. The code that was contributed for that was Moonshot (contract and requirement gathering), GPC (round manager and grants hub contracts and front end), and Optimism (front end and decision making). This work was done via separate backlogs, but shared processes for review and requirement gathering via weekly synchs between all key stakeholders. In Season 15, it will only be Moonshot contributing to the code for Quadratic Voting. Wight feedback loops coming from Optimism to help drive the proper solution.
I think for Season 15 it may be a bit early for that as we are focusing on running lean to deliver these modules that are important to our essential intents (protocol adoption + GTC Utility). You are highlighting our long term vision for MC, and I expect season 16 we may be more ripe for explicit community contribution metrics.
Yes this is the plan, and we will be working closely with them throughout the initiative to ensure a smooth hand off. The handoff will happen once the code is complete and meets the needs of GPC and the key partners. Hopefully by season end.
Could you expand on this ask, specifically the non gitcoin PRs? are you referring to issues that related to the work that we may have done with Optimism?
This is a fine question, and don’t necessarily agree that PM’s could handle 2 small teams. I am acting as the other PM, and while acting as the WS lead I assume many responsibilities outside of a day to day PM. So, @brent is the only full time PM and will autonomously work with the other initiative team. 1 person couldn’t fulfill the needs of a PM on 2 teams and do the work required to keep the workstream running successfully.
We do not have DevRel hired anywhere yet, but GPC is planning on hiring and owning that per their S15 budget. Since we are the first community building on the protocols we can help frontrun that and implement best practices ensuring they can hit the ground running. I.e. Ensuring the protocols are approachable.
This is an interesting one and we absolutely plan on defining what success looks like/key KPI’s. At the end of the day we want to provide GPC meaningful feedback on the community facing documentation to ensure protocols can be approached easily. That will be done by consuming the documentation and SDK’s as a third party community, but having a tight feedback loop so those things can be iterated on. So quality of the documentation and SDK’s is where we will look to this season. The real success comes from the success of the communities building on the protocols and consuming documentation, but we wont get to realize that until future seasons.
Thank you again for all the thought provoking feedback and questions. I hope this resonates with you and am happy to answer anything else that may arise.
Thank you for the valuable feedback, and raising your concerns and questions. I hope the below response helps clarify some of your concerns.
Our goal is to find this person this season, hopefully by September, but we understand this is a big goal. We will be using our community of trusted contributors to help fill this pipeline with the hope of expediting the process. We will also explore other alternatives like finding someone internally or sourcing the work through composable scopes of work.
With that being said, we have updated the budget to reflect 2 months of salary rather than a full 3 months. So with that consideration that actually meets the US average of 145k /year for this role.
If there is any surplus due to the longevity of the hiring/sourcing cycle, that surplus will be used for future seasons budget.
I hope that addresses your questions and concerns, and am happy to continue the conversation if needed!
I am likely biased after working so closely with the team, I want to name that upfront. I do feel this statement from Olsen is accurate.
Having Moonshot collective slowdown (only two initiatives) to go fast (ramp up on the protocols) will be critical in S15. I appreciate that there has been a focus on the most important items to tackle, without a large swing on the priority list. Said differently, much of the items that were important are still important, we are just going to pace ourselves in accomplishing them given the protocol timing and support capabilities.
I am supportive of the budget and I hope to help hire the folks sought to join this great team.
I have not reviewed this budget in-depth on the forum, but I’ve read the positive reviews by the other Stewards under this proposal, and I’ve also read the initial proposal during the CSDO planning meetings. Based on this I will vote yes on this proposal.
Great to see this proposal evolve after the review session with the stewards assigned. Having spoken to @Jodi_GitcoinDAO and @anneconnelly after the review - I was fully in agreement re hiring and glad to see the revision made on role planning. I am comfortable voting to approve this budget as detailed in this INTEGRATED proposal.
Our S15 budget proposal is live on Snapshot
Please cast your votes before 20 August at 17:30 (ET).
Thanks your time and feedback!
I’m supportive of this request because of the great work @brent and team did launching Passport and passing it over to GPC to maintain and the importance of the Optimism partnership. I do think the new salaries from Gitcoin Holdings inform my decision too. I’d like to see this workstream develop better metrics around the rate they take in new ideas, validate potential, prototype, and build MVPs in future seasons.
I’m happy to see MC lead the charge on adopting Grants 2.0! It seems that we’re betting on token utility to come from staking mechanisms and there have been quite a few thoughts scattered across the forums (1, 2, 3, 4)
To sum it up and to help frame some of my queries, utility comes from:
- Staking GTC through the form of conviction voting
- Governance in DAOs (also beyond Gitcoin)
Utility is important because:
- It will reflect demand to be a part of Gitcoin’s network
- It provides some buy pressure on the token
However, this is a long term idea with really no way of knowing it will work out + we’re betting the entire DAO on this. I’ve noticed that there hasn’t been a discussion of revenue and prior discussions have been seen as defecting (a spicy question as @tigress nicely put it) though I do share the sentiment that revenue is important to keep the DAO going.
The DARPA execution framework boils down to showing that a vision is not impossible, showing that vision is possible, and then making it exist
To do that, having a fixed budget for ‘seedling’ projects to explore multiple pathways, having a highly technical team to scrutinise proposals, acid testing ideas, and cross-pollinating across the ecosystem is how they achieve it.
I hope this isn’t too drastic, but @GTChase you could also consider framing MC as a collection of DARPA program managers that are experimenting with the idea that a token-based network could help fund public goods across ecosystems.
However, I do agree with the budget for S15 to experiment with these 2 initial these put forth and would like to suggest some ways to speed it up.
Firstly CLR Fund has an open source repo including elements of MACI, quadratic voting etc that we could adapt. I would suggest having a conversation with them to include that as a module and then start experiments from there.
Secondly, perhaps starting some conversations about token utility so that we can frame reasonable experiments would be great. Token utility is a problem that every DAO faces so perhaps a coalition to tackle these efforts would be good rather than Gitcoin shouldering the entire burden (or resorting to ponzinomics). Some programs here 1, 2.
I am supportive of this budget given the positive comments reflected here and my first-hand experience of working with the MC team on the Grants 2.0 work. I think this plan reflects a strong focus and I look forward to working with Moonshot in S15.
I’m supportive of this budget after reviewing it at a high level and seeing the positive comments from stewards especially those who worked closely with the workstream on feedback.
I’m supportive of this budget and will be voting yes.
In my S14 voter guide, I wrote: “As we crisp up the DAO’s Purpose & Essential Intent throughout Season 14, I am cognizant of MSC and its place in the DAO - and as we move to becoming a Protocol DAO, it’ll be increasingly important that MSC continues to drive towards outcomes that serve the DAO-wide purpose”
I am encouraged since then by the leadership & diligence of MSC in adding more structure to their efforts and focusing on protocol & protocol-adjacent work over the past 3 months, while still maintaining an experimental, fast-paced innovation hub vibe.
One thing I do hope to see in S15 is closer MC <> PGF <> GPC collaboration. I think we sowed the seeds for this in S14 with some great dialogue, and I’d love for us to bring some more structure & proactiveness to how these groups collaborate looking ahead.