Chapter 1 of 8 · 5 checks · 4 min
Pick a healthy project
Before you write any code, make sure the project is open source, alive and likely to review what you send.
Start with a project you already use or want to learnShould
Why it matters and how to check
The Open Source Guides suggest starting with projects you already use, because you understand the problem they solve and you will keep coming back. A library from your final year project, a tool in your daily workflow or a framework you use at work are all good starting points.
Familiarity also makes your contribution better. You already know where the documentation confused you and which error messages were unhelpful, and those are exactly the gaps maintainers want filled.
Check it: write down two or three projects and, for each, one thing you have personally found missing, confusing or broken. If you cannot name anything, pick a different project.
Do
- List the libraries and tools in your own projects first
- Note the docs or errors that confused you as a user
Avoid
- Picking the most famous repository only because it looks good on a profile
Confirm the project has an open source licence fileMust
Why it matters and how to check
A repository is not open source just because its code is public. The Open Source Guides point out that without a licence the project is not open source, and GitHub's documentation explains that without a licence the default copyright laws apply and the author keeps all rights.
Look for a
LICENSEorCOPYINGfile in the root of the repository, or the licence name in the repository sidebar. Common ones are MIT, Apache 2.0, GPL and BSD. Your contribution will be released under that licence, so make sure you are comfortable with it.Check it: open the repository home page and confirm the sidebar shows a licence, or that a licence file exists in the root.
Do
- Read the licence name before you start work
- Ask in an issue if the licence is missing or unclear
Avoid
- Contributing to a public repository that has no licence at all
Check that the project is active: recent commits, merges and repliesMust
Why it matters and how to check
An abandoned project will never review your pull request. The Open Source Guides list the signals to check: when the latest commit was made, how many contributors there are, how often people commit, how many issues and pull requests are open, and whether maintainers respond to them.
Spend five minutes looking before you commit hours of work. Open the commit history, then the closed pull requests, and see whether outside contributors' pull requests were merged in the last few months.
Check it: find at least one pull request from someone who is not a maintainer that was reviewed and merged recently. If you cannot find one, expect a long wait or no answer.
Do
- Look at closed pull requests, not only open ones
- Check how long maintainers took to reply to recent issues
Avoid
- Projects where the last commit and the last maintainer reply are years old
Read a few issue threads to see how maintainers treat newcomersShould
Why it matters and how to check
The Open Source Guides suggest checking whether the project is welcoming: are maintainers helpful in issues, is the conversation friendly, are pull requests reviewed, and do people say thank you. They also warn that frequent flame wars can mean energy goes into arguments rather than development.
Read three or four recent issues opened by first-time contributors. You are looking for patient answers and clear guidance, not dismissive one-line closes.
Check it: you can point to a recent thread where a maintainer helped a newcomer get a contribution over the line.
Do
- Read threads opened by first-time contributors
- Note which maintainer usually reviews outside pull requests
Avoid
- Projects where newcomers are routinely mocked or ignored
Find the code of conduct and know how to report a problemNice to have
Why it matters and how to check
Many projects publish a code of conduct, often as
CODE_OF_CONDUCT.md, that sets expectations for behaviour and explains how to report problems. GitHub shows it as a tab on the repository overview next to the README when one exists.Reading it takes two minutes and tells you how the community expects people to disagree, who enforces the rules, and where to go if someone treats you badly. It also tells you how you are expected to behave.
Check it: you know where the code of conduct is and which contact it names for reports.
Do
- Read the code of conduct before your first comment
Avoid
- Assuming every project shares the same rules