I don’t think it’s the job of a grants program to fund full-time teams.
I think we might be debating over semantics (calling them “teams”) on this one.
The long-term idea is not to be a central manager of full-time teams.
I realize this distinction is perhaps not prominent, but I want to draw attention to this sentence:
The main goal of maintaining an ecosystem grants program is to attract & onboard contributors to the Radworks ecosystem.
The idea here is to create a gradual “funnel” through which we can onboard contributors gradually.
So with the 2 grantee categories:
- New Grant Applicants: a space for brand-new grantees - who we have a lower level of trust with - to begin contributing on smaller, one-off projects
- Teams: for lack of a better term, these are “groups” who have a high level of trust within our ecosystem, currently don’t have a place on a central team or their own Org, but who can provide valuable contributions to the ecosystem. The idea is that these groups will eventually find space on a core team or their own Org.
But I have a feeling we are either somewhere on the same page or can meet in the middle if not.
Let me know what you think.
I can make this more explicit so that we have it in writing.
Before we allocate this kind of money for grants, we should determine that we’re able to get that amount of value out of a much smaller allocation. I don’t see this being the case yet.
To play devil’s advocate on this point:
Imagine you are on a call with a team interested in using Radicle. Aside from the core workings of the protocal, what are some of the first things they will be interested in?
Some of the answers to this question are in the Radicle Org’s 2024 Proposal “Objectives”:
- Improved issue management options
- Support the integration of third party CI platforms
- Implement Radicle notification system (stretch goal)
Each of these map directly to several items on the Grants Proposal:
Request for feedback
@cloudhead:
To some degree, disagreeing funding this Grants work feels like disagreeing with some crucial parts of Radicle Org’s own proposal. Clarity around the thinking here would be great.
My 2 cents
The Radicle Org is addressing the points above at the protocol level.
Nowhere in the Radicle Org’s Proposal is there mention of actually building out those 3rd party integrations.
This creates a significant gap for anyone teams we try to “sell” on Radicle.
The idea here is to fill those gaps via Grants, especially leading into and following the launch of v1.0. The aim is to make it that much easier to “sell” Radicle to teams.
In a previous life, I worked in software sales for B2B software, so somewhat analogous to what we’re building here. The first thing I would do here is give feedback to the engineering teams to make sure that these integrations are at the ready to make “selling” the software easier.
I am of the opinion that we will be missing a big opportunity to do so if we do not allocate budget to address work on 3rd party integrations.
Request for feedback
I am not likely to vote for anything beyond 250K. The product ecosystems this grants program is funding are still unproven, and the value delivered by previous grant cycles is also still to be determined.
@cloudhead:
If we are absolutely deadset on the 250K number, direct feedback that pinpoints which projects in the current proposal are most worth funding (i.e. Is it CI? Is it issues management? Is it IDE plugins? etc.)
A stack-ranked list might be best.
Your input is invaluable, so any guidance much appreciated 