Skip to main content
Back to module
Foundations for Software, Data, Design & Tech Education Careers · Building Evidence

Contributing to open source

Reading40mLesson 2 of 3 in this module

Find a beginner-friendly open source issue, understand the contribution workflow and make a plan to contribute.

Why it matters

Open source contributions are public proof that you can work in someone else's codebase, follow a team's conventions and respond to review. That is exactly what you do in a tech job, and it is hard to show any other way before your first role. Contributions also help you learn from experienced maintainers and meet people in your field.

Open source is not only code. Documentation fixes, translations, tests, bug reports with clear reproduction steps, design work and accessibility reviews are all valuable, which makes open source useful for designers, analysts and trainers as well as developers.

The core idea: the contribution workflow

Most projects on GitHub use the same steps:

  1. Find an issue. Look for labels like good first issue, help wanted or documentation.
  2. Read the rules. The CONTRIBUTING.md file says how the project wants contributions; the CODE_OF_CONDUCT.md says how people treat each other.
  3. Say you are working on it, if the project asks for that.
  4. Fork the repository (your own copy on GitHub), then clone it to your computer.
  5. Create a branch, make the change, and run the tests.
  6. Commit with a clear message and push to your fork.
  7. Open a pull request (PR) explaining what you changed and why, and link the issue.
  8. Respond to review. Maintainers may ask for changes; that is normal and useful.

In commands, the middle of that looks like:

git clone https://github.com/<you>/<project>.git
cd <project>
git checkout -b fix-typo-in-install-docs
# edit the file, then
git add docs/install.md
git commit -m "docs: fix broken link in install guide"
git push origin fix-typo-in-install-docs

Then open the pull request from your fork on GitHub.

Worked example: a documentation fix

You use a Python library and notice the install guide links to a page that no longer exists.

  • You search the issues and find "Broken link in install docs", labelled good first issue and documentation, unassigned.
  • CONTRIBUTING.md says: "Comment on the issue before starting; docs changes do not need tests; use conventional commit messages."
  • You comment: "Hi, I'd like to fix this. I think the link should point to the new getting-started page. Is that right?"
  • A maintainer replies "Yes, thanks!" You fork, branch, fix the link, commit with docs: fix broken link in install guide, push and open a PR that says "Fixes #1234".
  • The reviewer asks you to fix the same link in the French translation too. You push a second commit. The PR is merged.

That single small PR shows a future employer that you can read a project's rules, communicate clearly, use Git and respond to review.

Choosing a project

  • Start with something you already use: you understand what it does and will notice problems.
  • Prefer active projects: recent commits, maintainers replying to issues within days or weeks.
  • Check the licence and code of conduct: a project with neither may not welcome contributors.
  • Smaller, friendly projects are often easier to start with than huge ones.

Useful starting points (Checked on 2026-10-23.): the GitHub guide https://opensource.guide/how-to-contribute/, the practice repository https://github.com/firstcontributions/first-contributions and the issue finder https://goodfirstissue.dev.

Etiquette

  • Be patient. Most maintainers are volunteers.
  • Do not claim many issues at once, and say so if you have to stop.
  • Keep PRs small and focused on one issue.
  • Never open low-effort PRs (like whitespace changes) just to get a contribution count. Maintainers notice, and it can harm your reputation.
  • Do not paste AI-generated changes you do not understand. Be ready to explain every line.

Common mistakes

  • Starting work without reading CONTRIBUTING.md, then having the PR rejected.
  • Working on an issue someone else has claimed.
  • One giant PR that changes many unrelated things.
  • Taking review comments personally. Review is how projects keep quality high.
  • Giving up after the first PR. Repeated contributions to one project show much more than single drive-by fixes.

Quick recap

  • Open source shows you can work in a real codebase with real collaborators.
  • Contributions include docs, tests, design and bug reports, not only code.
  • Workflow: find issue, read rules, fork, branch, change, test, commit, push, PR, respond to review.
  • Start with projects you use, keep PRs small, and follow the project's etiquette.

Try it

Open the Do tab to practise the workflow and plan your first real contribution.

Also in this lesson: