[Request for Comments] What's an Org?

[abbey]

TL;DR: I think it’s a good time to reflect on our current organizational model and start a discussion to better define “Orgs” within the Radworks ecosystem. I’ve outlined my personal assumptions and listed a set of discussion questions on which I’d like other Radworks contributors’ opinions.

Hi everyone!

After two successful annual org cycles, I think it is a good time to reflect on our current organizational model and start a discussion to better define “Orgs” within the Radworks ecosystem.

This conversation has become more relevant with the recent proposals for Radicle Seed Network and Radicle Developer Tooling. As it is the first time that new Orgs have been proposed in the ecosystem since the ecosystem transitioned to the Org model, these proposals have prompted a few questions I think are important for us to reflect on as a community:

1. What’s the role of Orgs in the Radworks’ ecosystem?
2. What makes a project or team an “Org” versus a grant funded project?
3. Who gets to start new Orgs?
4. What are the current assumptions we’re making about the answers to these questions, and how are they serving or preventing us from efficient, effective collaboration towards Radworks’ purpose?
5. How do we want to define Orgs moving forward?

Why does this conversation matter? We have a tendency as an ecosystem to develop our organizational structures and processes in responses to opportunities and challenges. This is one of our strengths, but it comes with risk. When we only focus on responding in the short term, we may miss out on building for the long term health and success of the ecosystem.

When we ask ourselves the question of: What’s an Org? I’d like us to ask ourselves the question not only in response to the context of today, but also with the future in mind. “What’s an Org” is really the question of: How do we use the primitive of an “Org” to best support the successful development of technologies that support Radworks’ purpose?

NOTE: this is my personal opinion as a contributor within the Radworks ecosystem, not a formal opinion of the Strategy or Governance Committee!

Current Operating Model

In our current operating model, Orgs help organize the distinct activities, funding, and teams working on projects related to Radworks’ of funding new, resilient, permissionless technologies to cultivate internet freedom.

Since the brand evolution back in Feb 2023, we have 4 Orgs in the ecosystem:

• Radicle
• Drips
• Grants
• Foundation

All of these Orgs:

• Are funded annually by the Treasury (via governance proposal)
• Independently manage funding
• Manage their own operations (e.g. payroll, contracts etc)
• Serve the Radworks purpose and demonstrate impact (e.g. Radicle MoU, Drips MoU)

Orgs have different roles in the ecosystem:

• Building Technology: Both Radicle and Drips are building technology towards Radworks’ purpose.

• Providing Infrastructure: The Foundation and Grants provide the infrastructure to ensure Radicle, Drips, and future technologies can be built.

  • The Foundation does this by serving as the protector, nurturer, and advocate for Radworks and its technologies. It also funds the operational, governance, and strategic work necessary to drive the long-term success and functioning of the ecosystem as a whole. In simpler terms, it keeps the wheels turning!

  • Grants does this by funding development that enhances, expands, and enriches the Radworks ecosystem (e.g. integrations and tooling, alternative interfaces, and general FOSS projects). Generally, most technical grants have been focused on technology built within the Radicle and Drips ecosystems.

Based on all of this, here are the previously undefined assumptions we’ve been making about what an Org is in the Radworks ecosystem:

1. They are autonomous, while being connected to the ecosystem. They define their own vision, strategy, and roadmaps.
2. They can operate independently, managing their own payroll, hiring, and admin.
3. They are either building technology and/or providing infrastructure to support Radworks’ purpose.
4. They are generally focused on building or supporting the success of the Radicle and Drips ecosystems, specifically.
5. They have a dedicated leader(s) that has established trust and credibility in the ecosystem.

From here on, I will also refer to Radicle and Drips as our “core” technologies, as my personal assumption is that ensuring the success of both Radicle and Drips is one of Radworks’ main priorities.

Future Definition

Now, we have two new potential Orgs on the horizon: Radicle Seed Network and Radicle Developer Tooling.

