October V3 Concept Blitz

[TheLostLambda]

During the latest Exercism maintainers call, the idea was floated that – to rebuild some momentum for V3 – all of our active maintainers would direct their efforts towards progressing a single track. The idea is that, by bringing all of our active maintainers together, we'll all have quick access to feedback and motivation from others. Once the sprint is complete, we'll all have collectively brought a track from start to finish and will (in theory) be able to take this experience back to our own tracks.

On the other hand, the case could be made that, in the short term, this sort of radical refocusing could leave many tracks even more neglected than they already are.

There are a couple of major questions that still need answering:

1. Is this really something we want to do? What are the pros and cons of redirecting everyone to a single track?
2. Which track would we start with? We need to be sure the maintainers can take the load. Ruby and JS have been proposed.

[NobbZ]

The problem I see with this is, it would probably help the mainstream languages to get closer to something that could be presented at v3.

Though all the nice niche languages, which always have been the reason for me to be enthusiastic with exercism.io, wouldn't gain mauch from it. I think they would even suffer from this. As the one or two people working on them (if at all) would be drained to another project.

And as there seems to be a huge library of concept exercises already, their problem is not really the creation or translation of the exercises. It is probably getting analyzer and test runner implemented.

[TheLostLambda]

Hmm, interesting! Perhaps I've been a bit self-centred. I'm maintaining of the more "niche" tracks, Common Lisp, but I think the biggest challenge for @verdammelt and myself has been creating the concept exercises, not the tooling. I'd be quite interested to hear what other "niche" tracks think is the central thing holding them back.

With that being said, it's quite valid to debate whether this will only benefit the large tracks or whether it helps train up maintainers for the smaller tracks as well. I agree with you, we already have a couple of big tracks nearly ready, so I'd only really be interested in this if it helps all of the languages.

I personally think having the whole community to help review PRs and sharing how they come up with exercises would help me become better at exercise creation (and not just porting), but that could just be me.

Thanks for sharing your view on things! I'm quite interested in what other "small" track maintainers think as well :)

[SaschaMann]

sharing how they come up with exercises would help me become better at exercise creation (and not just porting), but that could just be me.

That can also be done by implementing an exercise in two languages that share a certain concept together with another maintainer. Each person implements it in their own language, but you try to come up with a similar example, story etc. together. That way you actually progress on your own track but still get to share that creation process.

[wneumann]

Let's start to my answer to question number 2 first:

I honestly don't care; I don't think that I would be any more or less receptive to the idea no matter what the language is, even if it were Swift, which is what I am working on now. And I don't really know that one language is easier or more deserving or whatever than any other.

Having said that, let's move on to the first questions.

Is this really something we want to do? What are the pros and cons of redirecting everyone to a single track?

I a -1 on this proposal for a number of reasons.

The biggest reason is that, depending on the language chosen, I may not be able to contribute in any meaningful way. If it's not one of the couple of languages I use regularly, my lack of familiarity with the language would both increase the amount of time and effort required to write a concept exercise and decrease the quality of the output, while at the same time taking cycles away from a track that I can contribute meaningfully to.

If it's a language I'm particularly unfamiliar with, the result would essentially be that of asking an Exercism student to write the concept exercises for a language that they are learning. This is especially the case as one gets deeper into the concepts graph where languages tend to diverge more and more.

I also have concerns about making sure that the exercise works within the progression flow of concepts for a track. This stems from issues I had earlier with the Swift track, where loops were created in the concept's prerequisites primarily because of the way Swift treats strings which led to issues involving them, optionals, and conditionals. I'm familiar with the language and still fell into the prerequisite loop pit because I included the wrong bits of functionality in an exercise. This is especially the case for languages that are fairly different at a paradigm level where different concepts may need to be introduced in different orders. I can picture falling into traps like that much more easily if one isn't familiar with a language, if one isn't familiar with the track to know what's been covered already, and if multiple people are working on a sequential structure in parallel.

Having said that I'm having trouble thinking of what would work better. Perhaps something more along the lines of nightly or bi-weekly check-ins where we announce what we're working on, where we are, what issues we're encountering and then others who might be able to help can add their suggestions.

Perhaps this can be done via draft PRs, I'm. not sure the best way to handle it. The main downside to this is it can't be done in parallel, it would require a commitment from a lot of people to collaborate with a lot of different tracks. On the plus side it would probably make Erik's job a lot easier come exercise review time. Plus, the more exercises there are, the more stories and variations on stories there are (incidentally, I need to add a couple of my stories to the repository), which makes it easier for other tracks to build their exercise via forking.

[iHiD]

OK - so having read all of the above (thank you - very helpful!), a suggestion:

• Let's say we have a specific team who agree to do this. Let's say this is 15 individuals.
• Each week we choose a language to work on (e.g. 1. Ruby, 2. Lisp, 3. JS)
• The week before that week, the upcoming maintainer spends the week preparing, and outlining 13 exercises to work on (so during week 2, the JS maintainer wouldn't contribute, but would ensure there are 13 JS CE issues).
• During the week, the language-maintainer for that week is responsible for doing PRs and guiding the rest of the maintainers.

We would shape it so that the aim was to get a base set of PRs in place, each with an example, introduction, instructions and tests. The maintainer might want to improve all those etc, but we can then focus January on building on that work.

If 15 of us did this, we could get a base across 15 languages. And if a Lisp maintainer was part of the 15, then Lisp would get worked on, etc. So the esoteric languages wouldn't get left behind.

The key to this working would be the maintainer having a solid plan for the week before we got to it, with the right concepts in the right sort of order and the right vague ideas for exercises that would fit.

Obviously, not all maintainers have to do it - if they just want to work on their own tracks in isolation, that's fine, and we can still catch up on everyone's progress on the Friday calls, but it would give a small core group something to do together.

Thoughts?

[SaschaMann]

Thoughts?

GitHub lacks an appropriate reaction emoji: 🤷‍♂️ Meh, I don't care about it (as in: I wouldn't participate but I also don't have any reasons against it)

[iHiD]

OK - so building on Sascha's comment, are there 10-15 people who would choose to be part of this if we did it? 🙂

[angelikatyborska]

I would be a bit worried about doing 13 exercises in parallel. My experience from working on the Elixir track is that it's hard to accurately plan which concepts are actually going to be prerequisites before having written the example solution. It's also easier to decide on what the exercise is supposed to be about and trim down its scope when you can see the tree of concepts that were already implemented and how they depend on one another.

[TheLostLambda]

OK - so building on Sascha's comment, are there 10-15 people who would choose to be part of this if we did it? slightly_smiling_face

I would be up for giving this a try, if other people are!

[mikedamay]

I am strongly in favour of this approach (10-15 people working on a track). Having said that Ruby might be something of a challenge for me, say, compared to JS, but I would give it a go.

I think having an achievable cross-team sub-goal like this would be beneficial for overall productivity. Working through the bulk of the C# track on my own was a slog (even with the excellent support of @ErikSchierboom)

[ynfle]

I'm personally more inclined to work on a track that I'd want to complete and have a vested interest in completing.

I'd say a big blocker for has actually been writing the concepts exercises (which may subside after writing many of them). I'd like to/suggest that we pair up and work through exercises on a track that we'd have a common interest in where we'd complement each other's skills.

[ynfle]

https://exercism-team.slack.com/archives/CR91YFNG3/p1602536787187400 For more discussion