[2022-04-26] Tea Time Notes

What: Community Call
When: 2022-04-26T15:00:00Z
Who: Gaian, aia, Appt Pupil, Cadena, PostArchitekt, Dan Wu, John, Chun, Chase

Reminder: By end of week, each pod consents to the aims and domains


1. Orcanaut involvement in development efforts

Can pods be made admins of ON pods?

  • Context: Currently Chun is the admin for all ON pods, which is great for getting things done, but not ideal for the longer term.
  • Each pod is a smart contract, so another pod could be set as the admin
  • In the case of ON, it might make sense to have the source pod be the admin for ON pods.

What is dev-naut’s role in helping build out governance functionality into pods?

  • Context: Orcanauts may need better alternatives to M of N on-chain governance to reflect the off-chain agreements.
  • Early DAO projects failed because they tried to put everything on-chain, so we want to be more intentional and thoughtful about what features to attach to pods.
  • Sonar Labs refers to trustware vs socialware; trustware being tools that execute decisions with low reliance on trust; socialware being every other process or tool that does not fit the trustware description.
    • Roles within ON pods that are socialware are the delegates, for example.
    • Trustware is difficult to iterate over. It ties you to that structure or framework.
    • Socialware permits more experimentation as the org grows.
  • Sonar Labs’ thesis for on-chain governance is that governance needs to be tested out as socialware first.
    • If it does, then it becomes possible explore incorporating that process or role as a governance primitive into the existing trustware (pods)

What about governance tooling that is not on-chain? I.e., SnapShot integrations that help with ON’s governance processes

  • Integrating more tooling for pods will be important, and it’s a point of seeing what can be moved into the ON domains. This is something we can explore together.
  • Nav-naut has been involved in vetting a lot of tooling in the space, particularly ones around socialware, so might make sense for nav-naut to drive these efforts.
  • Either way, clearing up A&D will be a big step in being able to capture and leverage the enthusiasm that people enter our community with in the future.
  • Could also be a way to re-engage dev-nauts.

Where is the line drawn regarding development involvement of Orcanauts with respect to the Orca core products?

  • Development of Orca products is not strictly core protocol contracts, but could also be tools around it.
  • The tooling domains can potentially become an important ON domain as ON are in a prime position to understand and articulate what is needed to get the most out of pods in an org.
  • Regarding core contracts: limiting access can sometimes be a decision that is made with respect to security.
    • People hands on the contracts could impact code audits as well.
  • Lack of clarity around dev boundaries is that Sonar Labs was simply not quite ready to articulate what it is that community devs could work on.

What are solutions for people to vote that leads to clear calls to action? Why are volunteers not given tasks that they are volunteering to work on?

  • Context: Even if it’s off-chain, the governance “buttons” should be clear for everyone to see. There needs to be a clear interface that helps ON capture governance decisions.
  • Orgs are complex, so we might need different levels of decision making mechanisms with varying levels of complexity.
  • The lack of clear tasks for building specific tools comes back to the A&D conversation.
  • Many things before the A&D conversation ended up falling flat due to a lack of visibility on what is going on or what should be going on.
    • To facilitate this, we must first find alignment on the product and have a general agreement on A&D.
  • So it was not a conscious decision for Sonar Labs to shut down volunteering devs.
    • There simply lacked clear surface area for making these efforts happen.

Next

  • Explore ways to communicate a roadmap to Sonar Labs de-escalating domains
  • Explore ways to capturing and documenting tensions and how it’s resolved
  • Next nav-naut sync to discuss tooling convo further and set up time with dev-naut to see if they are down to take stuff on

2. Source pod and resource allocation

What is the source pod?

  • The source pod is responsible for home finding for domains.
    • It also pulls in the relevant people to have the conversation of home finding for a domain.

What pods are eligible for direct funding?

  • Context: Some pods will have domains that Sonar Labs is willing to fund directly, i.e., domains that have clear value adds to the Orca ecosystem.
  • Commissioned domains are domains that may be directly funded by Sonar Labs.
  • Noting here that the source pod would be allocating the domains across the Orca network.
    • Meaning that domains allocation and fund allocation are not totally held by one entity as the source pod holds members from both ON and SL.
  • Some domains will end up not getting funding, but people can still volunteer to work on those domains.
    • Keeping in mind that volunteering means volunteering and not banking on future payout.

How do non-commissioned (NC) domains get resources?

  • NC domains can be emergent, so to get funding, the source from which this domain emerges should be identified and approached for funding arrangements.
  • It may be important for pods to set a budget for emergent domains, so people can write proposals to that pod to get funding.
  • As a note on this, the challenge with the initial X1 budget was that everyone needed to get this ships in order at the same time.
    • With domain-based allocation, funding becomes easier and faster.

Next

  • Set up meeting for source pod only
  • For pods who do not have enough members for delegates:
    • Let’s figure it out lol

If anything is missing or inaccurate, please reply so I can correct it.

1 Like