This blog post is part of our Collaborations Workshop 2022 speed blog series. 

By Hugo Gruson and Heather Turner.

Most open-source projects are led by a small team of developers. However, for the projects to be sustainable, they rely on contributions from the community, in the form of bug reports, feature requests and contributions to the codebase itself.

In the case of large-scale projects, like the R project, it is often unclear how external contributors can join in. The experienced developers do not have much time to mentor potential contributors on the development processes and etiquette, to help them feel confident in contributing. 

Smaller-scale projects, like an R package, can face similar issues, but also face the issue of attracting contributors in the first place, as their project is less well-known. 

In this blog post, we consider ways to encourage contribution in open source software projects, both large and small.

Entry points to contributing

Just like starting a new job or joining a new group of people, it can be intimidating and overwhelming to try to join an open-source project as a contributor.

A way that maintainers could ease this feeling is by identifying clear entry points for new contributors: what kind of tasks could they tackle to get started?

In many projects, this could be things like contributing translations, triaging issues, or trying to reproduce existing issues. These are good entry points because they require no particular knowledge of the codebase.

These first contributions via the identified entry points serve multiple purposes:

• They create an initial interaction between the contributor and the maintainer(s) and build confidence from both sides. The contributor can get the assurance that they are gaining experience in a welcoming environment, while the maintainer(s) learn to trust the changes submitted by this specific contributor.
• The contributor can get familiar with the specific submission process for the project: etiquette for the pull requests, interaction with continuous integration systems and automated checks, etc.
• The contributor also gets familiar with the codebase itself.

Once the new contributor has acquired confidence and knowledge about the project, they might be willing to tackle bigger tasks beyond the scope of these entry points.

Mentoring and collaboration events

Even with clearly identified entry points, it might still be intimidating to submit a first contribution to a project. Maintainers can play a role in easing these fears by actively encouraging contribution and mentoring potential new contributors through collaboration events. During these events, maintainers can guide new contributors through the process of submitting their first contribution. Good examples of such collaboration events are Collaboration Campfires for the R project or Tidyverse Developer Day for the tidyverse suite of R packages. These events have proved successful at getting contributions from new contributors and at guiding people through the aforementioned entry points. The collaborative aspect can also reinforce the community feeling and boost the potential contributor’s motivation.

From a maintainer point of view, it is rewarding to see new people involved in your project. Additionally, in a world where open-source maintainers are often short on time, it can be helpful to group the onboarding of all new contributors in a single day.

Communication

Collaborators can benefit your project with their contributions, but working effectively with others requires good communication.

For example, users of the software are best placed to give feedback on the design, or report issues with the code or documentation. But the typical infrastructure (GitHub issues, Bugzilla) is not accessible to people without the technical background or relevant accounts. Consider ways in which a user might provide input another way, e.g., via a feedback form or a forum.

Users may prefer to reach out to maintainers via email or Twitter DM, which is convenient, but has the disadvantage of being restricted to the people involved. Communication that is open to the wider community, e.g. a mailing list, Slack group or GitHub issues, should be preferred, so that others can lend their expertise or learn from the exchange. 

Similarly, it is easier for established developers who know each other well to resolve issues on private DMs, chats or other private communication channels. However, this makes it difficult for external contributors to know the explanation for choices made or to be aware of the roadmap for the project, making it hard for them to add their contribution.

In conclusion you can make your projects more open to external contribution by creating clear entry points, providing opportunities for mentoring at a scale reasonable for your project, and working as openly as possible so that people can follow the progress of your project and identify where they can help.