[Formal Review 🌿 ] - Radicle Grants Program [v1]

This is the official draft and Snapshot poll for the Radicle Grants Program proposal. With this post, the proposal has entered the third phase of the governance process.

Please formally review the proposal and vote in the Snapshot poll by :rotating_light:17:00 CET - Friday, November 5th :rotating_light:

Functional Description

The proposal is to start the Radicle Grants Program (RGP). The purpose of which will be to collect, assess, approve, and fund solutions to problems within the Radicle ecosystem.

In other words, the aim is to directly support open source initiatives that help grow the Radicle product, community, and the greater Free and Open Source Software (FOSS) and Web3 community at large.

Budget & Timeline

Amount: $1,000,000 (USDC)
Length: 6 months

  • Roughly 75% of the budget will be allocated to fund grant projects.
  • The remaining budget will be used to compensate committee members.

Grant funding and compensation for committee members will be controlled by the RGP’s multi-sig. As Radicle decentralizes, the budget may fall under a different group entirely and/or utilize Radicle Funding/Drips. Any new arrangements will be assessed at the end of the 6 months.

:dog2::bone: Implementation

A fundamental goal for the RGP is to dogfood Radicle in order to build a web3-wide model for sustainable software development. This comes down to 3 main uses of Radicle:

The RGP Committee will be its own Org.
Committee members will be added as members of the Org.

Grantees post work to relevant Projects within Radicle’s core codebase for assessment by Core Dev maintainers. This workflow would be handled with forks + patches with the final anchored commits acting as the “proof of work” for grantees.

Finally, once Radicle Funding is ready, RGP’s Org could pay out to grantee Orgs for their work via
Drips.

Below is a high-level diagram of the proposed framework.

Note

In the short term, I see all of these pieces being substitute-able by any combination of off-chain tools (GitHub, AirTable, etc.) in order to lower friction for grantees. However, in the long term, the goal is to get as much of this activity on-chain. This is not just for the sake of having things on-chain. It is so that the entire process is natively transparent, highly automated, and so that any learnings and pain points from the on-chain process are fed back to the Radicle product itself. We want a virtuous cycle!

Team & Responsibilities

RGP Committee

The group outlined below will act as the RGP committee and will be the signers of the RGP Org’s multi-sig. These committee members will be responsible for approving grants and distributing funding to grant projects

The Radicle Grants Committee is made up of core Radicle team members, Radicle community members, and outside individuals who have related domain expertise within the Web3 ecosystem.

Current committed members include:

We will also be reaching out to several other platforms, such as The Graph, Gitcoin, and a few others to find members from the greater web3 ecosystem.

Core Development Team

This section is independent of whether a Core Team member is on the Committee.

Any technical work (i.e. code) will be posted to the respective Project/repo. For example, if a grant project touches Radicle Upstream, the work will need to be posted to either the Radicle or GitHub repo.

It will be up to any maintainer(s) of the respective repo to review, give feedback, and ultimately approve the work.

Once the work is completed and approved, the grantee will can share the Project ID + anchored commit hash as proof of
work to the Grant Committee for final payment.

The Core Development Team may at any time join the process to give feedback or guidance on any application.

Grants Lead

As mentioned in the forums, the Radicle Governance Working Group decided it would be best to hire a Grants Lead to create and manage the RGP.

After applying, I was chosen to lead the program by the RGWP. I’ve already introduced myself a bit in the application here.

I will be responsible for the following:

  • Organizing and disseminating project ideas: this will include RFPs from core Radicle members or open applications from the community (e.g. product requests from partners or straight from individual users)
  • Building channels for recruiting applicants: this might include things like putting forth RFPs to hackathons or posting bounties on GitCoin
  • Initial screening of applications: the Grant Lead will be the first line of defence for bad applications. Committee Members and Core Dev Team members should trust that they will only have to assess candidates who have met a high bar.
  • Scheduling assessments/interviews: this will include scheduling between grant candidates and any relevant Committee Members and/or Core Dev Team
  • Planning milestones/check-ins: milestones expected to be written by the grant candidates in their application. The Grant Lead will be responsible to have regular check-ins, depending on the tier of the project (see tiers below)
  • Multi-Sig voting: the Grant Lead will communicate to relevant Committee Members when a vote for finalized work is in order.

The core goal of the Grants Lead is to build the Radicle ecosystem.

Program Structure & Process

The entire structure and process is meant to evolve over time, with the long-term goal to push as much of the work onto
Radicle.

Project Ideas

