Why bother¶

• You learn from reading and getting code reviewed by people who are better than you at specific things.
• It's a public, verifiable portfolio — merged changes in real projects carry more weight than any résumé bullet.
• You fix the tools you actually use instead of working around them.
• You build relationships with people in your field.

Contributions that aren't code¶

Many of the most valued contributions don't involve writing features:

• Documentation — fixing errors, writing missing guides, improving examples
• Bug reports with minimal reproductions
• Triage — reproducing reported bugs, labelling, closing duplicates
• Reviewing pull/merge requests
• Testing release candidates on unusual platforms
• Packaging for distributions (Debian, Fedora, Arch, Homebrew, Nix)
• Translation
• Answering questions in forums, chat, and issue trackers
• Design, accessibility review, and CI/infrastructure work — the latter is where ops people are often desperately needed

Finding a project¶

The best project to contribute to is one you already use. You understand its problems, you can test changes in real conditions, and you care about the result.

Otherwise:

• Look for labels like good first issue, help wanted, beginner, easy, E-easy (Rust), quick fix
• Check the project is alive: recent commits, recent releases, issues getting responses, MRs getting reviewed
• Read CONTRIBUTING.md and the code of conduct before anything else

Before you write code¶

1. Read the contributing guide. It answers most questions: build setup, test commands, commit message format, DCO/CLA requirements.
2. Check for existing work. Search open issues and MRs. Someone may already be on it.
3. Comment on the issue first for anything bigger than a typo. "I'd like to work on this — my plan is X. Does that fit?" Nothing is more demoralizing than a large MR rejected because it went in a direction maintainers didn't want.
4. Lurk. Read the mailing list, chat, or recent MRs to learn the project's norms.

The workflow¶

# Fork the project in the web UI, then:
git clone [email protected]:<you>/<project>.git
cd <project>
git remote add upstream https://gitlab.com/<org>/<project>.git

# Keep in sync with upstream
git fetch upstream
git switch -c fix/descriptive-name upstream/main

# Make changes, run the project's own tests and linters
cargo fmt && cargo clippy -- -D warnings && cargo test

# Commit with sign-off if the project uses a DCO
git commit -s -m "fix(parser): handle empty input without panicking"

git push -u origin fix/descriptive-name
# Open the merge/pull request from your fork in the web UI

If upstream moves while your MR is open:

git fetch upstream
git rebase upstream/main
git push --force-with-lease

Some projects (the Linux kernel, Git itself, PostgreSQL, many GNU projects) don't use pull requests at all and accept patches by email via git format-patch and git send-email. Read their docs; it's a worthwhile skill.

Writing a good merge request¶

• One logical change per MR. Don't mix a bug fix, a refactor, and formatting changes.
• Explain why, not just what. Link the issue. Describe how you tested it.
• Keep it small. A 50-line MR gets reviewed today; a 2,000-line one gets reviewed "later."
• Match the existing style, even if you'd do it differently.
• Include tests and docs for behaviour changes.
• Make CI green before asking for review.

Etiquette¶

• Maintainers are usually volunteers. Be patient; a polite nudge after a week or two is fine, daily pings are not.
• Accept review feedback gracefully. "Good catch, fixed" goes a long way.
• If an MR is declined, ask what would make it acceptable — or accept that it doesn't fit the project's direction. You can always maintain it in your fork.
• Don't open "+1" comments. Use reactions.
• Don't submit low-effort, unverified, or AI-generated changes or security reports you haven't checked yourself. Several projects have started banning contributors over this.
• Report security vulnerabilities privately, following the project's SECURITY.md, never as a public issue.