• Radicle Seed Network (@lftherios): provide gateway infrastructure that makes hosting and fetching content from Radicle simple, performant, and accessible for any developer

• Radicle Developer Tooling (@yorgos): lower friction for developers who want to integrate Radicle into their existing workflows which supports easier user onboarding (i.e. quicker adoption) as well as user retention.

My personal assumption is that Radworks wants to fund these technologies because 1) they align with the Radworks’ purpose and 2) support the goals of the existing Radicle Org. But the open question is should these new technologies be funded in the same way our core technologies are funded?

Case Study: Rust

The Rust project has recently changed their governance structure. They’ve moved from a Core Team and subteam structure to a new “Leadership Council” and top-level teams. I actually see a lot of similarities with Radworks’ organizational model, and find their criteria for top-level teams to be quite helpful and relevant.

The Council establishes top-level teams via public policy decisions. In general, top-level teams should meet the following criteria:

• Have a purview that is foundational to the Rust Project
• Be the ultimate decision-makers on all aspects of that purview
• Have a purview that not is a subset of another team’s purview (that is, it must not be a subteam or similar governance structure)
• Have an open-ended purview that’s expected to continue indefinitely
• Be a currently active part of the Rust Project

If we applied this criteria to Radworks, we’d be left with the following definition:

The Council Radworks establishes top-level teams Orgs via public policy decisions governance proposals. In general, top-level teams Orgs should meet the following criteria:

• Have a purview that is foundational to the Rust Project Radworks’ purpose
• Be the ultimate decision-makers on all aspects of that purview
• Have a purview that not is a subset of another team’s Org’s purview (that is, it must not be a subteam or similar governance structure).
• Have an open-ended purview that’s expected to continue indefinitely.
• Be a currently active part of the Rust Project the Radworks ecosystem.

This seems like a clear way to structure Radworks’ funding moving forward, but if we did we would have a gap in our organizational model. New technologies within the current core protocol ecosystems play a vital role in the development of an open source ecosystem. New tools, apps, and services support adoption, increase usability, and contribute to ecosystem resilience. But if they aren’t funded as Orgs, how are they funded?

Case Study: The Graph

To capitalize on this dynamic, other protocol ecosystems often fund multiple core developers/builders to ensure sufficient decentralization, ensure long-term reliability, and increase usability. For example, the Graph funds 5+ core developers who all contribute research & development to the Graph ecosystem. These core development organizations are funded with Core Dev Grants, which are coordinated by the Graph Foundation and the Graph Council.

Since Drips and Radicle are both decentralized protocol ecosystems that benefit from client diversity and a thriving open source ecosystem (e.g. more contributors, node operators, app builders, users etc…), it would make sense for Radworks to take a similar approach and fund external development to increase the resilience of each ecosystem.

The difference between Radworks and The Graph, however, is that we have two ecosystems to fund, instead of one. More so, these ecosystems haven’t achieved product/protocol market-fit yet and aren’t considered standalone (e.g. if all funding ceased for Radicle and Drips Orgs, core development would be severely impacted/cease to exist).

Current Solution: Grants

Our current solution is (kind of) our Grants Org. The Radworks Grant Org’s goal is to fund development that enhances, expands, and enriches the Radworks ecosystem. This includes Radworks-specific third-party integrations, tooling, and alternative interfaces, as well as mission-aligned free and open-source projects.

While from a glance, this would seem like the perfect place to fund & house these non-unique new technologies, it’s become clear from discussions on the Grant Org’s last annual proposal and the current RSN proposal that Radworks’ current funding via Grants is insufficient for the type of work our core protocol ecosystems want to support & fund.

Discussion Questions

I’d like to discuss how we can iterate on Radworks’ current organizational model to:

1. Fund and proliferate new technologies within the Radicle and Drips ecosystems to support their individual adoption and paths to product/protocol-market fit.
2. Ensure sustainable and effective capital deployment that prioritizes protocol development of “core offering” (e.g. Radicle and Drips Orgs) to make sure they have enough resources to become sufficiently independent and/or self-sustaining.

