contribute-to-open-source

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:

1. Fork on GitHub, clone the fork, add the upstream remote.
2. 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.
3. Branch, make the change small and complete, run the project's tests or checks.
4. 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.
5. 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