contribute-to-open-source

# 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