Ecosystem Growth Fund - retrospective

[Discussion] EGF review

Note: you can find the original EGF proposal that passed here. We learned a lot from the deployment of the first round and would like to share details and lessons learned before proposing future work in a separate proposal.

Proposal champions

@nassar | nas#9634

Background

Purpose

The Radicle Ecosystem Growth Fund (EGF) was setup to fund initiatives that drive awareness, engagement, and adoption of the Radicle stack.

The EGF was also an experiment in DAO community contribution models. The aim being to explore ways to attract proposals from those wanting to contribute to the growth of Radicle and supporting them to productively contribute.

Approach

We worked together as a committee to develop an initial strategy to deliver on the intended objectives. The full strategy can be found here.

A brief summary of the strategy was that code collab and funding products would be supported in their launch by funding initiatives in the following categories:

  1. Growth contributors
  2. Hackathon/event sponsorships
  3. Content/media channel sponsorships
  4. Educational content sponsorships
  5. Product driven growth development
  6. Gas reimbursements

Success would be measured by number of active developers, active integrations, and TVL in drips protocol.

Contributors were educated on the project, its needs, and supported in developing a proposal and as they worked through delivery. This required a different model to top down management based orgs to ensure productive contribution. We share these lessons learned on this below.

Funded breakdown

Total: $159,892.63

Initiative lens Deliverables Total funding
Conference sponsorships Contributors attended conference, which helped them build a deeper understanding of the space and relationships that enable us to drive partnerships. A direct return is hard to assign to such activities, but it should be seen as top of funnel for partnerships. Devconnect Amsterdam and ETH permissionless. $2,629
Launcher contributors Launchers were focused on diving into specific segments of the market that they already had a depth of experience with. Their deliverables were to dive into our solution and then test the market vertical through a few rounds of conversations with leading project teams. This allowed us to speed up the process of testing positions that we believed may be interesting to a vertical. e.g. We had someone that has worked in web3 gaming firms propose a project to explore the use of Drips by different players in the stack. $15,526
Early user token rewards This proposal focused rewarding DAO teams for the work involved in being an early user and providing feedback. The aim was to onboard 50 Contributors. Build a solid list of contacts, projects, and document every interaction from discovery calls, to feedback sessions all in one place. 9 participants onboarded and completed the feedback session to be awarded RAD. The programme was cut short as the core team felt they had sufficient feedback and didn’t want to burn early adopters. $6,960
Community DAO sponsorship We funded womenbuildweb3 as a developer education and diversity focused DAO. They invested this in the onboarding and education of developers into the web3 ecosystem and incorporated Radicle tooling into their syllabus. a) Curriculum/content around building on Radicle prior the start of#30daysofweb3 to make sure people have a guide for each of the tools in our stack. b) At least 1 blog post about Radicle on the WBW3 blog shared on ourTwitter + D_D Twitter from one of the WBW3 members in the dev rel guild. c) We can organize at least 1 workshop with you and post it on WBW3 Youtube channel which we’ll also use to orient & onboard new members in the future. d) Tweet/retweet dev content for a month - Community and social media stats (engagement numbers, etc) $20,000
Marketing contributors We had product marketing and podcast contributors join to develop these initiatives. a) Launched Bear is for builders podcast series. b) Started product marketing pipeline with process for getting updates from product teams to market. c) Grow social and content marketing efforts. d) Developed messaging kits to guide marketing efforts $24,000
Developer education contributors We funded the development of a developer relations strategy. This was followed by 3 contributors that would begin educating developers on radicle and growing awareness of Radicle amongst developers with developer marketing. a) 3 pieces of content were released on hashnode. b) 2 educational videos were also developed for our YouTube channel. c) Tweets and threads were shared to grow awareness amongst developers. This initiative had the most challenges. We decided not to publish or promote the content as it wasn’t meeting the bar we felt is important at this stage of development where there isn’t much educational content. $50,700
Cohort programme contributors A group of contributors with experience in entrepreneur ecosystem building came together to develop a programme for onboarding and educating community members with peer learning. a) Design structure and infra for delivering cohort-based programme. b) Gather/Create cohort teaching material – texts and video (topics TBD). c) Begin promotion of programme to collect list of applicants prior to start of programme $27,447
  • Proposals can be found here.
  • Transactions with descriptions can be found here
  • RAD transactions can be found here