To structure this discussion, I have a couple of questions that I’d pose to the community for feedback:

• What do you view as Orgs’ role in the ecosystem?
• What other characteristics do they possess that I missed?
• How do we decide on what new technologies are necessary and/or most impactful to each core Org’s path to PMF?
• What is the balance of funding that should be allocated to core development vs. ecosystem development within each of these protocol ecosystems?
• What are other ways we can fund these new technologies outside of the current Org model?
• What is the Grants Org currently lacking that keeps it from being the place to fund these new technologies?
• Do we envision Radworks funding more “core” technologies outside of Radicle and Drips?

Please share your general thoughts, ponderings, and questions. I’d like to discuss here for a week or two, then shift to an in-person call to hash out specifics and next steps.

[bordumb]

Thanks a bunch for sharing this @abbey

Through existing governance processes, especially the learnings from the latest Grants proposal for 2024, I think we’re organically inching towards something like the diagram below:

Whereby:

1. Funding comes from the left side with the Radworks Treasury
2. This funding is localized and contained for each Org. Orgs are separated not by overall product, but rather technological categories (e.g. Core Protocol vs. 3rd Party Integrations), which gives us financial containment within each team’s purview
3. Each Org has a primary set of repo(s) that they contribute to, but may cross-pollinate knowledge work amongst each other
4. All of this work across Orgs’ is surfaced as a common interface for users. Basically users should not have to worry at all about the organizational complexity and should have a more-or-less familiar experience across tooling, regardless of which Org worked on it

Anyhow, that’s my thinking after recent proposals and calls!

Happy to hear others’ opinions.

[shelb_ee]

Hey @bordumb! One important thing to clarify regarding your diagram and comments above:

Orgs are funded via the Radworks treasury/Radworks governance process, NOT by the Better Internet Foundation.

[lftherios]

Thank you for starting this conversation @abbey.

I will begin by sharing some unstructured thoughts, followed by some specific recommendations. I believe that the project is at a pivotal moment where strategy and execution matter more than ever and these conversations are really valuable.

In my opinion, Radworks today is Radicle + Drips. The Oscoin vision we set out to accomplish in 2018 had two components: sovereign code collaboration + new value flows for FOSS developers. It’s in my personal opinion as a contributor that this is still the vision that has buy-in from existing contributors and token holders. And I advocate for reinforcing our commitment to it. This is the vision of sovereign developer infrastructure. “Developer Tools. Yours. Forever.”

Reflecting on our journey, I believe that we collectively made the mistake of thinking that our problem was vision & purpose, while in fact, our problem for years had been execution (and likely too much vision). With Radicle, our tech didn’t work reliably until Heartwood! And with Drips, we made the mistake of attempting to generalize too early, instead of focusing on developers only. But we learned our lessons in 2022, worked really hard over the last two years, and now 2024 is shaping up to be an exciting year for our community.

To me, this should remain the foundation of our thinking. Anything that strategically adds to this vision (right people, right time, right risk, right reward) we should collectively consider. Our approach to strategy and fund allocation should be emergent and driven by active contributors, here on the forum. All proposals should be considered as grants and they should only be differentiated based on duration (long-term vs. short-term) and amount requested.

I think that the idea of Radworks as a funder is misleading us. Radworks is a collective of people that is almost always building and rarely funding. It’s my assumption that most of the interesting next ideas about this vision will come from existing contributors / builders.

To the topic at hand, I think that what has worked over the last two years was focus and context. With regard to that, separating the orgs was the best organizational move we could have made, as it reduced noise, created accountability, and enabled the people with the most context to make the right calls. It’s for the same reasons that I’ve been vocally against “nested” orgs in both the conversation for RSN and for the grant for the “Radicle Integrations team” and why I have previously proposed we move the governance team to its own org (instead of being nested under the Foundation).

