Communication & Collaboration with Contributors in an Open-Source Organization

Zhiam Kamvar is Lesson Infrastructure Technology Developer at The Carpentries (Software Carpentry, Data Carpentry & Library Carpentry), an open global community teaching the skills & perspectives to turn data into knowledge.¹ Maëlle Salmon is a Research Software Engineer with rOpenSci. In this post they compare their experiences in the two distinct organizations The Carpentries and rOpenSci.

At rOpenSci, many packages are maintained by volunteer community members, and similarly at The Carpentries lessons are maintained by volunteer community members. We’re very thankful for the effort our volunteers put into that role and our organisations could literally not run without their work. However, sometimes infrastructure changes are decided centrally. For example, requiring two-factor authentication for all GitHub organization members at rOpenSci or overhauling the foundation of the lesson infrastructure at The Carpentries. In this post, we shall share some insights from our experiences regarding how we, as staff members, best support our volunteers through these transformations.

Making requirements explicit

When volunteers take on maintenance of something (be it an R package or an R lesson), it is helpful to make expectations explicit right away. These requirements can contain a list of tasks and expectations of time (to respond) and duration (of the responsibility). At rOpenSci we have an author guide for those who submit software to review, as well as a package curation policy. At The Carpentries, maintainers undergo an onboarding training to establish guidelines for how to work with Pull Requests, and to ensure our lessons align with The Carpentries’ core values and evidenced-based teaching practices. In 2022, The Carpentries established a yearly check-in to give maintainers a chance to step down if they have decided that they need a break from maintenance.²

Using several channels of communication and being responsive

Unless there are very few people involved, messages need to be sent in several places, with reminders. Not all at once, the idea is not to spam people! A mix of general communication channels (newsletter, mailing lists, Slack workspaces) together with more targeted communication (ping in GitHub issues, emails³), can best help deliver information… but also opens the floor for questions and feedback from maintainers (because at the end of the day, the most important part of the community is the community itself)! Answering contributor questions in a timely manner is key to trust.

Not rushing changes

Have you ever stumbled across a package dependency with a new release that broke everything? Not rushing changes is probably a good idea in general, but especially so in organizations where much of the work is done by volunteers juggling other responsibilities. Even big tech organizations like GitHub make changes slowly so that they don’t alienate their users. We keep this in mind when defining timelines so that we can give people support before the change happens.

Helping without taking over

It is important to us to do as much work on volunteers’ behalf as possible. For instance, when monitoring the dashboard of R-universe builds of packages, failures are reported with as much information as possible, with clear suggestions of fixes (possibly even pull requests). However, this has to be balanced with letting maintainers have ownership: for instance, we make as few direct code edits as possible. In The Carpentries, helping without taking over means that we provide decision support for maintainers, which looks like working on pull requests during maintainer meetings, providing clear context for contentious issues, aggregating issues that need help (rOpenSci equivalent page), and even providing a high-level governance structure made up of volunteers to address broad topics in curricula.

Conclusion

In this post, we described how we as staff members interact with volunteer maintainers in our organizations. Our key messages are: having clear requirements; communicating via several means, respectfully and timely; making changes not too quickly; doing as much work as possible while respecting ownership. We recognize that there will still be hiccups in the way we drive changes, but we do our best to learn our lessons. What is your own experience as staff or volunteer in open-source organizations?

1. Zhian also maintains the rOpenSci tinkr package that was first introduced on this blog. ↩︎

2. This has inspired rOpenSci to think about planning a similar yearly survey. ↩︎

3. On a technical note, some communication can be partly automated, e.g. emails can be sent collectively using gmailr. ↩︎