How we performed

  1. Market feedback - The early user token rewards, launcher contributors, and conference sponsorships can be categorised as initiatives that aimed to help the growth and product teams build relationships across verticals to get feedback. The feedback helped speed up the learning of teams as they worked to build and decide on verticals to focus on.
  2. Adoption KPIs - Number of active developers, active integrations, and TVL in drips protocol were the key metrics we wanted to impact. The product and protocol teams were not quite ready to meet the needs of developer users or platforms wanting to use protocols. Limited progress was made on moving these numbers in this initial round.
  3. Awareness - Community sponsorships allowed Radicle to position ourselves as being a key partner for communities that had high engagement and positive sentiment in the market. We also had contributors make proposals for developing a podcast and a product marketing function, which are now up and running and we should see the impact of these efforts moving forward.
  4. Education - A developer education strategy was developed and a team of contributors setup to deliver on it. These initiatives were the most challenging as it became clear that a higher level of technical experience was required to understand and communicate the concepts to developers. Effective developer educators are in high demand in the space and so we have been exploring different ways to approach this critical component in our proposal for next steps.
  5. Onboarding builders - We funded the development of a cohort programme with the aim of building a more supportive path for builders who want to build in our ecosystem. The strategy around this took longer to develop than expected due to changes in the strategy of core team, but we now believe it’s well focused and will be a key pillar of how we move forward in our ecosystem growth efforts.

Lessons learned and improvements

  1. Attracting contributors/proposals - During this initial phase there was a fair bit of direct outreach to those that seemed relevant and likely to be interested in taking on an initiative. As our contributor pool grows and processes get more clear we anticipate greater inbound interest in contributing to growth initiatives at Radicle. It is likely that the best contributors and initiatives would be attracted to more focused teams with clear contribution guides and so we are keen to encourage growth teams to make it easier to contribute over rely on a single fund.
  2. Vetting - Contributors had a higher failure rate than core team hires due to the desire to allow community members to make a proposal for work they want to do over hiring for a narrow role with proven experience. We believe that teams focused on one growth area would be better at vetting contributors and initiatives as well.
  3. Onboarding - Contributors need a fair bit of support as they onboard to the project. We learned that it was very important for them to understand the mission and strategy being taken by each team to serve this mission. They also need guidance from someone with enough knowledge of the project and teams in order to connect with the right people as their initiatives have dependencies on others.
  4. Accountability - Contributors need to be held accountable on a regular basis the same way core teams need to share updates on a monthly basis. We started by trying to minimise the reporting requirement for contributors, but decided that it was important for each initiative lead to contribute to a monthly community update.
  5. Off-boarding - ****Contributors that were funded didn’t always meet expectations. Initially we tried to give them time to try find their feet, but learned that we needed to minimise impact on other contributors. Again, we think by moving contributors to more focused teams would help with speeding up feedback loops when something isn’t working.
  6. Strategy alignment - It’s been hard work keeping the initiatives connected and aligned with the core development teams as changes to core strategy were implemented. If an initiative needs a high degree of strategic alignment then they should be coordinating closely within a single org. If an initiative is able to progress the ecosystem mission without needing a high degree of strategy alignment it can be funded and operate as an independent org.
  7. Committee structure - The committee contributed to our initial strategy and was very valuable to have such experienced heads as we developed this new fund. We did find that on an ongoing basis it was the other initiative leads that had stronger opinions and enough context to have help make decisions on the initiatives that we would be funding. We believe that contributors should govern the EGF moving forward and committee members should act as advisors.
  8. Confusing team lead overlap - Working as head of growth in Radicle core development team and leading the EGF was challenging and confusing. It’s best to have leads focus on delivering and reporting on one strategy.

Next steps

The EGF has been a great tool to allow us to run experiments in DAO open contribution strategies and ecosystem growth infrastructure. We learned a lot running this first round of EGF and have explored a few options for path forward.

We explored transitioning EGF to an org in the DAO where core marketing, partnerships, education, and community teams sit and coordinate. We decided that this wasn’t the best approach for two reasons. Firstly, it would significantly increase the coordination work by EGF core team and could even hamper the coordination between engineering contributors and growth focused teams. Secondly, we felt a fund across partnership, marketing, community, and education is less effective than having clear funded contribution guides for each team to attract and fund initiatives in their domain.