My concrete recommendations:

1. Radworks should stand for sovereign developer infrastructure.
2. Radworks should be a collective of people that mostly build and rarely fund.
3. All proposals should be considered as grants.
4. Grants should be differentiated on their duration and amount requested. Think larger long-term grants (go to the Radworks Treasury) vs smaller fast-track grants (go to the XYZ Fast-Track committee).
5. Funding of grants related to existing long-term teams (like Radicle and Drips) should be actively evaluated and overseen by the respective Orgs.
6. For fast-track grants outside of existing teams, the process needs to be actually lightweight -i.e. Can we reduce liability for grant recipients while enabling speedy delivery of funds (and avoiding new entity creation).
7. Strategy for Radworks should be emergent. Active contributors should be the ones leading and contributing to new initiatives here on the forum.

With regards to your specific questions, these are my personal opinions below:

@abbey

• What do you view as Orgs’ role in the ecosystem?

These are long-term teams that execute towards a specific purpose that is aligned with Radworks. They are expected to fulfill their designated purpose with the resources provided.

@abbey

• How do we decide on what new technologies are necessary and/or most impactful to each core Org’s path to PMF?

I believe that existing teams possess the most context, expertise, and focus necessary to address this question effectively. Therefore, I propose empowering them to determine the course of action. At the end of the year, we can collectively assess their performance against the plan and decide whether further funding is warranted.

Regarding new ideas, I believe discussions should commence early on the forum and evolve in collaboration with the community (like this thread).

@abbey

What is the balance of funding that should be allocated to core development vs. ecosystem development within each of these protocol ecosystems?

I believe that the relevant organization should have the authority to decide and present their rationale as part of their grant application. Contributors should have the opportunity to discuss and vote on the matter accordingly.

@abbey

• What is the Grants Org currently lacking that keeps it from being the place to fund these new technologies?

In my opinion many things. See my arguments above. I think it would be healthy for us to collectively revisit it and focus it on fast-track grants for new ideas outside of Radicle or Drips.

@abbey

• Do we envision Radworks funding more “core” technologies outside of Radicle and Drips?

Yes, if the right idea is presented.

[yorgos]

Thanks for starting this discussion @abbey !

I’ve seen a lot of confusion in recent months about this, so I think an open discussion like this will be very helpful.

@abbey

All of these Orgs:

• Are funded annually by the Treasury (via governance proposal)

I would like to point out that history shows they don’t need to be funded annually by the Treasury: all orgs apart from Grants Org still had considerable remaining budget at the end of the year, meaning each team could simply apply for more funding when they are running out of funds.

@abbey

• Independently manage funding

Perhaps this is obvious to some folks, but I would like to understand this a little more: what does “independently” mean in this context, considering there are Memorandums of Understanding that impose certain constraints to how funding is managed? (e.g. “The Radicle Org will not seek additional investment from third party capital providers without consent of Radworks.” )

@abbey

• They are autonomous, while being connected to the ecosystem. They define their own vision, strategy, and roadmaps.

Similar to above, I’d like to better understand “autonomous” here. As I understand it, orgs do have a certain level of autonomy, but, from my point of view, they don’t define their own vision (they serve the Radworks vision and they have to “demonstrate impact” serving that) and since they receive funding from Radworks there are probably also other constraints.

For example, if we have any two or more teams/orgs that the Radworks community would expect to work together (e.g. Radicle Seed Network and Radicle Org, or Radicle Org and Radicle Developer Tooling, and so on), I don’t think each org can go about setting their own strategy entirely autonomously - it is always subject to Radworks community approval.

Perhaps this is what you meant with “being connected to the ecosystem” though ?

@abbey

1. Ensure sustainable and effective capital deployment that prioritizes protocol development of “core offering” (e.g. Radicle and Drips Orgs) to make sure they have enough resources to become sufficiently independent and/or self-sustaining.

