Investigate status and health of Exercism language tracks

[kytrinyx]

I've used Sarah Sharp's FOSS Heartbeat project to generate stats for each of the language track repositories, as well as the x-common repository.

The Exercism heartbeat data is published here: https://exercism.github.io/heartbeat/

The most important question that I would like to answer right now is to what degree each track is maintained, and if it is, who is actively maintaining. I've made up a scale:

• ORPHANED - Nobody (other than me) has merged anything in the past year.
• ENDANGERED - Somewhere between ORPHANED and AT RISK.
• AT RISK - Two people (other than me) are actively discussing issues and reviewing and merging pull requests.
• MAINTAINED - Three or more people (other than me) are actively discussing issues and reviewing and merging pull requests.

In addition to this, it would be interesting to know if there is any degree of activity. If here are fewer than 20 issues/PRs in the past year, the track can probably be considered inactive. (I'm making the threshold up).

For tracks that have activity, it would be useful to know if there are any contributors who should be nominated for commit.

Summary

Based on the comments below, here is a snapshot of the track health and status.

Maintained

• Ruby
• C
• Java
• Crystal
• Elixir
• Haskell

At Risk

• Swift
• Rust (but very active)
• OCaml
• JavaScript
• ECMAScript
• Python
• Scala
• F#
• C#
• Clojure
• Objective-C

Endangered

• Lua
• Lisp
• Erlang
• Go
• Factor
• Perl 6
• PHP
• C++
• Elm
• Emacs Lisp
• Lisp Flavored Erlang
• MIPS Assembly
• Racket
• Scheme
• Prolog

Orphaned

• Bash
• CoffeeScript
• D
• Groovy
• Kotlin
• PL/SQL
• Perl 5
• Pony
• R
• Standard ML

Inactive Tracks

There has not been enough activity to generate a heartbeat for the following tracks:

• Ceylon
• ColdFusion
• Haxe
• Idris
• The Netwide Assembler
• Nim
• Pascal
• PowerShell
• Purescript
• Tcl
• TECO
• VB.NET

[petemcfarlane]

PHP

ENDANGERED

To what degree is the track maintained?

7 pull requests in the past month from 5 authors

Who (if anyone) is merging pull requests?

I am the only maintainer besides @kytrinyx that has merged PRs in 2016.

Who (if anyone) is reviewing pull requests?

Mostly me again

Is there someone who is not merging pull requests, but who comments on issues and pull requests, has thoughtful feedback, and is generally helpful?

@brettsantore has contributed and has been useful, he may be interested?

[brettsantore]

@petemcfarlane Next week, I'll be able to review the track again and take a look at the common track. I'll see if I can spare some time to help out.

[masters3d]

I am not sure if something like "how many tracks is a person currently maintaining" could affect the rating but if somebody is maintaining 3+ tracks and that person leaves, all of the sudden we have 3+ tracks that go from endangered to ORPHANED. There are only so many hours in a day.

[kytrinyx]

@brettsantore ✨ that is much appreciated. If you want commit say the word!

[kytrinyx]

@masters3d That's a very good point. I'm hoping that we can put some things into place to make it more likely that all the are in a good, safe, sustainable place. Getting this overview is a first step, and it's been very encouraging to have this conversation and see how many people have been actively helping out across the board in the past year.

[kytrinyx]

Thanks, everyone, for weighing in on this!

[rbasso]

@kytrinyx, could you please add @abo64 as a maintainer in the Haskell track too?

Both @petertseng and I agree that he would be a great addition to the Haskell team, and this would also move the Haskell track from "At risk" to "Maintained".

[kytrinyx]

@rbasso done! @abo64 Thank you!

[Theodus]

@kytrinyx I would like to be added as a maintainer for the Pony track so that I can help get it off the ground.

[kytrinyx]

@Theodus done, and thank you ❤️

[joeljuca]

I would like to contribute to the JavaScript track, and I could probably contribute to the ECMAScript too. I'm not sure what does it take to become a track co-maintainer, but yeah I'm up for the challenge.

[kytrinyx]

@joelwallis 🌻 The best way to become a track maintainer is to start contributing... and then keep contributing. As a (maintainer) friend of mine once said: people become maintainers on my project when they make less work for me, not more, and when I trust them to merge pull requests.

I'm not sure exactly what type of work is going on in the JavaScript and ECMAScript tracks at the moment, but I do know that the track is actively maintained, so (1) you'd get responses to any of the questions you might have, and (2) the contributions would be much appreciated (and noticed!).

I'm sure there are issues to help triage, pull requests to help review, documentation to improve, and code to write!

Here's some high-level documentation we have about contributing to tracks: https://github.com/exercism/docs/tree/master/contributing-to-language-tracks

And here's some about maintaining them:
https://github.com/exercism/docs/tree/master/maintaining-a-track

[petertseng]

I'm wondering if we should update some track statuses in the first post (we can do so, but haven't), or if we should leave it as a snapshot of how things were, and can see how things have changed since then. I mention it because Go has about five maintainers now, and Rust has three, so they could move up.

[Insti]

It would be good to have a separate document (perhaps x-common/TRACK_MAINTAINERS.md) where we could track the current state of tracks and maintainers.

[hilary]

I think it's important to:

1. a place where we can track the (roughly) current state of tracks and maintainers, and
2. link to that place from the first post, so that people coming to this thread can easily find it 😄

[kytrinyx]

I'm going to open a new discussion about how to track maintainers. Once we figure out how we want to do it, we can update this issue with that information.

[kytrinyx]

OK, see #139

[morrme]

I'm a little late to this party but what will happen to the endangered/inactive tracks? Will there be a call for help or are you redistributing it among active contributors?

[petertseng]

I'm a little late to this party but what will happen to the endangered/inactive tracks?

Good question. #102 is where to talk about it if you have any ideas.

[petertseng]

I was going to ask whether it would be useful to get an idea of some statuses again. Was it useful to get every track's status in one place?

Recall that at #139 each track maintains its own maintainers list. Can that be automatically leveraged to get an idea of how the tracks are doing?

I see y'all want to talk about it in #191, but I had insufficient relevant material (about mentors, etc.) to contribute to that issue.

I have only this to say, regarding the health of some specific tracks I'm aware of:

I have generally felt that the per-track amount of work has increased slightly (README generation, nextercism tree structure). This takes its toll multiply on me as a maintainer of multiple tracks. A few months ago I had to make the tough decision to completely drop one of my (then four) tracks. I'm very glad that that track remains in very good hands. Of my remaining three tracks, I am now the sole maintainer on two of them, so I need to prioritise those two over the third (Rust). If things get real dicey I may even have to drop Rust as well. We in Rust are definitely letting a few PRs sit for weeks, a bad experience for contributors, but I currently can do nothing about this.

[yurrriq]

We definitely need lispers. I’m super busy lately and have all but neglected the Clojure, Racket, Scheme, Emacs Lisp and LFE tracks... its be great to see Idris get off the ground too but I just can’t really commit..

[kytrinyx]

Once I get my head above water, I intend to build some automation to take some of the burden off of track maintainers, and to keep an eye on tracks to raise warning flags when we're understaffed, and also to do deliberate outreach in hopes of finding new contributors who can grow into maintainers.

I just don't have the bandwidth for it quite yet, and likely won't until we've shipped v2.