@JoelCares, your intuition is correct. The best way to decentrally manage a DAO is to get broader input from the community. Broader input statistically and empirically makes for more robust plans and stronger buy-in. Stronger buy-in on better plans leads to better results.
Separating objectives from the initiatives implemented to achieve those objectives is a great way to open up the process for more input. Let the community first focus on what they want to achieve or what the problems are than need to be solved. Then allow anyone to propose initiatives that they argue will achieve the objectives. Then the community can compare them and pick the ones they think are best. This is the practice of “open strategy” and is a proven best practice.
I know @pet3rpan-1kx plans to post the final proposal soon. OBRA and the report card approach is one way but it collapses goals (objectives) and a single initiative (described as a strategy). If not designed right this can cut off members of the community from producing alternative ways to achieve the desired outcome that may be better than the standalone proposal has.
I can provide some context. While working on an updated version of OBRA based on the comments here and based on feedback from others, it became clear that there are a few dependencies to resolve before a resource allocation framework like OBRA in its current version can be functional and effective.
For instance, the legal state of SafeDAO and its relation to the Safe Ecosystem Foundation (see also here) currently limits how SafeDAO could operate through OBRA. Within the Safe team, I’m working with legal and finance on a description of the status quo to give everyone a better idea of what these dependencies are.
Also, discussing OBRA within the Safe team led to related discussions around a broader product vision that SafeDAO could choose to pursue, with lots of open questions on details and timeline. From my side, it seems that some level of detail and timeline of these discussions should be defined first, before we define an implementation framework like OBRA (which then can be optimised for a more tangible short-term roadmap on what exactly OBRA will allocate resources to).
Once these discussions reach a point when they are ready to be shared here for discussion, they will be shared here, of course. In this case, OBRA opened a bit of a rabbit hole which just takes a bit longer to get to the bottom of.
These are just my2cents. @pet3rpan-1kx and others, please correct me if I’m wrong or missed something.
I’ve requested that the core Safe DAO team first needs to define the current project direction of the DAO before being able to apply a resource allocation framework. We should understand the current objectives of the DAO first before going forth with a resource allocation system.
More formally, I propose that as a DAO, we first need to clarify the following aspects before we can implement and ratify a resource allocation framework:
Product vision – The product vision defines an aspirational end state of a product. It defines what the product will achieve and the value propositions for end users and serves as an anchor point for how we assess the funding of new features, functionality, and products. We should look to establish a product vision based on an understanding of end-user needs and the market landscape. While ideally, we want to set a single canonical product vision, there may also be several product visions we may want to consider, explore or attempt to validate. Nonetheless, they should be initially defined first as a starting point. A product vision establishes the necessary clarity around Safe DAO’s motivations (the ‘WHY’) around tactical goals and surrounding strategy.
Product goals – These are specific tactical objectives that help achieve Safe DAO’s product vision. Goals should acknowledge the constraints of our available resources and the existing position/state of Safe DAO. With each product vision, there will be its own respective product goals that are nested under each. Product goals allow us to understand what we need to accomplish immediately (the ‘WHAT’). While typically product goals generally are coupled with a strategy on how to execute them, we want to enable the community to participate in bottoms-up ideation on the ‘HOW’ via OBRA. We expect many of OBRA’s strategy proposals to revolve around our established defined product goals.
Product metrics – Product metrics are data points that allow us to establish a picture of the current, past, and future state of Safe DAO’s progress toward goals and its product vision. Metrics aim to guide and inform, not necessarily be optimized at all times. A single metric alone will not provide the full state of reality, nor will a full set of metrics achieve that. Metrics should always be understood via the lens of qualitative assessment. Our initiative proposals should be measured against product metrics as much as possible.
We want to ensure a resource allocation framework supports the execution of the community’s outcomes, goals, and direction as opposed to working against it.
Hey! I’m new here, but after reading through it a few times this looks very promising, I’d love to learn how this works in practice. Thank you for putting this together, along with the governance references.
Perhaps I didn’t look hard enough, but does this say anything about what membership model(s) should be used / could fit well with this? How would one become a member or delegate and gain reputation in this model (if at all)?
All initiatives are funded by streamed payments via a tool such as superfluid or sablier unless the sum of funds is < $10,000
You could add substake.fi to the streaming payment options here.
DAO would park some ETH in a substake vault. It uses stETH to generate yield. The initiative can only claim that yield. DAO can pull back the full deposit any time. So it actually doesn’t cost anything to the DAO to fund the initiative.
For people like me looking to see progress on this SEP, Please know that a new thread has been opened for this proposal which serves as a revised version
