FOSS contributor tracks

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.

Articles from blogs I follow around the net

This post gives an overview of the recent updates to the Writing an OS in Rust blog and the used libraries and tools.
I was very busy with finishing my master's thesis, so I didn't have any to implement any notable changes myself. Thanks to contrib…

This is an archive of a series of comp.arch USENET posts by John Mashey in the early to mid 90s, on the defnition of reduced instruction set computer (RISC). Contrary to popular belief, RISC isn't about the number of instructions! This is archived her…