Variable semi-automatic learning paths

[JKrag]

It has been proposed a number of times that we should have one or more suggested learning paths. (e.g. #56 and #130 and discussed also as part of #185 and #156 )

One specific suggestion involves having a next.sh script that automatically takes you to the next kata, which would be quite nice.

While thinking about this, I suddenly had the thought that it should be possible to have variable paths, and still support a next script. One idea could be that the "Student" chooses one of more paths (through a script maybe) and this sets either an ENV variable or better a local git config property in the local git-katas repo.

Once this is set, the next.sh script can read this property to know which path the student has chosen, and then go to the next declared exercise for that learning path.

We would have "Learning paths as code" by declaring them in named files like beginner.path and admin.path or as named sections in a single path file.

I haven't really thought about the best format for these path files, but our often hated Yaml should do the job :-)

So far only a rough sketch of an idea - please contribute.

[adamatan]

Hi, Here's my response (apologies for the delay). It's a very creative solution, and would give an easy way to step to the next kata. However, I would argue that that its disadvantages overshadows its benefits.

1. Orientation: With Implicit kata ordering, there's no orientation regarding progress. The student can't tell whether they are half way through or just beginning.
2. Trackback: No clear way to reach previous katas. Even if prev is implemented, it only gives a single step, not a list of previously-completed katas. This would make sharing katas between students (e.g. Hey, I just did that in a kata 3 days ago, let me send you a link) cumbersome.
3. Terminology: Two students working on the same kata can different results for next.sh, which is confusing because the next ambiguity.
4. Student attention span and focus: Students are required to learn a lot of concepts when they dive into git. staging area, references, objects, branches - it's not trivial to keep all of these in mind. Adding another term, learning path, would add unnecessary term to their already loaded mental stack, and would divert their attention from the important ideas they have to grasp.
5. Prior knowledge: There's no clear definition of prior knowledge for each kata, because prior knowledge varies between paths.

[RandomSort]

For me this is a fun and cool idea - but perhaps with limited benefit. I think it is overkill and filled with caveats as @adamatan mentions. I'd be happy to review a POC if yhis is something you have a drive to run with :)

[JKrag]

Although I would claim that points 1 & 2 are addressable in the implementation, and having next script go different places (i.e. point 3) is the whole point of the idea :-)

But, @adamatan I hear what you are saying, and you might well be right. ;-) Or at least this is argument enough not to prioritise this task (other than for the actual challenge of implementing it ... and potential for reuse on other kata repos).

I do have a closing comment or your last 5) point. One of my main worries with numbering is that it would lead us (aka. contributors) into making too many assumptions about prior knowledge. If we all remember to keep up the promise of making as few assumptions as possible, then this might not be a big issue.