Add FOSS contributor tracks article

1 files changed, 79 insertions, 0 deletions

diff --git a/_posts/2019-07-29-FOSS-contributor-tracks.md b/_posts/2019-07-29-FOSS-contributor-tracks.md
new file mode 100644
index 0000000..5369123
--- /dev/null
+++ b/_posts/2019-07-29-FOSS-contributor-tracks.md
@@ -0,0 +1,79 @@
+---
+layout: post
+title: FOSS contributor tracks
+tags: [maintainership, free software]
+---
+
+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.