oss-contributor-onboarding

Start by scoring the first-contribution path rather than rewriting documentation: check that contribution is invited, setup runs cold, beginner issues exist, and submissions get answered. Fix the leaking step first, then prove the fix with a cold run from a clean machine.

A beginner-friendly issue needs seven parts: observed behaviour, expected behaviour, the file and its test, required skills or APIs, a suggested approach, the exact verification command, and a named mentor. Size it at roughly one evening for someone new to the codebase.

Acknowledge on a separate clock from reviewing: a same-day note saying the PR was seen and when review will land. GitHub's Open Source Guides report contributors reviewed within 48 hours return at a much higher rate, though no published dataset backs the figure.

Adopt the portable .devcontainer format before choosing any hosted vendor, since the format works across editors and cloud workspaces while the hosting choice does not. Vendor-published time savings are marketing figures with no peer-reviewed measurement behind them.

Only after the environment and review loop already work, since an under-mentored intern costs more than no intern. The two most-cited studies disagree on retention, and a solo maintainer with a few hours per week cannot clear a mentor's weekly commitment for a full season.

The common causes are silence on the submitted PR, discovering the work is out of scope after review rounds, and no explicit invitation to a second contribution. Invite the next contribution at merge time with a named issue, since this almost never happens on its own.