Track Anatomy Project Update April 2019

project_update_2019_4.md

The state of things in the Track Anatomy Project

For the background on the project, see Track Anatomy

What we currently have:

• A prototype of a Track Anatomy Tool, which is meant to help one maintainer per track to create an initial Track Anatomy. The end result is a big 'table' of all the exercises, with their key features and how they are related to each other. This is also the starting point for continuous improvements to the track. (We need to find a good name for the resulting 'Table'.)

• The prototype is not scalable yet, so we started with only a small group of tracks to test the workflow. Currently: Ruby, C#, Javascript, Rust, Elixir, Python, Haskell (and, unofficially, Typescript). The Tool is divided in 5 'Rounds'. Each round results in one or more smaller PR's. Ruby is my 'sandbox' for all things Track Anatomy. C# was the first other track involved, and @erikschierboom the only other one who worked with the predecessor of the current tool. The first version was a Google Spreadsheet and a pain to work with.
  The tracks were invited because of one of two reasons: either the track was in dire need due to an overwhelming mentor queue, or we thought it had characteristics that made it an interesting addition for the Prototype testing stage. Prolog, for instance, had no core exercises at all, only side exercises, so it was interesting to see what the Prototype would offer in such cases.

• All of those tracks have finished Round 1 of the Tool, meaning an initial reordering of the exercises from easier to harder, and removing math-y and 'DIY' exercises. ('DIY' stands for reimplementing features that are in the standard library of a language.) Sometimes we chose to leave those in, and sometimes the relative difficulty is debatable, as this round is meant to be a quick fix for the most obvious obstructions in a track.

• Some of them have also finished Round 2. Round 2 focuses on the beginning of the track, with the easiest exercises. Right from the beginning we realized that there are not enough easy exercises available; that's why we created some. Thanks to @pedrogaspar and @erikschierboom we now have HighScores and the first 2 of the Resistor Series. :yay: As we strive for quick and fast iterations, Round 2 will not remove all the obstructions at the beginning of the track, but the results show that mentoring is way easier after Round 2, and most mentoring queues become manageable. In general, Round 2 results in several smaller PR's, ideally with one exercise added to the core and one removed. Meaning that each PR makes an improvement to the track. Even if the immediate improvement is not always clear looking at that one PR. And as life is, sometimes it's a pragmatic choice, so we can keep the speed up even if it's not the perfect solution yet. From this Round on, taking care of Mentor Notes and start implementing not-implemented exercises is part of the job too. Sometimes it is done by the maintainer theirselves, sometimes they open issues for it. (If you want to help out, look for issues with the Track Anatomy label on your language's repo.) Currently finished Round 2: Ruby, C#, Javascript. Currently working on Round 2: Rust, Haskell Next to start Round 2: Python

• Only Ruby and C# have finished Round 3. Javascript is on the verge of starting. Round 3 focuses on the 'mid-level' exercises, between the easy exercises at the start, and the advanced exercises at the end. This Round is real fun, because a) it's much easier than Round 2, b) there are far more exercises to choose from, c) it feels like it's making a bigger difference.

• Round 4 is mainly about the most advanced exercises, and other aspects of the track as a whole. Currently only Ruby has gone through round 4, and even that is partially.

• Round 5 is setting up things for the maintenance stage/future/continuous improvement. The next step in Ruby is to find out how we can share the Track Anatomy, initially with the other maintainers, and how we can make it such that it's a good instrument for maintainers, mentors and contributors.

Next steps:

• We decided that the Ruby track needs to be prioritized at this moment. As Ruby is the sandbox for the project, we need the results of the Ruby track to push the Track Anatomy Track further. Now that the track has gone through a first pass of Round 1 through 4, new bottlenecks become apparent, and the next step is to find out how to handle those, and what it means for other tracks.
• To solve the bottlenecks, we need to define some more formal metrics, so that we can monitor the effects of changes to the track. We explicitly asked the Track Anatomy maintainer to go with their gut feeling, and/or make pragmatic choices. But at some point soon, we want to know if a change was an improvement or that it did nothing for either the student's or the mentor's experience. Defining metrics is the next priority for the project.
• We want to find out what is the best way to share the Track Anatomy, and how tracks are going to work with the Track Anatomy.
• The next priority are the rest of the tracks that are currently going through the Track Anatomy Project. The first step is quite administrative: all of them currently have their own version of the Tool, and I'm working on creating one template that all the tracks can work with. That's mostly to avoid that I have to copy/paste changes and improvements into multiple documents. When the main template is ready, the tracks can all go through the next rounds in their own time.
• Then, in order to make the Tool available to all the other tracks, it needs to be transferred to a scalable version. We're still thinking about that; one of the options is to add it to the Exercism website, maybe or maybe not in a dedicated Maintainers Tools space.