Rethinking the order of the exercises

[emcoding]

Related #815

Currently, I am going through the flow of the exercises per request of @hilary and after several interesting conversations on Slack :-)

The greater goal is to have topics that will work for the new exercism design and that cover the core concepts of Ruby. In a way that is most helpful to the students and a pleasure to mentor.

Elsewhere I spoke about my concern that some of the exercises unlocked by 'hello world' are really complicated, and I am worried that this will put off people. I'd hate to lose students because they think: "O, if I can't even solve the first exercises, this is not for me." Or worse.

Short term goal

What I'd like to do as a first step, is mark a few really simple exercises to be unlocked by hello world, and just move all the other side exercises 'one level up'.
(See Question 1 below)

Long term goal

As this is my first steps in being involved in the track flow, I'd like to check if this is the right direction.

Here is an illustration of what I am thinking for the start of the track. (With only a selection of the relevant exercises, to keep it clear.)

• In the first column, we have the simplest exercises, preferrably oneliner methods.
  It should touch the different data types with some simple data manipulation. In this stage, students will get familiar with Exercism, with mentoring and probably mainly style things.
  Mentoring is very fast, in my experience with TwoFer it is mostly "Great!!"s and sometimes someone needs more attention.
  (As a side note, I know Exercism is not meant to learn Ruby, but I really think this first level start is useful anyway, see thoughts hereafter.)
  More advanced students, maybe coming from different languages, will burn through them, and yet get early feedback on the Ruby way of things.

• The second column are exercises with one step more: like Error handling, and most important: iterations. This means that if a student is not familiar with the Enumerables, and for instance doing for loops, the mentoring is still straightforward. Focus is on the basic Enumerable methods, for basic iterations.

• That means when we arrive at the third column, with something like Grains, we shouldn't have to point them to basic Enumerable methods anymore, but can discuss on a higher level: iterating over all the chessboard fields, or optimize by using math.
  Other candidates for this column are exercises where more advanced Enumerable methods are helpful.
  Also, exercises where the organisation of code is addressed.

Interesting: Currently, Hamming is coming before RNA transcription. I think with this ^ set up, it would probably be the other way around: RNA as the first exercise with a RegEx and advanced String methods screams Middle Column , and Hamming with the more advanced Enumberable#zip method could be Third Column (or also Second, because of the low difficulty).

Question 1: The short term goal
Can we do an isolated step first, to match the short term goal? That means mark only the first exercises (left column) as unlocked by: null, and move all the other (side) exercises up to a next level exercise.
Without changing the core exercises yet, just move them up to be unlocked by either TwoFer or Hamming

Question 2: The long term goal
What do you think about this kind of building-up? Is this a viable approach?

Question 3: Long term goal
I'd prefer to make all the exercises in the middle column core exercises. I'd think that mentoring can be done very fast in most cases. And if it cannot, it is for a good reason, and it is good to catch those early, and not in more advanced exercises. What do you think?

[Insti]

Hi, Welcome, Thanks.

The Ruby track could do with better organisation of its exercise tree.

There is a philosophy document somewhere that outlines the purpose of the tracks. (Help me find it.) Edit: Probably this one: Meaningful and Flexible Linear Progression in Exercism

As I recall it goes something like this:

By completing the track of core exercises you get an overview of the different aspects of a language, they start off easy and get progressively harder. By completing a track only doing the core exercises you should end with a broad experience of the language.

The branch unlocking gives you something to work on while you're waiting for your core exercises to be mentored.

The only things I'm certain of right now are:

• Hello World should be the first core exercise and not unlock any further exercises, it gets auto-approved.

• Two-Fer should be the next core exercise. You get access directly after completing Hello world

Answers to your questions:

Question 1: - Probably not.
I'd like to see as wide a selection as possible of exercises available as bonus exercises.
Basically everything that isn't explicitly added to the tree for some educational purpose.

Question 2: - Probably.
Building up the exercises around the core is a good idea. But maybe only to a max of 5 topic based unlocks per step.

Question 3: - I think we have a philosophical difference.
As I understand it you want to make all the "easy" exercises for each topic core exercises and make them unlock harder exercises. I do not think this is the right thing to do.
There is scope for better difficulty tagging of exercises to identify easy/hard exercises.

P.S.
The Ruby track is currently a little screwed up see: exercism/exercism#4096 (comment))

[emcoding]

Thanks @Insti for your comments, much appreciated.

Re: the short term goal (make a few exercises available in the first steps of the track, and move harder ones up.)

I'd like to see as wide a selection as possible of exercises available as bonus exercises.

Is that a different opinion than (Copied from #815):

We should have 4 or 5 exercises that are "core": false, "unlocked_by": nil. These are bonus exercises that will be available as soon as you join the track, along with the first core exercise.

Because that is what I propose the 5 exercises in the left column for.

Is there a difference of opinion on how many that first batch should be? Or did I misunderstand your comment?

[Insti]

Is that a different opinion

It would seem so.
I'm not sure what to do about that.

What V1 of Exercism was and what I think Exercism should be seems to be very different from the direction it is now taking, so maybe I should step away.

@F3PiX I encourage you to make PRs with the changes that you think need to be made.
As long as they are small and don't change too much at once they should be easy to merge.

[Insti]

@F3PiX, This thread over in the csharp track is also looking into exercise progression, it might be worth checking out exercism/csharp#611 (comment)

[emcoding]

@Insti O thanks 🙇 That's good to know.

[emcoding]

This is mostly old news, closing this issue.