Freeing our maintainers: Exercism-wide changes to track repositories

After nearly 10 years of building an amazing platform powered by volunteers, we want to take a little time out to consider how to make volunteering in the next 10 years the best experience possible. As part of this work, while we’re taking time to think, we are making a few changes to free up maintainers to recover their energy, work on the fun parts of developing Exercism tracks, and/or join in our thinking about how to improve things.

This post is about getting the practical details sorted out for the tracks.

Our blog post provides more context. Please read it, if you haven’t already.

Pausing community contributions

For most repositories across Exercism we will be adding a workflow that automatically closes issues and PRs submitted by people who do not belong to the Exercism organization.

If you wish to accept community contributions, please reach out to @jonathanmiddleton as explained in the blog post. We will be merging this workflow on Dec 1st if we’ve not heard from you. This is not set in stone, of course, and should you change your mind about community contributions later, please reach out to us.

Note that adding content for the Dig Deeper feature such as Approaches and Articles falls outside the scope of this. All tracks regardless of their status will be open for contributions to Approaches and Articles.

Actual usage of the track will also continue as normal - a student’s experience will remain unaffected. So there will be no changes to mentoring, and mentors with “supermentor” status can continue to give feedback to exercises through the Representer UI.

What do we do about open PRs?

If there are open PRs that add new exercises, either make the changes yourself to get them to a mergeable state and merge them, or close them with the paused label. Remember that we are not aiming for perfection here. You can always iterate on exercises to improve them.

For PRs that add new Approaches or Articles, these should follow the guidelines for optimistic merging provided in the blog post.

Any other PRs that you don’t want to deal with in the next 6 months should be tagged with the paused label and closed. Closed PRs can be reopened later.

What do we do about open issues?

If you are not accepting community contributions, all open issues that you as a maintainer do not plan to work on in the next 6 months should be tagged with the paused label and closed.

What will we as maintainers do if we’re not dealing with community contributions?

The short answer is: whatever makes you happy!

If getting deeply nerdy and technical makes you happy, maybe you want to write some Representers or Analyzers for the track. Or you could add more exercises.

You might want to write Approaches and Articles for the new Dig Deeper tab for exercises in the track.

If you are a mentor on the site and have earned “supermentor” status, then providing feedback on exercises through the Representer UI is another valuable way to spend your time.

Both adding Dig Deeper content and providing feedback through the Representer UI provide a huge amount of value for a moderate amount of effort.

Alternatively, if you wish to take a sabbatical for the next few months, that’s totally fine (and, indeed, encouraged). Let us know so we can remove you from the maintainer team while you are away. After you’ve had a nice break and are ready to get back into things, let us know, and we’ll add you back. You are always welcome!

What happens next?

On December 1, 2022, if we have not heard anything from any maintainers we will tag the repository with community-contributions-paused and merge the workflow PR.

If you wish to accept community contributions, please reach out to Jonathan.

Please also reach out if:

  • you wish to take a sabbatical.
  • you are the sole maintainer of a track and wish to make it easier to work autonomously in the track. We can adjust some of the settings to remove friction.
  • you have some regular contributors that you’d like to continue receiving contributions from. We can add them to the organization, that way their issues and PRs will not be automatically closed even if contributions are paused overall.

If you wish to discuss things in this issue, please do so below or reach out to @jonathanmiddleton.

Finally, thank you for everything you’ve put into Exercism so far. We’re really excited about how we can make volunteering on Exercism an amazing experience for the next 10 years!


Since DMs are disabled here in the forum, @jonathanmiddleton how would you prefer to be contacted?


I think I found it:

And in blog post:

please reach out to Jonathan Middleton on Slack

I’d like to opt out of this in the jq track. I closed the PR there. Is that OK?

Some feedback from a maintainer:

I would just like to share that my burnout of the Dart track didn’t really start until around the time of the V2 to v3 migration.

Initially we were told tracks could come up with the concept exercises on their own. It took me some time to develop the first proposed concept exercise, when I was ready I learned that the direction had changed.

And that happened a few times during the migration from v2 to v3, that I just didn’t want to put in the work not knowing if the guidance would change again.

How I would like to contribute is on implementing exercises, updating exercises based on evolving specs, and improving the contribution experience for non-Exercism org members.

I think a hybrid of the OSS model could be helpful with certain Exercism members responsible for documentation, concept exercise specs, practice exercise specs, etc. So while track maintainers may focus on whatever elements work best for them, Exercism as a whole still has a team measuring progress/activities in the rest.

The only reason I did not leave the track is due to support from Exercism leadership to stay and to just focus on what I wanted and to ignore the concept exercises if that was too much for me. I really appreciate it.