Hmmm if we want them to become independent and/or self-sustaining, why does the MoU limit third-party capital?

To be clear: I am not saying we should allow third-party investments. Rather: could we perhaps better define “self-sustaining” ?

@abbey

To structure this discussion, I have a couple of questions that I’d pose to the community for feedback:

• What do you view as Orgs’ role in the ecosystem?
• What other characteristics do they possess that I missed?

I largely agree with @lftherios 's definition above.

@abbey

• How do we decide on what new technologies are necessary and/or most impactful to each core Org’s path to PMF?

I don’t think we should be focusing on technologies at this high-level. Teams/orgs can present success criteria that don’t depend on the underlying technologies and use metrics that everyone in the Radworks community can understand. For example, if enough people use some technology, funders don’t always have to understand it to judge it it’s valuable.

The teams understand the tech and they should demonstrate to the community why it’s the correct choice, by abstracting away from it in terms that funders can understand.

@abbey

• What is the balance of funding that should be allocated to core development vs. ecosystem development within each of these protocol ecosystems?

I don’t have relevant experience of “some previous case that worked well” to justify what the balance should be here. If called upon to vote, I would examine this on a case by case basis.

@abbey

• What are other ways we can fund these new technologies outside of the current Org model?
• What is the Grants Org currently lacking that keeps it from being the place to fund these new technologies?

For What It’s Worth (FWIW), The Grants Org worked well for us as Grantees. Without it, I doubt we’d have been able to contribute anywhere near as much as we have till today.

Perhaps this will take us off on a tangent, but the main pain points have mostly been around crypto payments - because not all countries allow legal entities to hold crypto. Ability to pay in FIAT would make things considerably easier. Especially taking into account that (as far as I know) other orgs also pay some of their own, long-term, contributors in FIAT, this makes even more sense for short-term contributors. Additionally, a legal entity to have as a “contractual counterpart” would have helped in our case, but I’m not sure if the situation would be any better if the grants were coming directly from the Radworks treasury…

Another way the Grants Org could be improved would be with closer ties to the other teams, through Requests for Proposals (RfP) that the orgs could write to invite grant applications, so that teams request contributions in areas where there is work left but that is beyond their current capacity / focus area.

[vanton]

Very interesting conversation, thank you @abbey

First of all I would like to add a couple of thoughts about organisational structure.

• The way an organisation is structured nurtures and helps the development of a specific culture
• It also defines the level of autonomy of the units
• And finally depicts the ability of the members to communicate and co-exist

I’ll give some examples to make it clearer.

• An hierarchical structure reveals a culture based on less responsibility to most people and more responsibility as we climb the hierarchy. Less autonomy and more “follow the rules” culture.
  A flat structure reveals a very different culture based on distributed responsibility and an autonomous groups structure a self-organized, decentralized & democratic culture. There is a vast amount of literature for the first two organisational structures and you can find more info for the latter here and here.
• I think with the previous bullet I also covered the autonomy part that I strongly believe is part of the culture of an organisation.
• Personal relationships, communication between team members and personal agendas play also a significant role to the structure of an organisation. For example there are organisation that are structured according to which members/founders/owners have the best (or worst) communication between them. Teams are created not because they need to cover a business need but because otherwise the organisation is not functional.
  So answering to your points:

@abbey

What’s the role of Orgs in the Radworks’ ecosystem?

From my point of view an Org is currently a semi-autonomy entity as it isn’t able to survive without funding coming from the community but its members decide about who, what and how they develop their part of the product.
I think it’s a model that suits Radwork’s

@abbey

How do we decide on what new technologies are necessary and/or most impactful to each core Org’s path to PMF?

I don’t see why we need to distinguish core Orgs from other Orgs. The only difference is that other Orgs’ “products” depend on core Orgs’ “products” but this is common even between companies, projects etc. Regarding technologies I think that the Orgs have the necessary expertise to choose the right ones. If we are talking about features then we need a mechanism to understand what the users really need or use and this is something that can be achieved from the Orgs that have access to the users. So I don’t see something we need to do at an organisational level.