The areas that we found to be most interesting, challenging, and impactful in the EGF were the education focused initiatives. The core team members of EGF are also most experienced and interested in education. It became clear to us that there is a lot of opportunity and work to do and we would want to approach this in the most focused way possible. Radicle is working on hard problems, which require a collective effort greater than what we fund and develop to solve them. We need the web3 ecosystem to work collectively on shifting culture and for tooling/infra to progress to achieve our mission. So focusing on research and education allows us to build a developer and researcher community that brings mindshare into the ecosystem and creates resources for the wider web3 ecosystem to benefit from.

Transitioning

  1. We are exploring two options for transitioning the treasury
    1. We return all funds to the treasury.
    2. We roll the funds over into the proposal for the next phase of our work on ecosystem growth focused on knowledge sharing and education. Current committee would be removed as signers and replaced with new core team.
  2. We also need to decide on a plan for transitioning marketing initiatives/contributors that are currently being funded/paid by the EGF to a new org. This is being discussed with the new Head of Marketing in the core dev org.
5 Likes

Thank you so much for sharing!!! So much detail and a lot useful learnings listed here. Really excited to see where the EGF goes next! :grin:

2 Likes

Thanks for the write-up, Nassar! Good to see this all in one place.

2 Likes

Great summary Nas!

2 Likes

Hi Nassar,

Thanks for this helpful write-up. “The EGF has been a great tool to allow us to run experiments in DAO open contribution strategies and ecosystem growth infrastructure” — this is spot on. There has been a lot of experimenting, and, importantly, there are clear lessons learned that can be applied to future planning and strategy, especially when it comes to operating within a DAO framework.

To this point, I wanted to clarify some of the lessons learned and room for improvement that you covered:

  • “It is likely that the best contributors and initiatives would be attracted to more focused teams with clear contribution guides and so we are keen to encourage growth teams to make it easier to contribute over rely on a single fund.” I’m not sure what the second part of this sentence - with regards to growth teams and single fund - means exactly. What is the ideal structure (and onboarding) for attracting the best contributors?
  • “Contributors had a higher failure rate than core team hires due to the desire to allow community members to make a proposal for work they want to do over hiring for a narrow role with proven experience. We believe that teams focused on one growth area would be better at vetting contributors and initiatives as well.” What does it mean for a contributor to “fail”? Does “core team hires” refer to people hired as part of the Growth Core Team? Hiring is always hard, I can empathize. Did you have any takeaways around the best ways to vet people from the community - especially when they are new and unknown? Should we be bringing on unknown contributors for large grants?
  • “If an initiative needs a high degree of strategic alignment then they should be coordinating closely within a single org. If an initiative is able to progress the ecosystem mission without needing a high degree of strategy alignment it can be funded and operate as an independent org.” - This is a good point and an interesting observation. “Working as head of growth in Radicle core development team and leading the EGF was challenging and confusing. It’s best to have leads focus on delivering and reporting on one strategy.” Do you have general thoughts on how Orgs within the Radicle ecosystem should be scoped? And how can we clarify scope to avoid the confusion you felt in your role leading Growth (as part of a core development team) and EGF?
  • I saw several instances/mentions of the product and protocol teams not being ready for the insights gathered or work done by the EGF. Given where product and protocol teams are today, what kinds of work should be prioritized within “growth” initiatives (beyond the educational work you intend to push forward)?

It was hard from your overview to get a sense of which initiatives were most successful and which could have been done better - and the how/why. Specifically, I believe this insight is important as we transition more Radicle work to be funded by the DAO. So I’m curious to know:

  • How were initiatives reviewed by the EGF during and after the initiative’s funding period? How were the outcomes/impact measured against strategy and KPIs of the EGF?
  • What proposals (and/or contributors) were most likely to succeed?

Because “Developer education contributors” accounted for almost 1/3 the costs AND your intentions are to have developer education be a critical component in your proposal for next steps, I’d like to know a bit more about why your team “decided not to publish or promote the content as it wasn’t meeting the bar [you] felt is important at this stage of development where there isn’t much educational content.” Can you dig a bit deeper here? I feel like this was (quite literally) an inspirational effort, but there is little to show except a big price tag.

When it comes to your upcoming proposals for work in education, I’m not sure if it’s helpful but back in the Monadic days, I put together accessp2p. The participants were not technical, but I’m still happy to share outcomes from that effort.

