The Ruby Track Anatomy

[kytrinyx]

The Track Anatomy Project has been well underway for Ruby for a while now. This issue provides an overview of the project, and what contributors can expect to see throughout the process.

Background

Rationale

Our research has shown that having a suboptimal track structure causes frustration for students and a significantly worse experience for mentors. The primary cause of this is that historically Exercism exercises were not implemented with any particular purpose in mind. Both exercise choice and sequencing were mostly incidental. In the past couple of years, we've come to understand that the principal purpose of Exercism is to optimize for achieving fluency. Reworking the tracks with this focus improves the experience for both students and mentors.

The project

A while back we spun up a project to tackle these problems. We've named the project the Track Anatomy Project, and you can read more about the background in the introductory blog post.

The goals of the Track Anatomy Project are:

• to design the optimal path for progression throughout the track. We want to make sure that the key topics are covered explicitly, in a suitable order.
• to ensure that progression is consistent across language tracks (where appropriate).
• to optimize the track for fluency in the data structures, language features, standard library, and conventions/idioms of the language. Fluency means that the goal is for the student to be able to express themselves comfortably in the basics of the language and that their code should not be jarring to experienced users of the language. It does not aim to teach people to get better at programming (though that is sometimes a side-effect).

The tool

To reach these goals, we've developed a tool to help maintainers work through the restructuring step by step. The working title of the tool is The Track Anatomy Tool.

The task of restructuring a track is significant. To make this restructuring achievable, we've split the process into several phases, where each stage addresses one specific aspect of the restructuring. Together, the phases work from coarse-grained to fine-grained, and from the beginning of the track to the most advanced exercises. The end result will be a restructured track, with a list of improvements that need to be made, as well as a set of guidelines for the track to make it easier to make decisions about suggested improvements in the future. The methodology is the same for all tracks. The outcome is different for each language.

We have been testing the tool on the Ruby and C# tracks, and so far it has resulted in dramatic improvement for both students and mentors.

What this means for the Ruby track

The Ruby Track was the starting point for the Track Anatomy Project. We asked Maud (@F3PiX) to take the Ruby track and make it our exemplar.

Many small PRs

The restructuring process results in a lot of small PRs.

We encourage this project to be run like a series of refactorings: small and regular changes, where we address the simplest problems first, without striving for perfection. After each change is merged, we monitor the results and tweak based on our findings. Then we make the next small change.

We focus on the core progression first, either leaving the side exercises alone or taking pragmatic actions to redivide them. The side exercises will be addressed in more depth later on.

The process gradually builds up a big picture that will not be discernible in any single pull request. This big picture is never clear at the start of the restructuring; it gradually develops as the maintainers work through each phase of the process.

This means that unlike most earlier work on Exercism language tracks, individual pull requests will be more difficult to discuss as one-offs, as they tie into a large, complex, and often unclear picture. We understand that this can be a bit disconcerting for contributors who are not deeply involved in every step of the Track Anatomy Project for this track but ask for your trust in the process.

Mildly confusing for students

The changes typically lead to some confusion for active students, due to changes in the order or the state (core/side) of exercises. We have decided that the advantages of the small changes outweigh the confusion they may cause.

How can you help and contribute?

Most changes are first and foremost pragmatic choices, based on what the tool is asking. None of the changes are final, and none of them pretend to be the perfect solution to all that matters in the track.

To help this process along, we ask that you give the maintainers who are working through the tool room to experiment. In PRs, help find technical and mechanical problems and clerical errors rather than questioning the underlying reason for the change.

Keep an eye on issues with the label Track Anatomy. You can contribute by implementing new exercises, or researching how such an exercise can be solved in your language. Since the main focus of the tool is on the core exercises, it would also be valuable to help address issues in the side exercises that happen as a side effect of restructuring.

Most importantly, you can help by mentoring, improving mentor notes, and providing feedback on your mentoring experience as a result of the implemented changes. Let us know if mentoring got easier or harder, more fun or less, and share your observations about the result of a change, either in issues here or in the Slack track channel.

Final thoughts

We are fully aware that the tool is a black box, and the inner workings can seem mysterious. We're not being secretive, it's just a matter of (a) mental bandwidth and resources and (b) things are changing so rapidly that documenting them is very hard.

Our primary focus is to facilitate the folks who are working through the process on the track, and we ask for your patience in the process.

We're confident this will lead to the best outcome for the Ruby track! If you have any questions, please ask them here :)