@abbey

What is the Grants Org currently lacking that keeps it from being the place to fund these new technologies?

I agree with @yorgos and @lftherios and I would like to point out that if Grants Org was represented by a legal entity. Doing so would expedite payment processes for grantees, streamline invoicing procedures, and ensure compliance with local legislation, thereby facilitating smoother operations across different countries. Furthermore, enhancing the visibility and utilization of Radicle and Drips within communities could significantly boost Grants Org’s efficiency. This entails undertaking marketing initiatives to incentivize developers to utilize these tools and foster software development atop them.

[ange]

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:

@lftherios

Grants should be differentiated on their duration and amount requested. Think larger long-term grants (go to the Radworks Treasury) vs smaller fast-track grants (go to the XYZ Fast-Track committee).

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:

@vanton

Regarding technologies I think that the Orgs have the necessary expertise to choose the right ones.

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.

[abbey]

Thanks everyone for the super thoughtful responses! I will be process this feedback and report back with some proposed next steps in the next day or so

[abbey]

Thank you @bordumb @vanton @lftherios @ange for the comments! I really appreciate everyone’s thoughtful feedback and participation.

Here are some key takeaways I’m gathering from all the responses:

• We need a better way to differentiate grants based on their duration and amount requested. Larger, longer-term grants should have different requirements and processes than short-term, smaller scope “fast track” grants. Specifically, we need to introduce a more lightweight process for funding “fast track” grants that reduces liability for recipients while enabling speedy delivery of funds to ensure an active and productive flow of new ideas within the Radworks ecosystem.

• Instead of defining what should be an Org and what shouldn’t, we should establish clear requirements for what’s required to receive larger, longer-term grants such as:

  @ange

  • 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

• We need to revisit Radworks’ strategy and how it defines our overall organizational model so that we can focus in on a direction that is emergent and driven by active contributors. This strategy needs to be more narrow in scope than Radworks’ current purpose. It also needs to focus decision-making on active contributors, who have the context and expertise required to prioritize larger, longer-term funding within the ecosystem.

My proposal is that we zoom in on how we can restructure Radworks’ governance process and the Grants Org to be the most effective and “lightweight” vehicle for distributing “fast track” grants. I really like Ange’s line of questioning and would propose we use the questions as a starting point for a synchronous discussion. In parallel, the Governance team will sync with the Operations team and come up with a restructured list of Org requirements for larger, long-term funding that we will include in our governance documents.

To tackle the third takeaway, there is currently an active discussion about Defining a Strategy for Radworks. I suggest we continue the discussion on the forum and work to surface more defined action items that will incorporate this feedback into Radworks’ overall organizational model.

To kickstart this work, I will schedule an open one hour session next week to deep dive into the Grants Org and discuss what we believe is required for short-term smaller scope “fast track” grants. If you’d like to participate, please submit your availability below:

• Wednesday, March 13th @ 6pm CET
• Thursday, March 14th @ 4pm CET
• Thursday, March 14th @ 5pm CET
• Thursday, March 14th @ 6pm CET
• Friday, March 15th @ 3pm CET
• Friday, March 15th @ 4pm CET

Thank you all again for your contributions! Looking forward to moving this discussion forward.

[abbey]

Hi @everyone! Thank you for participating in the poll.

I will be moving forward with scheduling this call for Thursday, March 14th @ 5pm CET. I (and @lftherios) will not be able to attend the 4pm CET slot anymore due to a conflict.

I’ve made a Discord event for the session. Please be sure to add it to your calendars!

Join the Radworks Discord Server!

Looking forward to chatting!

[shelb_ee]

Hey folks! FYI I just posted notes and key takeaway from the call last week here!

Please let us know if we missed anything or needs to be adjusted!

[abbey]

Thanks for the notes @shelb_ee !