Lastly, regarding what to do with the remaining funds, FWIW: I would be in support of transferring them back to the treasury. In the end, this return-of-funds-and-re-proposing-funds-for-another-purpose more clearly holds recipients of Treasury funds accountable to 1. the work they are supposed to do with the funds and 2. the process [temp check and beyond] for Radicle Treasury allocations.

Thanks for your patience in working through this long post :slight_smile: but I’m very much looking forward to hearing more.

2 Likes

Thank you for sharing this retrospective @nas.

I will structure my feedback around the two goals that you mentioned above. Specifically:

  1. Awareness, Adoption and Engagement of the Radicle stack
  2. Grow community contributors for Radicle

Regarding the former, there were a lot of initiatives that you all tried and a fair amount of impact and learnings, especially given the change of product strategy as well as the delays in terms of product launches. On this part, I don’t have much to add except the fact that I wish that the EGF team:

a) had proposed some methodology on how to measure awareness and
b) use that methodology to reason about progress.

I specifically mention “awareness”, knowing the constraints you all had with regards to adoption and engagement, due to the state of the tech.

With regard to the second goal (growing contributors for Radicle), by reading this retrospective, I struggled to understand the strategy that was followed. For instance you write above:

Can you share more on:

  • What was the strategy to identify who is relevant and likely?
  • How were these candidates selected?
  • What was their onboarding process to the DAO and core teams?
  • What was the plan with regard to interacting with core teams?
  • What was the plan with regard to compensation?
  • Were there any feedback sessions done with folks where things didn’t work out? Any learnings that you can share?
  • In general, what was the envisioned path from “Radicle is cool!” to becoming an active contributor within the Radicle ecosystem?

It’s quite hard for me to formulate an opinion on how valid the learnings you share are, without having a better idea of what you all tried and what not, and how the pieces fit together.

1 Like

Hey @nas! Thank you for taking the time to put together this retrospective.

I wanted to share a couple of comments & questions before we decide on next steps.

It seems like Dev Rel education initiatives & contributors were the most expensive line item on the EGF’s budget. I’m able to find a comprehensive overview of what work was proposed & scoped, but am having trouble finding the output/deliverables from the Dev Rel contributions. Could you provide a more detailed overview or point me to any documentation outlining the contributions?

Regarding the cohort programme, where could one find more documentation? If it will be an important piece of how ecosystem growth efforts are coordinated moving forward, it would be great to see more detail on what was developed over the last 6 months. After searching, I am able to find the information outlined in Radicle Cohort Programmes - #4 by RuthD post but am having trouble finding information on what work was done after that.

It’s definitely tough to navigate growth strategy within a project that is early on its path to “product-market fit”. What suggestions do you have for the emerging Core Development Org on how strategy shifts/changes can be better communicated across the DAO?

Can you say more on this? In your perspective, how will focusing teams on one growth area increase the quality of vetting?

Can you say more on why you believe education-focused initiatives are the most impactful?

As for the transition plan, I think the best path forward is to return all funds to the Treasury. While rolling over the funds is acceptable in the cases of minimal changes to structure & mandate (e.g. Grants v1 → v2), it seems like there will be substantial changes to direction of the initiative. Therefore, returning the funds and starting fresh with a fresh proposal that outlines the new mandate, scope, and strategy seems like a more appropriate next step for the EGF.

Looking forward to discussing your replies!

Hi @ange

Appreciate your thoughtful response.

By single fund I am referring to the EGF. I believe on the growth side it would be better to have marketing, education, partnerships, and community teams that have a budget for community proposals over creating a shared pool of funds. If a community member wants to contribute to a team or even request funding for an event, it would be better if they went to a more focused team with their proposal.

“core team hires” mean contributors that have been interviewed and vetted for a particular role. This is in contrast to contributors that made proposals to the EGF with their own strategy for driving growth at radicle.

Great question regarding definition of failure. Each proposal had deliverables, which were tied to particular EGF objectives. So failure took the shape of either failing to fulfil deliverables (sometimes out of no fault of their own) or failure of their strategy and proposal to make impact.

Re takeaways around the best way to vet people, I think the key takeaway on contribution proposal vetting is outlined above. I think more focused teams should vet and sponsor proposals over having a singular growth fund with a committee. It is important to note that the vast majority of contributors that worked via the EGF are very talented and experienced. I believe the challenges came from co-ordinating work with other teams and in some cases reasonable experiments that didn’t pan out as expected.

