Solving the Onboarding Lottery

Onboarding new community members can be one of the most worthwhile investment of SC time, but it can also be a complete waste depending on their level and duration of commitment.

The Problem

The investment to onboard someone is a lottery. We might spend our time onboarding and guiding a seemingly promising future contributor, only for them to disappear a week later. Some people are flakes, and some people are naturally going to abuse or take for granted the time for others. I’ve appreciated the care @decentralion and other devs have taken to listen to my priorities and guide me to areas of the project that suit my interests. However, I’m worried this time spent could be abused as the project attracts more people. In addition, there’s only so much attention/time to devote to new contributors, and focusing on one might come at the cost of another. In this case, we’d not only waste our time, but at the cost of letting potentially great contributors slip through the cracks.

I think this is an important organizational issue to solve, particularly as SC grows and attracts more contributors. Here are some specific ideas I have to address this.

  1. Onboarder Edge Weight (I :heart: this one): bringing new contributors into the ecosystem has potentially massive long term upside, but isn’t necessarily the most fun or glamorous use of time in the short term. In SourceCred style, I’m imagining that if A onboards B in a more formal way, that some small percentage of cred from B could flow to A. This leverages the SC graph to naturally reward onboarders.

  2. "Staked" Mentorship / Tribute: this may be overly cryptoeconomic, but to signal commitment, a new contributor might stake some funds that could be slashed if they fall off the map. This helps us gather a rough idea of how serious certain people are and discourage abusers. If someone is acting in good faith, they wouldn’t need to overthink the tribute. The risk here is losing contributors who are intimidated by the staking. How we’d use this signaling mechanism, and how we’d decide to slash are another decision, but this mechanism of putting skin in the game could be useful. Keep in mind I am not suggesting that we give 1-to-1 priority to whoever stakes the most. That feels very un-SourceCred to me.

On a more meta-level, this is asking the question of how recruitment/training/hiring translates into the wild world of web3. I think there’s magical emergent benefits if we get this right, and would avoid a lot of future headache.

1 Like

I have some thoughts:

  • In regards to #1, I definitely agree that those who onboard put in a lot of work and that work should be recognised and gain Cred. Having an onboarding system has proven difficult in the past, but I believe is totally possible. However, I would rather we focus on holding the new contributors in a supportive, collaborative onboarding style. Instead of formality, we can use structure and describable steps of what to expect. This shift in lens is, in my mind, super important to the process.

  • As for # 2, I look back on my experience joining SourceCred, and I never would have staked anything, even though I had a personal connection to the tbd and knew I wouldn’t be taken advantage of. Investing in something one doesn’t understand doesn’t feel like informed consent, isn’t super comfortable (especially for non-devs who feel totally in the dark and need lots of time to acclimate to the platforms and language used in SourceCred), and involves staking using cryptocurrency, which many devs and non-devs alike have very little experience with and may have reason to distrust. Also, asking for an investment in something unknown is inaccessible to those without financial stability. Furthermore, asking for someone to invest in something they may genuinely not feel like a good fit for might create more work for the team, as newcomers would feel more pressure to not leave, but ultimately leave after more time has passed, due to it just not being a good fit. Most importantly, asking people to invest to show their commitment seems to go against the person-centered approach SourceCred works to uphold. We want people to know that it’s okay to bop in, get a sense for the community, and then decide it’s not for them. Instead, we could create a goal for newcomers to meet to gain community trust and have us give them more of our bandwidth.

Let me know if I misunderstood anything you meant.


I’m a fan of this, and I dont’ mean to propose anything bureaucratic by any means. I think this could be done voluntarily or culturally, such that it would be custom to flow some small percentage of your nodes’ cred in the graph to the people who helped get you started. You could also do it for some period of time, like the first year.

Yeah, I agree with this take on #2 as a whole.

I def agree that we should have a way to flow cred from “mentees” to “mentors”. A simple way to start would be to give every person control flowing a portion of their Cred every week to people that are supporting them in the project. E.g. you could be in control of flowing 20% of your weekly Cred to the people supporting you that week.

