When people talk about contributing to an open source project, they almost always think of pull requests with new features. Yet a huge share of the work that keeps a project alive is not code: it is explaining, translating, organising, checking, answering. Many maintainers say this is exactly the work that is most lacking, because it is less visible and less rewarding. And it is an excellent way in for people who do not program, or who want to get to know a project before touching its code.
Documentation
Documentation is often the weakest point of a technically solid project. Those who write it know the software too well to notice the steps they take for granted. A new user, by contrast, sees all of them.
Concrete contributions:
- fixing instructions that no longer work with the current version;
- adding a complete example for a common use case;
- writing a getting-started guide that begins from a clean installation;
- reporting unclear pages precisely, saying where you got stuck;
- harmonising terminology and structure across pages written by different people.
A good method is to note every difficulty you encounter during your first installation: that list is already a plan for improving the documentation.
Translations
Software available only in English excludes many people. Many projects use collaborative translation platforms that do not require Git: you translate strings directly in the browser.
A few precautions make a translation genuinely useful:
- use the project's glossary, or propose one, so key terms are always translated the same way;
- respect placeholders such as
%sor{name}, which must not be translated or moved arbitrarily; - try the translated interface, because a correct string may be too long for a button;
- maintain, not just translate: new strings arrive with every release.
Issue triage
Triage means putting incoming reports in order. In popular projects, issues pile up faster than maintainers can read them. Helpers can:
- check whether a reported bug can be reproduced with the latest version;
- ask the author for missing information;
- spot duplicates and link them to the original issue;
- suggest labels for type, area and priority, if the project allows it;
- flag issues that have already been resolved and can be closed.
This work saves maintainers hours every week and, over time, often leads to being given permissions to manage the tracker.
Testing pre-releases
Before a release many projects publish beta versions or release candidates. Trying them on your real-world use and reporting what works and what does not catches problems automated tests miss: unusual configurations, hardware combinations, uncommon workflows. Even a simple «I upgraded my setup and everything works» is useful information, if accompanied by details of the environment.
Supporting other users
Forums, chats and Q&A sections are full of requests that anyone with some experience can solve. Answering there frees maintainers from basic support. A few rules:
- answer only if you are reasonably sure;
- point to the relevant documentation, so the answer stays useful later;
- if a question keeps coming back, suggest adding it to the documentation.
Design, accessibility and communication
Other valuable and often overlooked contributions:
| Area | Examples of contribution |
|---|---|
| Design | Interface review, icons, visual consistency |
| Accessibility | Screen reader testing, contrast, keyboard navigation |
| Communication | Readable release notes, introductory articles, website updates |
| Organisation | Running events, meetings, minutes |
Accessibility in particular requires specific skills that are rarely present among a project's developers.
How to start
Read the CONTRIBUTING.md file: many projects also describe non-technical contributions. Introduce yourself where the community gathers and ask where help is needed. Start with something small and well defined, finish it and only then take on another. One completed contribution is worth more than three started ones.
In my work I have seen people become key figures in a project without ever writing code, simply because they were the ones who knew the documentation and the users best.
In short
- Much of the work that keeps a project alive is not code.
- Documentation, translations and triage are the most needed contributions.
- Testing pre-releases and helping users takes a lot of load off maintainers.
- Design, accessibility and communication require skills often missing from projects.
- Start with a small task and see it through.
