Hi all,
@abbey , thank you for getting this started - and @bordumb , @lftherios , @yorgos , and @vanton for your input!
“What is an Org?” - In short, an Org is a vehicle for funding work that is aligned with (or in support of) Radworks.
In order to define whether work “is aligned with Radworks” and how an Org can support Radworks in getting that work done, I agree with @lftherios that we need to agree on a scope for Radworks that is more narrow than its current purpose. If we agree that Radworks, for now, is Radicle and Drips (or “sovereign developer infrastructure”), then the question becomes, how do we define structures (vehicles) that enable idea and value flow in support of Drips and Radicle?
Currently, both the “Org” structure and, specifically, Grants Org have been parts to this answer. And I believe that we can improve and further detail how these structures are used to fund different ideas - while keeping the “rules” simple and accessible to idea authors. In general, one thing I believe we’ve learned (a couple times) over the last few years is that complex processes, terminology, or operations are hard to adopt and not very sustainable. Especially when the Radworks community is still in its early stages and when a majority of our users/contributors/community members are engineers 
So I tend to like Ele’s suggestion:
An Org could represent the path for larger, longer-term grants from the Radworks Treasury. Proposals to the Treasury are part of a month-long review cycle, which includes community evaluation. I agree with @yorgos that answering what technologies should be funded by Radworks, in support of Radicle and Drips (or “sovereign developer infrastructure”), should (for now) be a decision left up to the community. The onus is on the proposal authors to prove to the community that what they want to build is worth funding. Authors of these [Org] proposals, to be awarded funding, will likely have to be trusted, existing contributors. I don’t believe that we need to define Org to its absolute fullest extent, largely because it will need to adapt based on the further maturation (of structure, vision, products) within the Radworks community. The main objective, for me, in defining an “Org” would be to establish requirements for:
- Security of funds received from Radworks, ensuring that funds are safely held by Org Leads and trusted wallet co-signers.
- For example, ensuring the receiving wallet uses at least a ⅗ signer threshold.
- Accountability about the use of funds from Radworks, ensuring that funds are being used as outlined in the funded proposal by (for example)
- Publishing monthly financial reporting to community.radworks.org
- Reporting on progress at quarterly Radworks Community Calls
- Committing to a Radworks software licensing strategy
Outside of these technical and procedural requirements, I believe it should be up to the community to prioritize what is funded via a governance vote.
But this kind of proposal cycle and reporting might not make sense for a week-long project to create a deliverable or offsite in support of the Radworks vision. Or a contribution from a new Radicle enthusiast who wants to build-out some new feature. So what kind of funding does Radworks provide for (potentially new) contributors for new, smaller or shorter-term or narrowly defined contributions that support Radicle or Drips or the ecosystem around them? And where does it come from?
The Grants Org could facilitate this evaluation and value flow, but I think there are some key questions about this vehicle that we need to clarify if we want this vehicle to provide a more “lightweight” solution for grant disbursement in comparison to Orgs:
- Should the disbursement of funds be “quick” in comparison to Org funding? If yes, how would the Grants Org be set-up to facilitate quick turn around of funds?
- Do we need to have a maximum grant amount awarded to a proposal via the Grants Org? What “risk” would this mitigate? Would this enable quicker disbursement of funds - and enable quicker execution of the proposed project? Side note: If we see a fast-track review as increasing the risk of less critical review of the proposal and its team, then we increase the risk of funds not being used most effectively or successfully to solve the problem they were granted for.
- Does the current grant application template facilitate quick facilitation? Does the grant application template ask for work/preparation that is proportional to the amount of the grant? The same question goes for evaluation or reporting on the end result of the funded work.
- When are grant application reviewers expected to review applications and on what timeline? Do all “grant application reviewers” (more on that below) need to review every application and is this work for reviewers proportional to the amount of the grant?
- Can we offer great operational clarity (if desired by grant application authors) for receipt of funds? [see input from @vanton and @yorgos, this is also something I’m starting to think through with @wendy]
- Should this kind of grant vehicle also retroactively fund work that’s been partially bootstrapped already?
One larger question remains with regard to this solution for smaller, “lightweight” grants: who is most appropriate for reviewing the incoming grant applications? What kind of skill sets do we require within this group of reviewers?
I agree with @vanton:
While the broader community is involved with the more lengthy review of higher-value grant proposals, Radicle and Drips Orgs can be used to quickly evaluate the impact of lower-value grant proposals to fund new contributions that enrich their respective ecosystems. The Radicle Org Lead or Drips Org Lead would be best positioned to answer: does the proposal’s cost accurately reflect the value and impact of this new technology/contribution?
Furthermore, there is the question of: how do we proactively identify and fund work that support specific needs of Radicle or Drips? If we assume that most of the grant applications will come from existing contributors (as Ele projects), then maybe we don’t need to prioritize now creating this pipeline for proactively identifying work that would support Radicle or Drips, as existing contributors know deeply the needs of these products. But as we clarify this value flow within the Radworks ecosystem, I think the anticipation of this proactive identification of work that needs to be done should inform our thinking.
Another side note: I think the designation of core vs non-core technologies is not very productive; not only is this terminology caught up in previous iterations of the project but I’m not sure this designation solves a real problem - again, at this point in time.