I think this is a good period for Exercism to assess how to achieve its goals.


I’d like to thank the Exercism admins for all of this. There are times when I also felt burnt out but ultimately didn’t leave Exercism because I still believe in the vision of making the best online platform for learning code and I trust the Exercism leadership to have our back and make changes when needed. This blog post is a prime example of that. I could relate to everything said there and it’s great to see such a good understanding of our pains as maintainers/mentors.

For the Go track, we’ll stop taking contributions.

For the Java track, I’ll still take contributions, at least for now, although might take me a while to get to them. The contributions to the Java track lately are very welcome as they are relatively easy to review and tackle low-hanging fruit that greatly improves the track. They also save me a lot of work, I don’t feel at all that the time spent reviewing them is greater than the time it would take me to make the changes myself.


I’d like to opt out of this in the ABAP track


I would like to opt out of this for exercism/pr-commenter-action. It’s not part of the Exercism product, it’s used by many people outside of Exercism, including my team at work, and I would like it to continue running it as other OSS projects (already wrote about this in private to @jonathanmiddleton).


I’ll post here too (already DMed @jonathanmiddleton on slack but want to make sure its seen seeing as the merge date isn’t that far away). I’d like to opt-out for the V track because 1) I am happy reviewing community contributions and whatnot and 2) not a lot of contributions to review so it doesn’t take a lot of time

Speaking of which: if you’re looking to contribute to a track for the V language, check out the link above :smile:


Similarily, I just DM’d @jonathanmiddleton via slack.

There are so little contributions to the Erlang track at all, that I do not raise the bar for conttributions…

The bar is already quite high and changing that would imply changing the language to JS, TS, or something else mainstream.

Therefore I do not want to raise that bar even further. I can handle those 2 pass by contributions per year easily.

1 Like

Morning, thanks for everyone who responded.

I’ll be going through all the communication today to make sure we’re all on the same page :smile:


Hello @jonathanmiddleton ! We’d like to opt-out from pausing contributions for Pharo track! Community is really small, so for similar reasons as stated above for Erlang.
Is this enough, or mail/slack message is necessary?

ABAP track is handled without problems using GH issues and PRs. Pushing things to a forum will complicate the process and raise the potential of losing contributors and maintainers who are already on GH (no one has time to check more places).

+1 opt-out ABAP track. Thank you!

1 Like

Hi @jonathanmiddleton
We’ve discussed this with Cedd and Jeremie and we’d like to opt-out from pausing for the Elm track.

1 Like

I’ve tagged the following repositories as community-contributions-accepted, and have closed the corresponding workflow PR without merging it:

  • pr-commenter-action
  • abap
  • abap-test-runner
  • awk
  • awk-test-runner
  • bash
  • bash-test-runner
  • bash-analyzer
  • elm
  • elm-test-runner
  • elm-analyzer
  • elm-representer
  • emacs-lisp
  • emacs-lisp-test-runner
  • erlang
  • erlang-test-runner
  • erlang-analyzer
  • erlang-representer
  • gleam
  • gleam-test-runner
  • java
  • java-test-runner
  • java-analyzer
  • java-representer
  • jq
  • jq-test-runner
  • pharo-smalltalk
  • pharo-smalltalk-test-runner
  • red
  • red-test-runner
  • red-analyzer
  • red-representer
  • rexx
  • sml
  • sml-test-runner
  • vlang

I have a pending question about the Elixir repositories, so I will wait to process those.

Aside from the Elixir repositories (elixir, elixir-test-runner, elixir-analyzer, elixir-representer), are there any other repositories that I have missed?

I will wait to merge the remaining PRs until tomorrow (Friday, December 2nd 2022), as I want to be sure that nobody’s requests have fallen between the cracks.


Just to be sure, is it still ok to create small PRs (e.g. correcting typos, adding a [UseCulture] flag to a test file, or maybe adding a missing explanation to a file) if that language is not listed above? (To be specific, I’m talking about csharp)

And if so, should i first open an issue (should it be on github or only in this forum) or can I create a PR directly?

@dorianignee In general it depends on the track. I’ll let @ErikSchierboom answer that for C#. Thanks for checking :slight_smile:

1 Like

Very late to the party. The cleaners are in sweeping up the last of food wrappers and hosing down the steps.

Please @kytrinyx , can you tag the 8th and openeuphoria tracks as community-contributions-accepted

Thanks in advance.

1 Like

@dorianignee Yes that’s fine!

1 Like

I am also late to the party, I would like the main crystal repo(not the test-runner) to be marked as community-contributions-accepted.

Thanks in advance.