April 09, 2017

[Exercism - Behind the Scenes] New tracks, new folks, new ideas

For the past few months I've not been on top of things in the various language tracks. Thankfully, I haven't had to. So many people are actively keeping an eye on the issues and pull requests!

After having seen consistently great contributions from a number of people, we've asked them to join us as maintainers. In the Go track tleen, leenipper have taken on new responsibilities, and balazsbotond now has the keys to both the C# and F# tracks. jtigger, who usually shepherds things along over in Java, has kicked a few things into gear in the Kotlin track, and kotp who maintains the Ruby track has also taken on responsibility for both of the Perl tracks. Oh, and Delphi Pascal. Both he and rpottsoh are heading that one up, and it just went live last week! jonmcalder has been doing a ton of work on the R track, which is just about ready to launch as well.

I have a sneaking suspicion that I've missed someone in this list—I need a better way to keep track of new maintainers so that we can make sure to celebrate everyone!

In very exciting news, this week Embarcadero awarded rpottsoh with an MVP (Most Valuable Professional) title in recognition of his work on the Exercism Delphi track. Congrats!

And then some slightly melancholy but at the same time uplifting news... The Java track is one of our tracks that has been solidly maintained for the past couple of years, which is such a pleasure (and a great relief). It's so well-maintained, in fact, that matthewmorgan has been able to gracefully retire from maintainerhood without a single hitch or wrinkle.

jtigger said of Matt's contributions:

Matt has added to the Java Track in just about every way.  One of our earliest interactions was on the Java track itself as we found a common curiosity exploring nucleotide-count, looking for what performance we could get out of the Streams API — that was ridiculous fun for the both of us.  His first PR was adding pangram to xJava. Today, he's a top 10 committer.  More recently, Matt has been a skilled mentor for contributors to the track, exemplifying the way we are, here at Exercism: treating every one with respect while holding them to a high bar of quality (that's just how he is).

For eleven months we ran what we referred to as "The Matt & John Show": a video hangout where we tackled all kinds of challenges on Exercism.  We dipped our toes into machine learning (specifically natural language processing), mapped out all parts of contributing to Exercism, and did our best to bring some structure/organization to the track.  If you benefit from structure around here, know that Matt had a solid hand in that.

I would love to get to the point where we have so many people actively maintaining each track that nobody, ever, feels any twinge of guilt at moving on when they've had their fill.

New Features & New Ideas

We have a common pool of problem descriptions, which each language track can create implementations of. Until recently there was no way to create a special exercise just for one programming language. This isn't always the best approach, since some languages have unique (and sometimes peculiar) features. It makes sense to allow those languages to have unique (and perhaps peculiar) exercises, without adding noise to the common pool. We (finally) support track-specific exercises, thanks to the efforts of ianwhitney.

Our first GitHub bot is going to go online tomorrow. We've had help from 
Rikki the friendly neighborhood nitpicking bot in a few of the language tracks on Exercism, but we've not had any help from bots on the GitHub repositories themselves. This bot, probot/stale, will help close stale issues.

"Stale" means that there's been no movement on it for some set period of time. By default that is 60 days, but we're going to start with 6 months on the main Exercism repository and then work our way down. The bot will comment on the issue, marking it as stale, and if there is no further activity on the issue in the next 7 days, the issue will be closed.

"Stale" doesn't mean that it's not important, or that it will never be worked on. This is a bit reminiscent of the idea of "inventory" in Lean Manufactoring: you don't want a lot of inventory. In agile development methodologies, teams are encouraged to keep their back logs short. By keeping a fewer number of active issues, we hope to make it less intimidating to comb through the list of open issues to find something that can be worked on, making it easier to begin contributing to the project.

Somewhat related to stale issues, we've had a lot of issues that are vague and hard to tackle. Sometimes they're problem statements without a recommendation, sometimes they're wishful thinking without a concrete outcome. We've gotten better at describing the problem to solve and the solution in the past few months, so a lot of stale issues will likely take a lot of these vague issues out of the mix.

When new issues get posted that are more about figuring things out and making decisions we'll move them over to the "discussions" repository, leaving all the other issue trackers as actionable as possible.

Happy hacking!