RFPs will be the main source of project ideas. RFPs can come from core Radicle members or can be written by users and other community members (e.g. a feature request that another platform’s team is keen to have). RFPs from community members must follow the same format as the format established by Radicle. They cannot be free-form. This is to ensure some level of equality when assessing multiple applicants. And the more technical details, the better. This is to ensure we have enough detail to assess an application with as little back-and-forth as possible.

We expect that in Wave 1 of the Radicle Grants Program, most RFPs will come from the core Radicle team. Over time, the line between core member based RFPs and community RFPs should blur. This will be a key part of Radicle’s progressive decentralization. Canonical RFPs will be organized within RGP’s Org in its own Project. Copies will be made available elsewhere, such as mirroring on GitHub, blog posts, etc. Budget Estimates will be made at this point.

Scope

The first grants wave will last 6 months.

Applications will be reviewed on a rolling basis. Every 2 weeks applications will be assessed by Committee Members.

Multiple teams may apply for the same grant/RFP. This has several implications. It means applicants are in competition. But Committee Members may also (a) recommend to combine teams or (b) split the RFP into sub-tasks to be divided amongst each grantee.

There will be 3 tiers to help organize and prioritize projects:

  • Tier 1
    • Target: individuals/small teams
    • Budget: < $25,000
    • Requirements: 20% of multi-sig approval
    • Time commitment from Committee members: voting pre/post, assessment of work
  • Tier 2
    • Target: small teams/start-ups
    • Budget: $25,000 - $50,000
    • Time commitment from Committee members: 1-2 interviews, voting pre/post, assessment of work
  • Tier 3
    • Target: small teams/start-ups
    • Budget: > $50,000
    • Time commitment from Committee members: 1-2 interviews, voting pre/post, assessment of work

Note: Details above are subject to change based on our experience providing grants.

Application Process

Grantees may choose from any of the application processes below. Both application processes follow the same form.

Non-Technical Applications

Location: there will be an AirTable based application.

Process: it will ask the Applicant for things like their name/pseudonym, GitHub or other previous work material, ask for a URL/name of the RFP they are applying to, or in the case of their own RFP/feature request, will ask them to fill in more details. It will also ask for details on how they plan to address the RFP’s work.

Technical Applications

This application process is recommended for anyone who wants to immediately start organizing their work with a Git client.

