Minimum Viable Resource Allocation Framework [DRAFT]

This is a copy of the Resource Allocation Framework shared in the Community Call.

The goal of this post is to have a super basic concept for resource allocation that we can collaborate together on. This is by no means set in stone or the perfect approach, but wanted to get something on paper so we can start having more tactical discussions.

Goal: create a minimum viable framework for resource allocation throughout Orca.

Note: “Resources” in this context refers to assets used to fund initiatives.

Design Principles

  1. Amount of funds allocated to a given pod is determined by the domains a pod takes on and the budget allocated to each domain
  2. Funding is distributed to pods that have responsibility over a given set of domains
  3. Source Pod is responsible for consenting to the allocation of resources across pods

Commissioned Domains

Domains that have a pre-allocated budget.

Note: today, that means funded by Sonar Labs – in the future, this could mean a pre-allocated budget from the Orca treasury more broadly or from external parties.

Non-commissioned Domains

Domains that do not have a pre-allocated budget.

Note: non-commissioned domains can become commissioned domains with consent from the Source Pod. See “Review of Non-commissioned Domains” for details.

Funding Process

Request for Funding

Requesting a commissioned domain requires (at minimum):

  1. Clearly articulated domain
  2. Pod taking on the domain
  3. Proposed budget for domain
  4. Source of funds
  5. What does success look like?
  6. Committed individual(s) who are responsible for stewardship of the domain

The Source Pod consents to commissioned domains quarterly and holds special meetings for processing funding of non-commissioned domains.

Quarterly Resource Allocation

The Source Pod meets quarterly to consent to commissioned domains. The process for consenting to domains is as follows:

  1. Each pod is responsible for submitting unique request for funding (see Request for Funding) for each domain they wish to work on for the next quarter
  2. The Source Pod holds one meeting with two brief rounds for each domain’s request for funding
    a. Question round – Source Pod members ask clarifying questions about each domain’s request for funding
    b. Feedback round – Source Pod members give initial thoughts on each domain’s request for funding
  3. One week period where authors of the request for funding have the opportunity to incorporate feedback and clarifications, if necessary
  4. The Source Pod holds final meeting to consent to each domain’s request for funding

Special Meetings for Non-commissioned Domains

For domains that are not commissioned, any Orcanaut or Cadet may request a Review of Non-commissioned Domains. This request asks that the Source Pod discuss the commissioning of a domain that currently exists as a non-commissioned domain or a domain that has yet to be created but that requires funding.

The process is as follows:

  1. Submit a request for funding (see Request for Funding) for the domain that is requesting funding
  2. The Source Pod holds one meeting with two brief rounds for the domain’s request for funding
    a. Question round – Source Pod members ask clarifying questions about the domain’s request for funding
    b. Feedback round – Source Pod members give initial thoughts on the domain’s request for funding
  3. One week period where author of the request for funding has the opportunity to incorporate feedback and clarifications, if necessary
  4. The Source Pod holds final meeting to consent to the domain’s request for funding

Open Questions

Questions from Community Call

Question from @Appt_Pupil: who can submit these requests?

  • Pupil: keeping it more open probably makes sense – a good idea can come from anybody
  • Post: commitment for someone requesting funds should probably

Question from @aia: how do we compensate pod leads, facilitators, etc?

  • Chase: build the budget for these roles into domain budgets and give pods autonomy to distribute as they see fit

Future Questions (going unanswered in the minimum viable structure)

  1. How do we handle external funding of projects? Does the Source Pod need to consent to a pod taking on funding from an external source (non-Sonar Labs)? What if it gives rise to a new domain?
  2. If a given pod makes a profit (i.e., doing consulting work for an external organization), do they share that revenue? What happens if you get funding from the treasury, for example (i.e., is it a grant or a loan)?
  3. Do we have a finder’s fee? How do we think about the people who aren’t doing the work directly, but are supporting the work?
  4. How do we think about the retro process? What could this look like?
  5. How do we handle tokens from other communities? Who holds those tokens?
4 Likes

I have an objection to including item 2 in the request minimum. As @aia and I discussed in the chat during the Friday 13 May community call, there are benefits and drawbacks to requiring a pod be specified at the time of request.

I don’t currently feel the benefits of including this outweigh the potential drawbacks of discouraging proposals that may not fit with the pod structure. The pod structure, like all categorization structures, tends to encourage things that fit well with the structure and discourage things that do not. Thus, requiring definition of a pod will tend to discourage the taking on of domains that do not fit our pod structure. Our goal with proposals is not to perpetuate our pod structure - our goal is to get the proposals that will best help DAOs achieve their full potential funded.

Therefore, I recommend that we make this optional to start with. We can revisit this as needed in case we are getting too many low-quality proposals because we are not requiring this.

6 Likes

Thank you @chase , for taking the time to write this up.
Overall, this makes a lot of sense to me.

Was there supposed to be more here?

I appreciate the distinction you are making.
I’m wondering about the implications of the relationship between pod and domain that this implies.
In terms of order of operations,
does the domain get approved and then we would see if it fits into an existing pod.
If it does not, then we would start up a new pod for it? Or might it remain podless for some time?

2 Likes

That is how I would think about it. If the Source Pod is reviewing a proposed domain or idea and thinks it is the right thing to do for the Orca ecosystem, it would then determine whether this would go into an existing pod or if we would create a new one (and who would be involved).

For instance, let’s assume we have an idea for creating a new type of NFT that would have some utility in a pod, but is also intended to have aesthetic appeal for investory types. In that case, we would likely spin up a pod for the project sourced from art-naut and dev-naut members. We might decide that upon completion, we would dissolve the pod and transition ongoing work into existing pods, or the new pod may be responsible for it going forward.

4 Likes

Makes sense.

Isn’t this exactly what “Home Finding”, one of the Source Pods explicit domains is exactly about?

1 Like

As usual @aia, you have found the heart of the matter. Thank you!

1 Like

This totally makes sense to me!

I like the idea of intentionally separating the resource allocation decision for a given domain from where that domain actually lives. I think in resource allocation decisions in particular, keeping things super modular and flexible is ideal. Otherwise these types of things can go on forever.

So I’m in agreement here!

I also want to acknowledge that, to @aia’s point, the Source Pod is also responsible for Home Finding. So ultimately, the Source Pod is still making a decision on where that domain lives, but that is a separate decision from whether to fund a given domain.

2 Likes

I agree pod is optional and ultimately up to Source Pod to determine where this domain/project lives.

I agree we should err on the side of openness as to who can submit proposals. If they temp check, as is our norm, we can weed out requests that don’t fit Orca or help improve them before they get on the source pod agenda. Can add more requirements if that becomes an overwhelming problem.

2 Likes