summary

I've been onboarding a bunch of orgs using this tutorial and Abbey and I put together. The product teams have asked for a synthesis of issues that have been raised whilst teams try to onboard. This document aims to capture the issues broken down by step in the onboarding journey

1. Create your Radicle identity

  1. The first step is having a wallet with ETH in it that will also be a signatory for the devDAO gnosis safe. This turns out to be a fairly challenging exercise as I'm speaking to a devrel, community lead, or grants lead. They need to think about governance and this requires co-ordination. they need to get funds into the wallet, which also requires coordination.
  2. I often tell them to skip the id connection part as it costs gas

2. Create a Radicle Org

  1. people often ask about different governance and DAO contracts here, but I push for them to keep it simple and just see their devDAO as a sub-dao and govern via a multisig
  2. Once org created quite often it seems as if The Graph doesn't index fast enough and this means we can't really move forward - THIS IS WHERE MANY ONBOARDING CALLS HAVE FAILED
  3. Add members costs gas, so encourage people to avoid right now, but this will impact activation
  4. Non-trivial setup effort on gnosis - wasn't showing created safe and so had to copy gnosis safe address from app.radicle.network org page to gnosis for setup
  5. transaction sometimes doesn't show in gnosis when trying to create an anchor

3. Add a project to your org

  1. Adding a project to you account seems to result in people creating a simple test repo. having mirroring functionality that port existing github open source repos would be amazing here as it will impact activation. having a bunch of orgs with a test repo on them doesn't really create much value.
  2. Anchoring hasn't happened in most (all) cases as org setup failed prior to getting to this point

4. Set up an org seed node

  1. THIS IS ALSO WHERE ALMOST ALL HAVE FALLEN OFF - It's the co-ordination required and often with very expensive and limited engineer/dev ops time that makes this such an issue
  2. Even if there is someone with experience deploying things to a server they often want to pull their infrastructure team in as don't want to pay for additional server OR don't want a random server setup without infra oversight
  3. They also need access to their DNS to adjust that and they often don't
  4. They need to setup an RPC provider, which many don't have