I think the main change I would make is have a leader in the radicle DAO responsible for only a single strategy. Orgs should have a clear strategy for driving the mission of the DAO that isn’t heavily dependent on other Orgs in the DAO in order to succeed. If a high degree of coordination and alignment is needed then it should be done under a single org.

The EGF did have its own strategy, but it was heavily dependent on the strategy and deliverables of the core teams and this made it hard to coordinate and left both sides feeling disempowered.

I think the core product team leads are best placed to answer this as it is heavily dependent on their product roadmap and strategy for reaching product market fit.

The minimum I think should be put in place is:

  1. A pre-release product marketing plan similar to the one pitch.com leveraged as they spent 2 years working towards a product that was public.
  2. Launchers - Product driven partnership leads on each team to ensure we are speaking to the market and either learning from their requirements or building up a waiting list prior to launch.

We had monthly updates from those working on funded initiatives where I worked to give them guidance on how to adapt based on the evolving nature of the core teams. At the end of the funding period we had a conversation to review deliverables, impact, and whether to continue. At this early stage the focus was on getting programmes working and so even where there were KPIs on a specific initiative (dev rel fund), it was the subjective assessment that was carried out by the initiative lead and myself as a retrospective.

I believe I’ve covered my thoughts on how to improve the chance of success for proposals/contributors above.

Sure. The developer relations org was setup by an experienced developer educator and the aim was to have a more community driven effort where contributors would create educational content guided by the strategy of the lead. This effort ended up not working for one key reason. The bar of expertise required to produce the quality of content required for a project as early as radicle was higher than expected and training up the contributors that wanted to work on this effort didn’t deliver the desired results. This is also a reflection of the current market for developer educators, which is very competitive and there is a significant undersupply of those with all the required skills to do this well.

As part of the review we concluded that this was the key failing and that the path forward should focus on a strategy that would take a slower approach that puts quality at its heart.

wow. this is amazing. didn’t know this existed.

Makes sense. agree

Thank you again for your thoughtful review. Hope my answers provide greater clarity.

Nas

2 Likes

Thanks for the review.

Our initial strategy was very focused on the adoption side of things and so that side was stronger. As we realised that the best way to make impact was to focus on awareness we did pivot towards prioritising this. We worked with thom who was acting as head of marketing and was also a committee member to develop a strategy and come to a methodology. You’re aware of the challenges we have had on the marketing strategy side and so I would say that depending on these things being worked out by a core team was perhaps a mistake.

Having said that, the methodology thom advised on as a starting point for growing awareness was to focus on key initiatives that would deliver content that would engage our key segments. The plan was to attract contributors, help them become productive, measure the velocity of content, and then refine as we learned more from the market.

As mentioned in my response to ange, I think this would be addressed by having more focused teams and orgs that attract and vet contributors based on their strategy.

  1. We defined the types of contributors in the EGF strategy and then identified people in the ecosystem that were doing the best work based on outputs in those categories and tried to attract them to come contribute to Radicle. If you look at the people that were funded they were all people that have done great work that fit into the expertise we were looking for in contributors. We also started by creating contributor guides, but found them to not be effective tools for onboarding.
  2. They were educated on the Radicle strategy and asked to make a proposal for how they would like to contribute with scope, deliverables, timelines, and cost. This was then reviewed by myself and in the case of more marketing focused ones, thom also reviewed.
  3. This evolved with time, but by the end it was a process of having regular check-ins to give them any information they needed as they navigated the DAO and making introduction to key teams they would be interfacing with. I think a lot more work needs to be done to improve this process as I don’t think we arrived at a perfect model.
  4. In many cases introductions were made to core teams for initiative leaders. Many of the contributors were working on the growth side and so I acted as their representative to core teams. Again, we never found a great model for this and it is something I think the whole DAO and org design should work to make better.
  5. Contributors made proposals with a request for compensation based on their market rate. In cases where this was higher than expected we negotiated, but also leaned towards accepting a higher rate given the self governed and higher risk nature of the income stream. We’ve seen similar dynamics in the grants programme.
  6. Yeah. Feedback sessions were done. The two categories of things not working out are:
    a. core org strategy shift making contributor strategy redundant/ineffective. We discussed the changes together and explored whether they could adjust direction or whether it made sense to not continue their work. People were usually pretty understanding and tried to make adjustment where possible or bow out.
    b. Failure in their proposed strategy. Again, we reviewed their work and assumptions together to understand where it went wrong and explored whether there was a better path forward or better to bow out.
  7. Radicle is cool → Understanding radicle strategy and org at a high level → understanding how EGF works → introduction to any existing contributors that would help develop strategy/proposal → making a proposal for how they would like to contribute → review and refinement of proposal → approval → introduction to key teams they would need to collaborate with.

