Just like many companies have different advancement tracks for their employees (for example, a management track and an engineering track), similar concepts exist in free software projects. One of the roles of a maintainer is to help contributors develop into the roles which best suit them. I’d like to explain what this means to me in my role as a maintainer of several projects, though I should mention upfront that I’m just some guy and, while I can explain what has and hasn’t worked for me, I can’t claim to have all of the answers. People are hard.
There are lots of different tasks which need doing on a project. A few which come up fairly often include:
- End-user support
- Graphic design
- Release planning
- Reviewing code
- Triaging tickets
- Writing code
- Writing documentation
Within these tasks there’s room still for more specialization - different modules have different maintainers, each contributor’s skills may be applicable to different parts of the codebase, some people may like blogging about the project where others like representing the project at conferences, and so on. To me, one of my most important jobs is to figure out these relationships between tasks and people.
There are several factors that go into this. Keeping an eye on code reviews, social channels, etc, gives you a good pulse on what people are good at now. Talking with them directly and discussing possible future work is a good way to understand what they want to work on. I also often consider what they could be good at but don’t have exposure to yet, and encourage them to take on more of these tasks. The most common case where I try to get people to branch out is code review - once they’ve contributed to a module they’re put on the shortlist for reviewers for future changes to nearby code. Don’t be afraid to take risks - a few bugs is a small price to pay for an experienced contributor.
This also touches on another key part of this work - fostering collaboration. For example, if someone is taking on a cross-cutting task, I’ll give them the names of experts on all of the affected modules so they can ask questions and seek buy-in on their approach. Many developers aren’t interested in end-user support, so getting people who are interested in this to bubble up technical issues when they’re found is helpful as well.
The final step is to gradually work your way out of the machine. Just like you onboard someone with feature development or code review, you can onboard people with maintainer tasks. If someone asks you to connect them to experts on some part of the code, defer to a senior contributor - who has likely asked you the same question at some point. Ask a contributor to go over the shortlog and prepare a draft for the next release notes. Pull a trusted contributor aside and ask them what they think needs to be improved in the project - then ask them to make those improvements, and equip them with any tools they need to accomplish it.
One role I tend to reserve for myself is conflict prevention and moderation. I keep a light watch on collaboration channels and periodically sync with major contributors, keeping a pulse for the flow of information through the project. When arguments start brewing or things start getting emotional, I try to notice early and smooth things over before they get heated. At an impasse, I’ll make a final judgement call on a feature, design decision, or whatever else. By making the decision, I aim to make it neither party’s fault that someone didn’t get their way. Instead, I point any blame at myself, and rely on the mutual trust between myself and the contributors to see the decision through amicably. When this works correctly, it can help preserve a good relationship between each party.
If you’re lucky, the end result is a project which can grow arbitrarily large, with contributors bringing a variety of skills to support each other at every level and enjoy the work they’re doing. The bus factor is low and everyone maintains a healthy and productive relationship with the project - yourself included.
Articles from blogs I follow around the net
Go’s treatment of errors as values has served us well over the last decade. Although the standard library’s support for errors has been minimal—just the errors.New and fmt.Errorf functions, which produce errors that contain only a message—the built-in error …via The Go Programming Language Blog October 17, 2019
I’ll soon be working full-time on open-source software! I’m pleased to announce that I’m joining Sourcehut. Huge thanks to Drew DeVault for making this possible. I also want to thank everyone supporting Sourcehut and allowing it to grow. Being able to do …via emersion October 15, 2019
This post gives an overview of the recent updates to the Writing an OS in Rust blog and the used libraries and tools. I finished my master thesis and got my degree this month, so I only had limited time for my open source work. I still managed to perform a…via Writing an OS in Rust October 6, 2019
Generated by openring