qualitylab

Knowledge distribution · Slack

Onboard new contributors deliberately, with people, not just docs

tier II/cost to adopt: high/active

Contributors who went through a structured onboarding programme reached their first merged commit a median 35% to 45% faster and produced code 14% less likely to introduce bugs than comparable contributors who did not.

Do this firstOne command builds and tests the project from a clean checkout

Run an actual programme with mentors, teaching content and hands-on work, and treat it as infrastructure rather than an event.

The numbers are unusually complete for this area. Time to first merged commit fell by a median 45% for female and 35% for male and non-binary contributors. The median probability that an accepted patch introduced a bug was 25% for contributors without the programme and 14% for those with it, significant with a large effect size — and the onboarded group submitted more code, and more complex code, while being less bug-prone.

The obvious objection is the right one: people who attend an onboarding event are not a random sample of people who could have. The study is correlational throughout and says so. What it does establish is that the association survives a matched comparison across 84 months, with 720 contributors deliberately excluded to keep the groups clean.

Note what this control is not. The authors are explicit that the programme was more than a tutorial on branching or running the suite — the automation that makes a checkout work is a prerequisite here, not a substitute.

The decoy

A contributing guide. It is the artefact every project has and the measured programme was explicitly more than one: mentors spent substantial effort explaining how the ecosystem and its individual projects relate, community norms, and communication — none of which a document has ever conveyed to someone who has not asked a question yet.

Evidence

Last reviewed 2026-08-19.