Hope this provides greater context. Appreciate the thoughtful review.

Nas

1 Like

Hi. :wave:t5:

The main outputs you can see were posted to hashnode. 4-5 other pieces of both written and video content were created, but were never published as they did not meet the bar we set.

Yup. The latest iteration and documentation can be found under “fellowship” here.

I don’t have strong opinions on how the strategy shifts can be better communicated through the DAO. I would focus on the DAO having a mission with different DAO orgs taking different strategies for driving that mission forward without a high degree of dependence on one another.

If we breakdown the proposals based on whether they fit more into community, partnerships, marketing, and developer education it is pretty clear that a strategic leader in those areas that was working closely with core teams would be better placed to vet contributors than a generalised lower context committee that evaluates a proposal.

The committee has less insight on what works in each area and so they are more dependent on shallower signals such as the reputation of the proposer and a high level evaluation of whether their strategy seems feasible. The proposer also doesn’t have much context of the organisation when they are making a proposal and so they would benefit from someone that has the expertise to guide them on how they can productively contribute.

I believe we need to attract more developers to build in the radicle ecosystem. Having spoken to developers that would be a good fit, but aren’t contributing, there is a clear gap in knowledge of our mission, the R&D we’ve already done, and the key areas of development we are focused on. Having also spoken to those that are building as non-core members they highlight how challenging it has been to get up and running and to knowledge gaps that still remain.

I also believe that we need to attract more developer communities to leverage radicle as an open protocol based collaboration tool that they can leverage to collaborate in a way that is optimised for them whilst staying connected to a global network. There is currently very little awareness of why and how they can leverage radicle. Educating these communities to use radicle as a developer tool would help drive early growth.

agree.

Thank you for thoughtful review.

Nas

2 Likes

Thanks for the detailed accounts.

I have two pieces of feedback. First in terms of the focus, I only really saw focus on web3. I would have liked to see much greater focus on code collaboration given that most of the work of the EGF was not product work around usage, but awareness, education, and contributor growth.

Te second point of feedback is that I haven’t come across any of the output, that is alluded to. For instance, educational material or new contributors, and therefore I have to assume that nothing was worth amplifying.

I think in the future the only possible route that would make sense to me is to focus on one thing, one initiative, one strategy and have a clear plan and deliverables, and have monthly updates presenting the deliverables to the community and team. For example, if the strategy is education, then content should be created and published on a monthly basis, and shared with the team and community. If the strategy is to grow the contributor base, then perhaps bounties can be created or contributor guides. The deliverables there should be contributions to the radicle ecosystem or protocols.

1 Like

Nas, thank you for this additional thoughtful insight.

I think my biggest takeaways are:

  • By creating focused (single-strategy), autonomous initiatives with their own budgets, we can better attract experienced community members to participate and more successfully support their work. Clearly scoped initiatives are also in a better place create and measure KPIs that can be applied to the work of its participants.

  • Growth efforts - when related to particular products - should be tightly coordinated with the product team (perhaps even sit within the team). And there are minimum efforts that can be done within a product team, no matter the state of the product.

I agree that education is a very critical element that is holding back the growth and diversification of the Web3 space. It also will play a role in the general public reception/interaction and government regulation of this space as well. To mention a couple of Berlin-based initiatives, there is TE Academy and a newly launched Third Academy.

Thank you, again, Nassar, for taking the time to respond here and provide insight from your experience and experimentation.

2 Likes

Thank you for all the answers @nas and the additional context.

I agree. Something there felt broken. Commenting from my experiences with the Drips team, many times we were surprised when someone we never met before would show up stating they contribute to Radicle without having any of their work in public or without an introduction from an existing core contributor.

Reflecting on most of the above answers, I start to believe that one of the core problems we faced was the relationship between EGF & core teams and the lack of process there. My feeling is that this lack of coordination, trickled down to the way potential new contributors were onboarded and supported by core teams.