FOSS contributor tracks

Published 2019-07-29 on Drew DeVault's blog

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
  • Marketing
  • Release planning
  • Reviewing code
  • Translations
  • 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.

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/ [mailing list etiquette]

Are you a free software maintainer who is struggling with stress, demanding users, overwork, or any other social problems in the course of your work? Please email me — I know how you feel, and I can lend a sympathetic ear and share some veteran advice.

Articles from blogs I follow around the net

Updates in March 2020

This post gives an overview of the recent updates to the Writing an OS in Rust blog and the corresponding libraries and tools. I focused my time this month on finishing the long-planned post about Async/Await. In addition to that, there were a few updates …

via Writing an OS in Rust April 1, 2020

Wayland clipboard and drag & drop

Clipboard and drag & drop are arguably one of the most complicated parts of the core Wayland protocol. They involve a lot of back-and-forth communication between three processes: the application where some content has been copied, the compositor, and …

via emersion March 26, 2020

Go, the Go Community, and the Pandemic

Go always comes second to more basic concerns like personal and family health and safety. Around the world, the past couple months have been terrible, and we are still at the start of this awful pandemic. There are days when it seems like wo…

via The Go Programming Language Blog March 25, 2020

Generated by openring