May 07, 2017

[Exercism - Behind the Scenes] The challenge of unmaintained and undermaintained tracks

We have over 60 language tracks. Of those, 35 are active on the site. The rest are in the works to some degree or other. Each language track lives in a separate repository, which makes it easier to manage, maintain, and contribute: you can work on C# stuff without knowing anything about Elm or Haskell.

In a perfect world, each of these repositories would have at least three active maintainers. Something magical happens when there are three people who all care about a track at the same time. The discussions become rich and lively, and a ton of interesting work gets done. The quality of the track tends to skyrocket when this happens.

Fewer than three doesn't mean that a track is unmaintained or undermaintained, but it does mean that the track is at risk. With two active maintainers we usually find that the work gets done. Issues get responses, pull requests get reviewed and merged or closed. Support requests get handled. But with two people there are just not enough different perspectives to spark the types of discussions that causes a track to kick into high gear. And worse: it just takes one life event, or one person moving on to end up with a single active maintainer. Maintaining a track alone can be a lonely burden. The lonelier and burdenier, the more likely the track is to end up orphaned.

Orphaned tracks are a problem because it's a prime way to disappoint people. People open issues and submit pull requests and it can take weeks or months before they hear back. If at all. That's a terrible experience, and we're losing great contributors.


Three maintainers per track, 61 tracks. That's 183 people. Some maintainers actively keep an eye on multiple tracks, so we would probably be fine with fewer than 180 people. 150 maybe.

We have nowhere near 150 active maintainers at the moment.


There's been a lively discussion recently about how to tackle the problem. The big questions are:
  • How do we detect that a track is in trouble?
  • If a track is un(der)maintained, how do we set expectations so we don't disappoint contributors?
  • What is the process to transform a dormant track into a thriving one?
There are some great ideas in the discussion. We might actually figure this out.

If you have any thoughts on the subject, please jump into the thread in https://github.com/exercism/discussions/issues/102. Even if you don't, it's a great read.