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.