Most people assume contributing to open source means writing code. The interesting projects get far more from their non-code contributors than most people realize. Documentation is where a newcomer can make a real difference, and the barrier to entry is lower than anywhere else.
Why docs matter more than you think
A project’s code can be perfect and still fail. If nobody can figure out how to install it, or how to run the tests, or what an option actually does, the project stalls. Maintainers write code well, and they’re often terrible at remembering what it was like to not know it. That’s the gap you fill.
Every README section that finally makes sense to you is a section a maintainer wrote while already knowing the answer. If you got confused, other newcomers will too. Your confusion is a signal and your fix is the contribution.
What counts as documentation
Anything that helps the next person understand the project.
- A README that’s missing setup steps or says “install dependencies” without saying which ones.
- A comment in code that doesn’t match what the code actually does.
- A
CONTRIBUTING.mdthat’s outdated or missing. - Error messages that expect knowledge you didn’t have.
- A tutorial, walkthrough or FAQ that would have saved you an hour.
Fixing the typo,rewriting the unclear paragraph, adding the example that was missing counts.
Why it’s a good first contribution
Docs changes are low-risk. A maintainer won’t lose sleep reviewing a paragraph you rewrote the way they’d worry about a logic change in the core. Your PR is small, reviewable, and genuinely useful.
Docs also teach you the project. To write clear documentation you have to understand how the project works. You’ll run the install, trace the setup and figure out the pieces. You learn more from documenting a tool than from watching someone use it.
How to do it well
Read the existing style first. If the README uses short sentences, keep yours short. Match the tone, the heading structure, and the formatting. A doc that reads differently from the rest of the repo feels off.
Be precise. Say “requires Python 3.10 or newer”, not “needs a recent Python”. Say what the command does, not just what it is. Add a concrete example whenever you can.
Keep your changes focused. One section per PR. A giant rewrite is hard to review and easy to reject. Small, clear improvements get merged. You can also use AI to help in doing it well.
Where to start
Pick a project you already use. If you’ve been fighting with a tool, it’s docs are your natural target. Look for a README with gaps, or issues labeled good first issue or documentation. Many projects list doc tasks right alongside code tasks.
By the time we start opensourcing our projects,our repos are a safe place to practice. We review PRs directly and we’re happy to walk you through the workflow. Find us on Discord.
A PR that fixes a confusing sentence helps someone you’ll never meet. That’s the whole point of the community.