Contributing to Open Source: First PRs & the Workflow

Contributing to Open Source

Contributing to open source is one of the best ways to grow as a developer: you work on real code used by real people, get feedback from experienced maintainers, build a public portfolio, and join communities that often lead to friendships and jobs. It can feel intimidating — submitting code to a project strangers maintain — but the path is well-trodden and welcoming, and contributions come in far more forms than just code (docs, tests, bug reports, design, triage all count).

The mechanics are standard Git: fork, branch, commit, open a pull request. The human part — finding the right project, reading its contribution guidelines, writing a clear issue or PR, and engaging respectfully — matters just as much. A small, well-scoped, well-communicated contribution lands far more easily than a large, surprising one.

TL;DR

Contributing builds skills, portfolio, and community — and isn't only code (docs, tests, triage count).
The workflow: fork → branch → commit → pull request → respond to review.
Read the contributing guidelines and start with good-first-issues.
Write clear issues and small, focused PRs; engage respectfully.

Quick Example

The standard contribution flow:

Ways to Contribute (Not Just Code)

Documentation — fix typos, clarify confusing sections, add examples. The most welcoming entry point.
Bug reports — a clear, reproducible issue is a real contribution.
Tests — improving coverage helps everyone.
Triage — reproducing issues, labeling, answering questions.
Code — bug fixes, then features.
Design, translations, community support — all valued.

Finding a Project

Start with tools you use — you understand the problem and care about the outcome.
Look for good first issue / help wanted labels — curated for newcomers.
Check the project is healthy — recent activity, responsive maintainers, a CONTRIBUTING.md.
Read the contributing guidelines first — every project has its own norms (style, tests, PR process).

The Pull Request Workflow

Fork the repository and clone your fork.
Branch for your change (git checkout -b descriptive-name).
Make the change, following the project's style and running its tests.
Commit with a clear message and push to your fork.
Open a PR with a description of what and why, linking any related issue.
Respond to review — address feedback graciously; iteration is normal.

See Version Control and Code Review.

Best Practices

Read CONTRIBUTING.md and the code of conduct before starting.
Start small — a docs fix or a good-first-issue builds confidence and trust.
Discuss big changes first (open an issue) — don't surprise maintainers with a huge unsolicited PR.
Keep PRs small and focused — easier to review and merge.
Be patient and gracious — maintainers are often volunteers; respond to feedback kindly.

Common Mistakes

A huge unsolicited PR

Ignoring the project's conventions

FAQ

How do I make my first open-source contribution?

Start small and non-intimidating: pick a project you actually use, look for issues labeled good first issue or help wanted, and read its CONTRIBUTING.md first. A documentation fix (a typo, a clarified example) is the perfect first contribution — low-risk, genuinely helpful, and it teaches you the fork → branch → PR workflow without deep code changes. Then graduate to small bug fixes. The goal of your first contribution is to learn the process and build confidence, not to make a sweeping change; momentum comes from a series of small, accepted contributions.

Do I have to write code to contribute to open source?

No — and believing you do keeps many people from contributing. Documentation improvements, clear bug reports with reproductions, writing or improving tests, triaging issues (reproducing, labeling, answering questions), translations, design work, and helping other users are all real, valued contributions. Many maintainers say non-code contributions are among the most helpful, because they're chronically under-supplied. Code is one path in, but the door is much wider than that. Start wherever your skills and the project's needs overlap.

Why was my pull request rejected or ignored?

Common reasons: it was too large or out of scope (maintainers couldn't easily review it, or it didn't fit the project's direction), it didn't follow the contributing guidelines (style, tests, process), it duplicated existing work, or you didn't discuss a significant change before building it. Sometimes it's simpler — maintainers are often unpaid volunteers with limited time, so a polite follow-up after a reasonable wait is fair. The best defenses: discuss big changes via an issue first, keep PRs small and focused, follow the project's conventions, and be patient and gracious.

How does contributing to open source help my career?

Several ways. It builds real skills on production codebases with feedback from experienced maintainers — often better learning than tutorials. It creates a public portfolio of work that potential employers can actually see and evaluate. It expands your network through the communities you join, which frequently leads to job opportunities and references (see Job Search). And it demonstrates initiative, collaboration, and the ability to work within an existing codebase and process — exactly the signals hiring managers look for. Consistent, quality contributions compound into both capability and visibility over time.