Accepting contributions¶
Handling contributions is a key ingredient of any open-source project. Contributions can come in different forms.
Contributing changes¶
New features or corrections of existing features can come from contributors outside your project's core team. For software they often come in as "merge requests" or "pull requests".
This is the typical route for new people to engage through contributions. Don't feel forced to accept all contributions; they should match the scope of your project and they need to satisfy the quality requirements. Continuous integration should be set up; review (and, as part of that, due diligence) must be performed.
Try to engage with contributors also outside the developer platform; you might be able to make them long-time contributors!
A typical first contribution is a simple bug fix; most development platforms have a common way to signal them. On Github, such issues are commonly labelled "good first issue".
Contributing spelling mistake corrections is a way for people to get their contribution counter up; make sure you have a triviality bar. That said, spelling corrections can be massive and wonderful contributions!
Contributions to documentation, tests, infrastructure, etc can be extremely valuable, too.
Contributing reviews¶
A weak spot of many successful projects is scaling up the reviews velocity. This is an essential contribution to projects, much appreciated by most maintainers: helpful reviews will make you stand out in the group of contributors and create a link of trust between maintainers and you.
Once you know how reviews are done, ideally by having a couple of your own contributions reviewed by experienced project members, why not review your first pull / merge request of someone else? In your review you can call out that you are not a code owner, that your review is not authoritative, but that you are trying to be helpful, to move the pull / merge request forward.
It's good style to contact the maintainers / code owners for feedback on your first reviews. Good projects will try to guide you to become a reviewer with positive impact, and will put you on track to take over more responsibilities if you so wish.
Contributing support¶
For open-source projects with a large user base, a large fraction of the developers' time is traditionally invested in user support. You can help here, in the issue tracker, the forum or in places such as Stack Overflow. If done successfully you will get noticed by users and developers alike. You also free developers' time - who knows, maybe even for them to fix the bugs you have reported.
Contributing to project management¶
Experienced contributors (such as reviewers) can also help with triaging issues or defining development priorities: the day-to-day issues of "we don't have enough people, what do we do next?" Once people have become contributors, it's time to encourage them to participate and raise their voice.
Contributing resources¶
Your project might be lucky, being offered a share of a developer, or budget to hire for instance a developer. If it happens it's usually in a commercial context; see Collaborating with companies.
You might also be offered free resources for continuous integration, for instance on special platforms. Or a run of a commercial review tool (code quality, security issues, etc). All of these are often valuable contributions for open-source projects: you should consider asking whether you can publicly show the contributor's logo, to signal that the project is carried on multiple shoulders.
Contributing to a project's evolution¶
By providing contributions, people and companies are investing in your project. It is likely that at a given scale, such contributors will expect to be able to influence how the project evolves. This can be institutionalized with an agreement set up by the Knowledge Transfer group.