This still might not quite capture the value of onboarding. Suppose that Rose provides a lot of support to Garnet when Garnet is ramping up, so Garnet flows a fraction of their Cred in those weeks to Garnet. However, Garnet is still ramping up, so it’s not very much Cred. A year later, when Garnet has hit their stride, Rose isn’t as involved, and so Garnet is flowing Cred to someone else. However, arguably, Garnet wouldn’t be in the project (and earning all this Cred) if they hadn’t been onboarded by Rose, so maybe Rose should get a portion of that Cred even though they aren’t as present anymore?

Seems tricky to get this perfectly right, but having a really basic system here would be a big improvement over no system at all.

I basically agree with @Bex’s pushback. Having an economic mechanism where people need to stake $ in order to get attention for onboarding had a lot of downsides:

  • high friction and offputting
  • potential for abuse / exploitation of the people being onboarded
  • gatekeeps opportunity in the project based on wealth / disposable income
  • contributors who don’t work out are likely to feel burned / taken advantage of

Happily, I think we can accomplish the same goal without needing to involve money at all.

Over the course of my time leading SourceCred, I was “burned” several times in that I invested a lot of effort into onboarding people who didn’t really stick around. For example, someone would tell me that they were interested in contributing to SourceCred, and I’d immediately set up an hour-long pair programming session to show them the codebase, and then they’d kind of disappear. This was pretty disappointing, and discouraged me from onboarding other folks.

More recently, I’ve found a better approach, which is: I will not invest much effort into onboarding someone until they’ve demonstrated (through their actions) that they are seriously interested and willing to put in some effort. Thus, when someone wants to onboard, I’ll give them a “proof of work” kind of assignment which is low-effort on my part, but will require some real work from them in order to complete.

As an example from our own relationship, @eeli: when you reached out to me and said you were interested in contributing to SC algorithms, I didn’t immediately spend a bunch of time onboarding you. Instead, I asked you to do your own research and get to the point where you could explain eigenvectors and how they’re relevant to the PageRank algorithm to me. This only took me 5 minutes, and gave you an opportunity to show (not tell) that you were capable and willing to do some work. Once you did that, I felt much better about spending cycles on onboarding you, since you had already demonstrated interest and follow-through.

This is actually a much better signal than someone staking $. Someone staking $100 could just mean they have a lot of disposable income, but it wouldn’t actually meaningfully predict their long term engagement. Your willingness to actually do some research and follow through was a much better basis for predicting that onboarding you would be a good decision.


So glad that you saw this and wrote a topic about it!

I think that once we set up a more robust onboarding flow that allows newcomers to explore entry points independently (but with support from the flow) that will offer a small amount of sorting for commitment through action before newcomers even make it to creating a mentor/mentee relationship. So that will help.

Second, I also like solution 1 over solution 2, and think that solution 1 could be teased out into something even more nuanced as we refine our technology. Something like Gratitude Spikes, or defining levels of investment like being a “guide” vs being a “mentor”, or having an Onboarding Team of trained folks who are receiving Cred from the project for the work they do to improve it could help build on the idea of flowing Cred to those doing hands-on onboarding.

1 Like

I think regarding Cred flow (whether for onboarders or supporting persons), there are a couple of features we can build in that might make this intuitive, robust, and fair:

  • Lifetime Cred grant (a la @LB’s Gratitude Spikes idea): you grant a person a one-time Cred amount for the contributing impact they’ve made in your success. This can be done repeatedly as one-offs, since you may realize additional value they’ve brought to your life over time.
  • Gratitude Cred, for flowing a % of Cred to mentors, onboarders, supporters, assistants, etc. This could be a feature that lets you specify things like “Give 15% of my Cred earnings to Garnet for their help guiding me into SC, for the next three weeks.” It could be a fixed amount for a specified time period, never, or—inspired by the new RECENT Grain distribution policy—it could have an exponential drop over the course of X weeks.

For instance, for onboarding we could have a recommendation of 20% of Cred with a discount rate of 0.5 (RECENT policy-style), so that in week 1 the onboarder gets 20% of the Cred, week 2 they get 10%, week 3 is 5%, week 4 is 2.5% and maybe we cease it there, or cease it once it drops below 1%.

Addendum: if we make the RECENT policy a common but consistent weighting pattern in SourceCred, it would help explain it to all users alike.