Dev team funding

Governance
1

So. The latest passed set of votes included 3 months of funding for the dev team. Per the vote text “(this is interim funding; we likely want to fund longer based on a roadmap, but that can be a separate vote)”. So I wanted to get the ball rolling on that. There’s been a minor amount of discussion on discord.

Rough outline I’d like to get a temp check on:

  • 12 month main cadence
    • Team and pDAO communicate about roadmap + budget. Team finalizes roadmap, pDAO finalizes budget, team accepts budget or not, we go to vote, payment is one lump sum up front.
    • These discussions would look roughly like what we got around the recent roadmap discussion in May.
    • Trying to avoid micromanaging the dev team that’s served us well, while also avoiding being permanently married to this specific team forever.
  • Team MUST provide quarterly updates on the roadmap. These need not be big discussions as for the main cadence – think of them like the zoomed out version of the biweekly reports.
    • The next big roadmap and discussions can happen any time after the last scheduled quarterly update.
    • To be really explicit about a potential cadence, it could look like:
      • We decide on a Roadmap to cover a year starting October 1st
      • Team provides a quarterly update the first week of January
      • Team provides a quarterly update the first week of April
      • Team provides a quarterly update the first week of July
      • After that update, we start discussing the next roadmap. We approve a roadmap that is valid starting October 1st.

Ok. So some things we need to iron out:

  1. Is that general plan ok? If not, what would you like to see changed?
  2. Is 12 months the right cadence? The team have expressed a desire to have it be that long to prevent (a) overhead and (b) being steered by the flavor of the month tooo much. Is there interest in getting even more out of the way and doing 18 months?
  3. Were the discussions around the roadmap in May sufficient? Do we need to formalize what those look like? Does the one in May count for the initial cycle (starts September)?
  4. Are we paying the right amount? Some team input might be useful here. Would more money translate to a bigger team? Is a bigger team desirable? Would more money translate to any other advantages?
3 Likes
2

Nice work.

I don’t see any issue with twelve months. As long as pDAO can vote to shorten it in the future, 18 months seems fine as well.

3
  1. I think this is ok
  2. 12 months is good, but could there be a problem with huge fluctuations in RPL price?
  3. Yes, they were sufficient. Formalization would be good. The one in May should count.
  4. ?
4

I don’t have brass tacks backing this up but I suspect the team is a very cost efficient way to pay for dev work, compared to other mechanisms (grants/bounties, contractors, hiring other daos or even other teams).

This is due to a few facts:

  1. They are already subject matter experts, so they work at a high rate of efficiency
  2. Contractors are expensive
  3. Running grants/bounties through the full process for every single roadmap item and piecemeal deliverable has a cost to both the GMC and the person claiming the grant/bounty.
  4. They’re very, very aligned with the success of the protocol- they prioritize work and spend to that end.

Which is all to say that yes, some team input would be useful- If they feel that RPL inflows are the main factor preventing them from hiring, and they have a desire to increase staffing, we should increase those inflows, as we get very good ROI by funding the team.

1 Like
5

I am happy to give them more money for hiring from the oDAO for sure.

6
  1. This seems basically ok to me. One question I had was when is the deadline the roadmap / budget process is expected to be approved? I wouldn’t want to be on a team that found out 3 weeks (or even eight weeks) before the end of their runway whether the next year had been approved. That decision should be finalized 6 months before the end of each runway I think. Them knowing for sure that funding was there provides some more stability. Perhaps another point to get feedback on.
  2. 12 months seems fine, but see point 1, I think there should be some crossover / overlap for stability. Even if we did 18 months, as written there’s still this cliff where at least theoretically, it could end.
  3. I might not have been as keyed in at the time, but weren’t the May discussions more about getting feedback on community priorities? Is the quarterly update more status (what we did, what we’re going to do), or a roadmap building exercise?
  4. Agree, looking forward to team input.
7

As I wrote above, that discussion would start 3 months ahead of the end. I suspect it could be 2-3 weeks to do it right. Then 2 weeks of voting. So that would give 7-8 weeks of clarity. If team would prefer more, we can probably figure out how to do some of the discussion ahead of the last quarterly update, or change the updates a bit or something.

3.

I wrote up a yearly “plan roadmap with the community” and a quarterly “update community on status”. I think May was not-quite the roadmap planning I’d like to see, but a fine first foray that direction. I would’ve liked more back and forth than there was.

1 Like
8

Hey, just a heads up that we are considering this and will post a response shortly.

1 Like