| name | contribute-to-open-source |
| category | start |
| description | Make the person's first open source contribution. A real issue in a project they use, from fork to submitted change. Use when they say "I want to contribute to open source", "how do I make my first PR", or want public proof of work. |
contribute-to-open-source
Guide someone's first open source contribution. A merged
pull request on a project other people use is public, verifiable
proof of work — exactly what a thin resume lacks. The session ends
with a real issue claimed, the fork building on their machine, and
the first change pushed. Do the work with them at speed; every
command runs in this sitting, not as homework.
Find the project in their life
Do not send them to a "good first issue" aggregator full of
abandoned repos. Start from software they already use: the game
mods, the Discord bot in their server, the app or CLI tool or
library they touched this week, the site whose docs confused them
last month. A contributor who uses the project writes better fixes
and cares whether they land.
For each candidate repo, check the pulse together: commits in the
last month, maintainers responding to issues, a CONTRIBUTING file.
A friendly small project beats a famous one — first PRs to huge
repos often sit unreviewed for months, and say so.
Find the issue
Look through open issues labeled good-first-issue, help-wanted, or
docs — but also trust their own experience: a typo they noticed, a
confusing error message, a doc step that failed for them is a
legitimate first issue they can file and then fix. Right-sized
means they can explain the fix in one sentence before writing it.
Docs fixes, error-message improvements, and small reproducible bugs
all count; nothing is beneath a first PR.
Before writing code, read CONTRIBUTING.md, the issue thread, and recent pull
requests for the project's coordination norm. Comment to ask or state intent
only when the project requests it; some projects do not assign issues. Check
that no one is already doing the same work before starting.
Fork, fix, submit
All in this session, them at the keyboard where possible:
- Fork on GitHub, clone the fork, add the upstream remote.
- Get it building or running locally, following the project's own
docs. If the docs fail, that failure is a contribution too —
note exactly where.
- Branch, make the change small and complete, run the project's
tests or checks.
- Commit with a message that says what and why, push, open the PR.
The PR description links the issue and states what changed —
their words, plain.
- Set the expectation: review may take days, requested changes are
normal and not rejection, and they should respond within a day
when it comes.
Once merged, the contribution goes on the resume with the PR link —
https://sphinxstack.com/skills/build-resume/ shapes that line. If
they liked the workflow, https://sphinxstack.com/skills/ship-on-github/
turns it toward projects of their own.
Done
- Active project and right-sized issue selected under its published contribution rules
- Fork builds locally; focused change and relevant checks pass
- Pull request submitted in the person's words with issue link and proof, or a
documented maintainer-specific next step if submission is intentionally later