Location: the RGP Org will run applications through a Project called “applications.” In the example below, there is an rfps folder where all RFPs live. A standard template [template.md](http://template.md) , an RFP for Japanese localization posted by the Core Dev Team, and an RFP/application posted by a community member.

RGP-ORG
  | - applications (project)
  |  | - rfps (folder)
  |  | - | - application-template.md
  |  | - | - japanese-localization (folder)
  |  | - | - | - rfp.md
  |  | - | - | - your-application.md
  |  | - | - my-custom-application (folder)
  |  | - | - | - your-application.md

Process: to apply, Grant Applicants can fork + patch into an existing RFP’s folder or they can create their own RFP folder. In either case, the only thing an applicant should be adding is a new application file (your-application.md)

Note

In the short-term (this grant wave), Applicants may substitute this workflow with GitHub using PRs. We will mirror RFPs there. But canonical RFPs will be on Radicle.

Milestones

Milestones will either be explicitly written in the RFP and if not, should be addressed by the Grant Applicant in the application.

The purpose of milestones is to break down projects into functional components. In short, the main goal is to mitigate the risk of projects not being 100% complete. If 1 usable component is done and 2 are not, we can restart from square 2, rather than square 1. Second, the simple exercise of creating milestone components organizes the work for the grantee into manageable chunks. Lastly, milestones also help us measure the completion status of the project in a simple way.

Grant Approval

The Grant Lead is to communicate Multi-Sig voting due dates and any required secondary assessments, such as interviews.

As noted above, this will occur on every 2nd Friday for Tier 1 grants. For Tier 2/3 grants, this may be on either the 3rd or 4th Friday, subject to Committee Member availability.

In leu of synchronous interviews, Committee Members may assess applicants asynchronously by providing written questions for the applicant(s) to respond to. This must be done in a timely manner (i.e. several days prior to when the final assessment takes place).

Project Support

The Grant Lead will directly or indirectly (through other Committee Members) provide grantees with the following:

  • Feedback before/during the application process
  • Funding
  • Feedback on delivered milestones

Outside of these 3 Fs, the RGP will not be a hands-on assistance or mentorship program. We are expecting individuals and teams who are planning to own the work from start to finish.

In cases where there is close integration with the product, Grantees should expect interaction and can get details clarified and pointers via our community channels (Discord, Matrix, etc.).

Posting Work

Technical Work

Any technical work (i.e. code) must be posted as a fork + patch if done using Radicle or as a pull request (PR) if on GitHub

For example, if a grant project touches Radicle Upstream, the work will need to be posted as a patch to Radicle project or as a PR in the GitHub repo.

The maintainer(s) of the respective repo (likely Core Dev Team) will review, give feedback, and ultimately approve the work.

Grantees will use the Project ID and anchored commit as “proof of work” for final payment (see Work Approval and Payment below).

Note

In the short-term (i.e. this first grant wave) Grantees can expect some flexibility to this process. For example, we will allow you to post your final draft to GitHub for assessment. But we will still end up forking it ourselves to bring it into the Radicle Grant Program’s own Org.

Non-Technical Work

Any non-technical (i.e. non-code) work can be shared in any manner that makes sense.

For example, if the work is to write a blog post, simply sharing a link to the content and a text file will suffice. If it is a video tutorial, a link to the video and a file of the video will work.

The details for posting non-technical work will be on a case-by-case basis.

Note

All work must adhere to the following criteria:

  • All code produced during your grant must be open-sourced with proper licensing (Apache 2.0, but GPLv3, MIT or Unlicense).
  • All code must not rely on closed-sourced software or infrastructure to be fully functioning.

Work Approval

There are 3 possible approvals, initial grant approval, technical approval, and non-technical approval.

Initial Approval

All projects will go through the initial approval. This will be managed entirely by the RGP Committee. An approval in this case is any multi-sig vote on a project that reaches quorum for the initial payment (see Payment section below).

Technical Approval

Technical approval will include an assessment by relevant Core Dev Team member(s).

For example, if a grant project touches Radicle Upstream, the work will need to be posted as a patch to Radicle or as a pull request in the GitHub repo.

The maintainer(s) of the respective repo (likely Core Dev Team) will review, give feedback, and ultimately approve the work to be merged.

The RGP Committee will use this approval as the “proof of work” to disburse final funds from the multi-sig (see Payment below).

Non-Technical Approval

Technical approval will include an assessment by relevant Core Dev Team member(s).

Payment

Schedule: when a grantees application is approved 40% of the grant will be disbursed upfront to provide immediate funding to grantees. Once
the work is complete (i.e. gone through Approvals as noted above), the remaining 60% will be disbursed.

Process for Final Payment:

  • Technical work: grantees must provide the Project ID + anchored commit showing the work has been approved by a Core Dev Team maintainer. RGP Committee will then disburse funds via the multi-sig.
  • Non-technical work: grantees must share the finalized work, which will then be assessed by the RGP Committee, and funds will be disbursed via the multi-sig.

Communications

Communications will be key and made fairly uniform and consistent. The major steps where communications will be made are:

1. Grants Dissemination

As Radicle-based RFPs become available, they should be posted with their budget through the following channels:

  • Twitter + other social
  • RFP + budgets posted on GitHub, Radicle Grants Program’s repo, Blog, and the #garden channel on Discord

For community-based RFPs, they will be posted if they pass the initial screening.

2. Grant Applications

No communications by us.

But these will be naturally public due to the fork + patch workflow mentioned above (or as PRs in the mirrored repo on GitHub).

3. Grant Approvals

As grants are approved on a rolling basis,

  • Approvals of grants (per grant)
    • Added to GitHub, Radicle, Blog on rolling basis as they come in

4. Grant Completion

  • Completion of individual grant projects (per grant)
    • Twitter + other social (celebrate!)
    • Will be naturally public due to the patch workflow mentioned above

Purpose

The purpose of this entire exercise comes down to three main goals.

First and foremost is progressive decentralization. Radicle is meant to enable the decentralization of governance and contributions to free and open-source software. As a result, Radicle itself should be self-governed, self-funded, and self-built for and by the Radicle community. This also aligns with the third high-level objective of the Radicle Foundation,

Second is that the team growth of contributors will mean product growth. There is a natural limit to what the Core Dev Team can develop, so new contributors will mean more attention to more features, an improved experience for users, and more innovation. The Radicle Grants Program won’t just be a space for peripheral tasks. It will also be a part of Radicle’s own recruiting pipeline to bring on new core members.

Lastly, if we’re successful, the RGP will become a model for all DAOs. It will be a model for building self-sustaining, open source projects, DAO-funded project development, as well as DAO-to-DAO (D2D) “business”. The RGP will become a hub for sharing best practices around organizing and funding projects, as well as how best to use Radicle to drive governance and development for FOSS. It will do this in a more codified, automated, and in an on-chain way that only Radicle can do.

The RGP is also an initiative that contributes to two of the Radicle Foundation’s high level objectives for the project (see full post below):

  1. Increase the number of devs building and contributing to Radicle #grants ##progressive-decentralization

  2. Strengthen the core teams #people

Background (what is the reasoning behind the proposal?)

Radicle is currently run by a couple dozen core members.

The Radicle Grants Program will be a major towards progressive decentralization.

The reasoning behind starting a grants program is to add structure, process, and automation to the onboarding of new contributors, all of which is powered by Radicle’s software itself. This will help us put our best foot forward in decentralizing Radicle.

Link to Temperature Check

Reasoning & analysis (what is the case for the proposal? what are the pros and cons?)

Pros

  • The pros largely follow the Purpose section above
    • Progressive decentralization: almost by definition, a grants program decentralizes
    • Team growth: the RGP can become a powerful channel for attracting community contributors as well as new core members
    • Product growth: the RGP will bring in more contributions to development of Radicle, which should mean more innovation
    • Feature ideation: the RGP can be a hub for users and contributors to meet where people can share best practices, product requests, and anything else that helps the ecosystem
    • Model for DAOs: the RGP will be a model — both from a process and technological point of view — for other DAOs to adopt

Cons

  • There is a risk of projects not working out as expected

Technical implementation (who will be writing the code? what is the scope required?)

Treasury Funding

  • Amount: $1,000,000
  • Period: 6 months
  • At the end of the period, the money should be sent back to the Treasury
  • Would need someone from Core Dev Team + Treasury to implement this

At the end of the 6 months, a new grants wave must be announced, go through the normal governance process.

Execution of Grant Work

(Note: summarized from Implementation & Setup above)

The Radicle Grants Program will have its own Org, with a structure like below:

RGP-ORG
  | - applications (project)
  | - project-one (project)
  | - project-two (project)

The Org will be managed by the Grant Lead.

Grant Applicants will use the fork + patch workflow to apply for grants (i.e applications project). If applicants use an airflow application, the Grant Lead will post their application publicly to the RGP Org.

Grantees will post work to the respective Radicle Project using fork + patch or as a PR in the respective GitHub repo. Core Dev maintainers will have final say on technical work. Non-technical work will be shared in a way that makes sense for the given work.

Once work is finally approved, the RGP Committee will use voting via multi-sig to disburse funds.

Note

In cases where grantees do their work on GitHub or elsewhere, that is fine. But the final draft will be uploaded to
Radicle in the relevant Project as noted above. This is what RGP Committee members will use to determine their
multi-sig vote for funding.

Impact (how does this contribute to the long-term resilience, sustainability and/or growth of the Radicle network?)

(Note: largely covered above in the Purpose section, so summarized below)

  • Progressive decentralization: self-sustaining (community funded/community built) growth from community contributors
  • Team Growth: will become a pipeline for recruiting new core members
  • DAO model: will provide a model for others DAOs to be self-sustaining, both from a process standpoint as well as technological

Please formally review the proposal and vote in the Snapshot poll by :rotating_light:17:00 CET - Friday, November 5th :rotating_light:

5 Likes

Thank you for the write up Abbey. I am generally supportive.

I have two questions:

  1. Concerning committee member compensation, what is the rationale that you plan to apply? is it hourly rate per committee member, a fixed fee per application or something else? At first, $250k for 6 months feels quite high to me, but it’s unclear if the whole amount will be used or not. I feel that how committee members are compensated needs to be transparent for the DAO to sign off.

  2. Concerning committee composition, my feeling is that given that most work to be reviewed and considered will be technical, the majority of the committee should have an engineering background. Do you see this similarly? is that the case already with the current participants? I don’t see this is as a hard requirement, but I wanted to bring it up and see what more folks think.

4 Likes

Hi all,

The Grants Program sounds like a well-structured program that should add value to the entire Radicle community.

I am opposed to the Program in its current form due only to the amount that is being reserved to compensate committee members.

25% as a rate and $250,000 as an amount both seem far too high. It would be good to have transparency as to how that number was initially set.

  • 25%. In a sense the Grant Committee is being charged with managing the Radicle DAO’s capital. There is clear guidance in the crypto world and fiat world for how much money managers or capital managers should charge. This ranges typically between 0.50-3.00%

  • $250K. The current team is currently made up of 7 individuals. According to the above we also plan to extend the committee to “a few others”. Let’s assume 10. That would mean we are paying committee members $25K each for 6 months of work, or $50K annualized. Radicle is a global community. Global GDP per capita is $11K. US GDP per Capita is $60K.

We don’t know the scope or time reponsibility of a committee member explicitly but in the job description the Grants Lead is described as being “part-time”. I would assume that paying each committee member on average something close to US GDP per capita for part-time work is inappropriate.

Questions I have are:

  • What is the proposed compensation ratio between the Grants Lead (whose work is being funded compensated via this proposal) and the other committee members?

  • What is the plan in general for Radicle DAO related Compensation? In the traditional world Compensation Committees are an important part of best practice in corporate governance and might be useful here

  • In general many other DAOs incentivize work simply with the promise that that work would increase the value of the DAO, thereby incentivizing that work. Joining a committee and earning a title also grants prestige. Why isn’t prestige + token appreciation enough incentive? If it is not for the current committee are there are a group of qualified individuals who would be willing to work for the comittee for those two incentives alone?

Many thanks for the time to go through this

5 Likes
  1. Concerning committee member compensation, what is the rationale that you plan to apply?

A flat rate. This was determined by discussing desired ranges with several possible committee members and choosing the upper bound. The rationale for this was to make sure that people we spoke to would want to join.

  1. Concerning committee composition, my feeling is that given that most work to be reviewed and considered will be technical, the majority of the committee should have an engineering background. Do you see this similarly?

In terms of reviewing applicants:
I think a good mix of specific engineering knowledge as well as general product and ecosystem knowledge is important for assessing grants. But I would say the composition currently leans heavier towards the latter, which may not be ideal. It’s something worth adjusting.

In terms of reviewing grant work (after a grant is accepted):
One thing that was not possible was getting a Core Dev member to commit to committee responsibilities. But once a grantee is working on their project, in most cases it will mean making patches/PRs against Radicle’s repositories. In these cases, I expect Core Dev to have input.

What is the proposed compensation ratio between the Grants Lead (whose work is being funded compensated via this proposal) and the other committee members?

The compensation is the same across the board. $6250 worth of RAD per month per member, including the Grants Lead.

The rationale for this was two-fold. The amount was determined by surveying what people wanted and picking the upper bound. The equality amongst members was done because we simply don’t know how much each person will work and who will be doing more work than any other member.

Part of the Grants Program is that the entire thing ends after 6 months. I imagine this is something that would be readjusted at each new grants proposal.

What is the plan in general for Radicle DAO related Compensation? In the traditional world Compensation Committees are an important part of best practice in corporate governance and might be useful here

I completely agree with this. And it was actually discussed early on.

Creating a Compensation Committee is itself an entirely separate proposal.

So the choices here seem to be:

  1. Wait until a proposal for a Compensation Committee passes. Then build out a Grants Program.
  2. Build out a Grants Program with a simple compensation model tied to its multi-sig. With the plan being to pass the compensation off to a Compensation Committee once it is made. This would hopefully be done by the time this first Grants Program wave is finished in 6 months.
  3. Shoehorn a Compensation Committee into the same proposal as this Grant Program proposal.

#3 seemed like the worst idea. And it was a toss-up between #1 / #2. Perhaps the best order of operations is to build out a Compensation Committee first, then start building out functions/teams (e.g. Grants Program) that would be paid by that Compensation Committee.

I’d be curious to hear what you and others think on this. I’m not opposed to doing it more methodically like #1.

In general many other DAOs incentivize work simply with the promise that that work would increase the value of the DAO, thereby incentivizing that work…Why isn’t prestige + token appreciation enough incentive?

This kind of sounds like you’re saying people should work for free? Is that right?

Or it sounds like we’re assuming all members of the Grant Committee have substantial amounts of RAD. I would argue that that should not be assumed and that each member should be paid out in RAD. Once they are paid out in RAD, then your point about token appreciation starts to come into play and make sense. I’m not sure I follow this one.

Thank you for the answer @bordumb.

By flat rate you mean: x $ per month? or x $ per hour of involvement?

If the former, the problem I see is that there is no way for token holders to review which committee member is actually putting the work, so I am wondering how we will be able to learn from this process and evolve it in the second iteration of the program.

To me the most transparent way would be to have committee members keep track of how many hours they put in the program, share it with the community and then get paid per hour of involvement (either in USDC or RAD).

Then if each committee member wants to get paid the same I don’t have a strong preference as long as the total cost for the DAO is reasonable. Are there any other rates for grants programs from similar DAOs (like Uniswap, Compound etc.) that we can learn from?

1 Like

@lftherios

By flat rate you mean: x $ per month? or x $ per hour of involvement?

Flat x $ per month

But see my response just below.

If the former, the problem I see is that there is no way for token holders to review which committee member is actually putting the work, so I am wondering how we will be able to learn from this process and evolve it in the second iteration of the program.

This is a very good point.
It is a trade-off between maintenance on the part of each committee member. I’m not opposed to shifting this to an hourly rate.

Do you think such a change would require scrapping the current proposal and rewriting that portion?

I am not opposed to this in any case. Risks here are rewriting some of the proposal and possibly losing committee members due to it. But the point on transparency and learning are definitely good things in the long-term.

…share it with the community and then get paid per hour of involvement (either in USDC or RAD)

I’m not sure how I feel the flexibility around USDC here for Committee members.

I think with the actual grant work, I’d be fine paying in USDC or RAD. Grant work may be very one-off and have a temporary nature. But something feels off with letting Committee members get paid in USDC. It sort of divorces them from incentives around getting RAD to appreciate. It doesn’t align the Committee members with the long-term.

Are there any other rates for grants programs from similar DAOs (like Uniswap, Compound etc.) that we can learn from?

I will ask around.

Thank you.

I agree with you about getting paid in RAD actually. It’s much better to align incentives through the token.

Concerning scrapping the current proposal: I am not sure what’s the right path forward. I am only representing myself here and basically that was the reason why I wasn’t voting in favor of the proposal, because I felt that this part was off. If you think that my concern is significant enough then it will likely require a new proposal, but it would be good to hear more thoughts from more community members.

I’m with @lftherios here. My thoughts:

  • The grant money should mostly go to the grantees
  • A by-the-hour compensation would be more transparent and would scale up and down with the amount of applicants
  • Employing 7 people over 6 months just to review grants seems excessive: the bulk of the work should be by the grantees, not the grant committee. If there is that much work for the committee, it either means we are getting hundreds of applications per month (unlikely), or we’ve created too much process for ourselves (unnecessary).

As for creating a new proposal, it might be necessary in so far as the snapshot seems almost tied already (partly due to this reason I’m guessing, though it’s hard to tell), and we would want a much clearer signal before doing an on-chain proposal.

Nb. I’m all for a large and diverse grant committee, I just don’t expect all members to be busy at all times.

Hi All

Given the initial snapshot is completed and we’ve had a lively discussion on this page, 3 things:

1. Proposal of a restart

The snapshot is closed, but due to the somewhat even result + the excellent feedback around compensation, I’m in favor of adjusting the compensation section to fit some of the concerns people have expressed. This is mostly to prevent wasting everyone’s time with the higher risk of not passing as is.

This means creating a new temperature check, with a rewritten compensation section addressing the concerns made in the comments here.

2. Compensation

(Below is what I’m thinking for the revised compensation)

The compensation should aim to cover any work by committee members, whether it’s assessments, meetings, recruiting, or anything else in the service of the Grants Program.

The grants lead will be given a fixed rate salary of $6,250 RAD per month.

Each additional committee member will be given an hourly rate of $150 worth of RAD per hour. Members will be expected to self-report their hours each month.

At the end of each month, the multi-sig will vote to approve remuneration for each member.

This compensation framework will only exist for the 6-month duration of the Grants Program. It is our intention to move all compensation decisions to a separate committee in the near future.

3. Committee Members

We will also revise the committee member list to the following:

1 Like

Thanks for the clarification here @bordumb !

I don’t think we have to make a new Temperature Check, as it seems everyone is behind the concept of the proposal and we are just trying to figure out the details before moving it through into the final stage. I think those who contributed to this thread (@lftherios, @cloudhead, @niloconthecob) should review the revised compensation breakdown and see if it addresses their concerns. If so, I propose we create a new Snapshot poll starting Monday, November 5th with this updated Compensation breakdown.

I believe having a separate compensation multi-sig governed by a *Compensation Committee (as @niloconthecob put it) should definitely be a next step for our governance system following this proposal (and was sort of the plan). The group should focus on transparently managing compensation & contributor relationships within the Radicle Governance network.

I believe this multi-sig should be run by the Radicle Governance Working Group (and one person to represent the Radicle Foundation perhaps?) as it’s made up of the community contributors who are coordinating and facilitating most governance activities at the moment.

I’ll prioritize putting together a Temperature Check outlining this structure and we can continue the discussion next week. I believe we can keep moving the Grants Program through as long as we’re pulling our concerns around managing compensation and driving them into the discussion of this upcoming Temperature Check.

Thanks all! :wave:

1 Like

Not representing any organization here but simply sharing some personal opinions + questions that came to mind as I was reading this thread.

Are all proposals public at every stage of the process, or is the Grant Lead’s pre-screen private? If the former, can proposals (no matter their status, i.e. including proposals under assessment in their initial form) be tracked only via Github, or is there another channel through which the broader community can have visibility to what’s being considered / worked on? If the latter, I personally think the pre-screen should be highly formalized and focus only on whether the proposal meets a predefined set of basic criteria, while leaving “content assessment” to the group as a whole. The main reason to have a committee in these situations is to diversify perspectives and reduce the effects of subjective bias. On the other hand, I also think it’s essential to make sure that every proposal that comes before the group has gone through an initial quality check, esp. in terms of format/clarity.

I tend to agree. But it’s also important to include other types of expertise, partly because the process of developing technology can benefit from a more holistic assessment, and partly because - at least as I understand it - the program is open for not just technical proposals/work.

I think there’s room for making a mistake in both directions. For example, I’ve been following the progress of the Zcash Open Major Grants (ZOMG) program and something that caused a lot of problems there was a mismatch between the time commitment required from individual committee members and the initial compensation which turned out to be way too low ($500/month per member). That said, right out of the gate, without knowing how many proposals (i.e. how much work) there will be and how the tasks will be divided among committee members (incl. the administrative/operational lead), both $250k/6/7 = ~$6k/month and $150/hour per member do seem high. I’m no expert in how similar work is compensated in different geographies, but at least in the countries that I have personal experience in, these numbers are comparable to (even higher than) what many mid-level (even senior) experts earn for full time employment. That’s not to say it’s therefore not justified, but I also didn’t see a clear breakdown / relevant reference point in this thread other than the shared agreement among proposed committee members. I would caution the DAO against underpaying, but I also think it’s easier/better to start conservatively and increase compensation based on proven need (incl. during the first 6-month period, if necessary) than it is to try and figure out ex post whether people are being overpaid.

Excited to see the grants program launched!

3 Likes

It’s difficult to draw direct comparisons with other grants programs because each project/context is unique but, for what it’s worth, here are three examples:

Aragon (ended up dissolving the grants program altogether)

Zcash/ZOMG (in process of addressing various issues with the initial structure)

Balancer (learnings from the first wave of grants, incl. a short section on compensation)

2 Likes

Thank you @bordumb. Two more questions from my side:

  1. What’s the rationale for a fixed rate salary for the grants lead? vs applying the same rationale that is applied to committee members with a potentially higher rate?

  2. Concerning payment in RAD, what will be the exchange rate between RAD and USD? the exchange rate at the time of approval? the exchange rate at the end of every month? or something else.

2 Likes

Are all proposals public at every stage of the process, or is the Grant Lead’s pre-screen private?

Short answer: Yes, they will be public at every stage.

Please reference the section called “Application Process”

Specifically this note:

Note
In the short-term (this grant wave), Applicants may substitute this workflow with GitHub using PRs. We will mirror RFPs there. But canonical RFPs will be on Radicle.

All of these repositories (whether on GitHub or Radicle) are public. So if an application appears there, it is inherently a public process.

I’ll make this more explicit when rewriting.

3 Likes

Thanks all for the great discussion here. I am in favor of proceeding with a revised compensation structure and with putting into place a compensation committee

@bordumb and @lftherios i would actually suggest to resolve the discrepancy between a monthly rate for the grant lead and an hourly rate for the committee members by moving everyone to a monthly rate.

Serving on a grants committee doesn’t strike me as the type of work that should be measured by hourly productivity. They are not manufacturing widgets. As someone who manages capital full time it becomes a sort of “always on” part time job where strides are made by learning, connecting the dots, meeting new people, late night research, etc. I think if I were having to propose how many hours I “worked” I would really struggle. It’s an old fashioned paradigm. Self reporting also invites error and strange incentives.

So my proposal would be for this group to decide a fair, well-benchmarked monthly salary for the committee members and a likely higher monthly salary for the Grants Lead given the increased commitment as defined by the procedures and enhanced level of responsibility. This person probably takes the blame of the Grants money is mismanaged or falls flat and therefore that level of enhanced responsibility should be reflected.

All the salaries should reflect the fact that A. this is skilled work but B. this is also part time work.

In future I would suggest compensation levels for committees or roles should be decided before members are chosen. That way we can select for the appropriate level of talent given what we are willing to pay and this avoids the obvious conflicts of the earners themselves deciding compensation amounts. They are likely the only ones who due to inherent conflict should not be deciding the comp levels

2 Likes

@lftherios

  1. Concerning payment in RAD, what will be the exchange rate between RAD and USD? the exchange rate at the time of approval? the exchange rate at the end of every month? or something else.

End of every month.

  1. What’s the rationale for a fixed rate salary for the grants lead? vs applying the same rationale that is applied to committee members with a potentially higher rate?

Fixed rate salary for myself is out of personal preference. I would rather be paid what amounts to a retainer fee to be “always on” and not worry about hours worked. This is not something I felt like budging on.

I am not so concerned about whether a committee members end up getting paid more than me due to an hourly rate. Some of the people we have on the committee very well may bring more value than I do (I looked for people who know things I don’t know!)

I think @niloconthecob comment below on a Compensation Committee is super important. My rationale is simply my personal preference. And if that doesn’t sit well, then there is misalignment that can be solved by a Compensation Committee that makes clear guidelines for myself and others to adhere to.

@niloconthecob

As someone who manages capital full time it becomes a sort of “always on” part time job where strides are made by learning, connecting the dots, meeting new people, late night research, etc.

This is exactly what my thinking was originally. A salary is essentially a retainer fee to keep that person “always on” mentality.

If we go with hourly, I would not be surprised is many committee members (myself included) do the bare minimum of reviewing applications and showing up for votes.

In future I would suggest compensation levels for committees or roles should be decided before members are chosen.

I 100% agree with this. I don’t actually like handling finance issues. I prefer being in a position to think objectively about product building, somewhat divorced/not influenced by finances. This is why companies have finance departments.

So my proposal would be for this group to decide a fair, well-benchmarked monthly salary

How would you propose we do this?

My approach was this:

  • Think about what my time is worth (I have another job where I make about $150/hour)
  • Ask committee members what their range is ($4,000 - $6,250 per month), assuming 10 hours of work per week
  • Found that my own compensation of $150/hour more or less matches the upper end of the range from other committee members. I went with this as I like the idea of committee members being equally paid.

As I write this out, it is more and more apparent how important a Compensation Committee is.

4 Likes

Probably through: 1. Realistic calculation of time spent and 2. Cross project comparisons, incl taking inspiration from committees in traditional industries.

WRT calcs I think @cloudhead comments are relevant: a. That most of the work should be done by grantees and b. Seven people are likely too many.

10 hours per week by seven people is 303 total hours per month. That seems crazy high for the amount of capital allocated and likely application flow. It should probably involve 3 hours per week tops - max 2 hours each person reviewing the applications and 1 hour discussion, no?

Just shot in the dark but those assumptions feel more realistic. I also don’t think it’s good value for the DAO or the committee to be allocating more time to the effort. This is a test and if f the team is underwater they can bring on more resource or increase comp after tracking time spent for the next iteration.

So for 13 hours of work per month what’s the appropriate compensation? Let’s round up to 15 to account for spontaneous brain space awarded to the effort. At $150 per hour that’s $2,250 per month or $13,500 over 6 months and ~$94,500 in total. Maybe Grant Lead gets 50% higher given the increased responsibility so in total that’s $20,000 and brings total comp to $100,000 which appears to be more reasonable in terms of the DAO paying 10% to allocate its own capital.

I do not believe the above is necessarily right, but that’s probably somewhere around how I would break it down. As mentioned above crowdsourcing alternate grant committees would be great for those who have access?

A question, from a newcomer (so please excuse if this is entirely off):

A lot of the discussion above on salaries / compensation seems to be focused on how much the committee members’ (hourly/monthly) time costs.

Rather than focusing on costs, is there a way to focus that discussion around how much value their commitment to this program would be generating for Radicle (in which case, it would become much more straightforward for both sides to agree on what is “fair” compensation) ?

… just a thought …

I don’t think this is tenable.

A few high-level questions that make this approach very hard:

  • How do you define value? How do others define value? (read: it’s subjective)
  • How do you reconcile projects that finish that end up being useless versus projects that flop but would have been useful? The point here is: investing capital in experiments with a chance of failure (i.e. not providing value) is all part of the task

These 2 questions alone are why I would not advise using this approach.

The question of value is a lot easier if you’re talking about a Sales program (i.e. selling $X worth of software). But in this case, I don’t think that’s an easy thing to gauge.