A contributor does not arrive because a repository exists. They arrive because they can immediately see where they fit.
When we first open-sourced our primitives, we made the classic maintainer mistake: we threw code over the wall, added a generic license, and waited for pull requests. Nothing happened. It took us six months to realize that open source collaboration is a user experience problem.
1. Stop treating contribution as a single action Most repositories treat contribution as "clone the repo and build a complex feature". That asks too much trust too early. We mapped a ladder of micro-contributions: - **Level 1: Verification**: Reproducing a reported bug on a specific device or browser. - **Level 2: Documentation**: Clarifying an ambiguous paragraph in the README or fixing a typo. - **Level 3: Component Polish**: Improving keyboard focus rings or adding an ARIA role. - **Level 4: Feature Architecture**: Authoring an RFC for a new adapter.
Every one of those actions is valuable, and each requires a tailored invitation.
2. Write issues as invitations, not tickets Compare these two GitHub issues: - *Bad*: "Fix cart hydration issue on mobile Safari." - *Good*: "Improve cart hydration reliability on mobile Safari. **Context**: Users report cart contents occasionally flicker on Safari 17. **Files to touch**: `lib/cart-engine.ts` lines 45–60. **Definition of Done**: Cart persists during fast browser refresh. We have a test script in `tests/cart.test.ts` you can run."
The second issue was resolved within 4 hours by a first-time contributor in Brazil. Specificity creates psychological safety.