search

exercism / discussions

For discussing things like future features, roadmap, priorities, and other things that are not directly action-oriented (yet).
37 stars 5 forks source link

Problem ordering, topics covered, and understanding of concepts required #60

Closed kytrinyx closed 7 years ago

kytrinyx commented 8 years ago

For the past three years, the ordering of exercises has been done based on gut feelings and wild guesses.

Over time this has proven to work OK-ish, but it's not great. There are easy exercises that get placed too far back, exercises that are too similar to one another, and exercises that are too difficult that end up early in the track, and we mostly don't notice until someone says out loud that they're struggling with something.

@IanWhitney did a thorough analysis of the rust track in https://github.com/exercism/xrust/issues/127, which resulted in reordering the exercises. He wrote about the experience in an essay called Exercism Shouldn't Make You Cry

We're also talking about similar issues in F# (https://github.com/exercism/xfsharp/issues/133 - @ErikSchierboom) and Elixir (https://github.com/exercism/xelixir/issues/190 - @devonestes), and I'm sure the topic has been mentioned elsewhere and I've missed it.

Back in the day, Peter Minten talked about how we might classify exercises more systematically, in https://github.com/exercism/x-common/issues/63 and https://github.com/exercism/x-common/issues/72.

I think that if we have language-specific classifications and topics, we should do it in the language-specific repository (keeping all the language-specific stuff together).

What if we did this in config.json? We could have a new key, exercises, which contained an array of objects with the problem slug and topics. x-api could be changed to look preferentially at the new key, and fall back to the old one if it's missing. Then we could migrate all the tracks without having to do everything all at once.

The topics would be optional, but having it in the actual codebase would probably help crowdsource this data.

@exercism/track-maintainers Thoughts?

jtigger commented 7 years ago

Do we yet have features in either the web app or the CLI that leverages "topics"? I think I get the concept, but I'm not clear on the use cases we're targeting with this data.

jtigger commented 7 years ago

By way of example of analysis of topics ...

@rcraggs digested the set of exercises on the Java track to determine what topics were surfaced in each exercise:

https://docs.google.com/spreadsheets/d/1-jHZex1oMRk2eJxCkHfWK1MXaIFkVWQt2hUhDUih198/pubhtml?gid=0&single=true

He shared this with Katrina in the GitHub Education forum: https://education.github.community/t/fluency-vs-proficiency-when-teaching-learning-programming-and-ready-made-assignments-for-your-classroom/2479/3

And there is a discussion about it, further in exercism/xjava#134

This could be really useful in thinking about how topics can be used to support track health...

kytrinyx commented 7 years ago

Follow-up to everyone involved in this discussion:

Topics and difficulties are going to be a key component in the nextercism prototype. We're discussing implementation details (and philosophy, always!) in https://github.com/exercism/discussions/issues/167

I'm going to close this in favor of the new discussion.