A place for track specific metadata in the .yml files about problem-specifications HOT 9 CLOSED

Yes, this would be backwards compatible, and would be very easy to support in the x-api.

I like how this would allow us, with very little effort, to change how the "progressions" work (linear to non-linear), and it would also be a step in the right direction for making the language landing pages feature richer.

from problem-specifications.

It's also relatively simple to add the properties, once good guidelines for them have been developed, and it can be done in small increments. So that may make for good first-patch material for newbies looking to contribute.

from problem-specifications.

Yeah, that's a really good point.

from problem-specifications.

I'm going to be speaking at ROSSConf in Vienna on April 25th, 2015 (a week from today), which includes a half-day hackathon to contribute to various open source projects.

I am attempting to prepare issues that can be broken down into small pieces and tackled without too much knowledge about the entire exercism ecosystem (https://github.com/exercism/rossconf/issues).

If we can come up with some suggestions for a reasonable first-pass attempt at this, then this task could be an appropriate one for the ROSSConf hackathon.

from problem-specifications.

The task of adding metadata breaks down, for a first pass, into two subproblems:

1. What's the type of an exercise (focus, practice, challenge)? This should be fairly easy.
2. What are the topics of the exercise (e.g. "recursion", "higher order functions", "loops", "conditionals", "concurrency")? I'm finding this to be a bit harder since topics tend to be vague and it's hard to enumerate them all beforehand.

I'll start using the x-common wiki to describe the meaning of exercise type and to write down a list of topics. That list will be incomplete. Part of what the ROSSConf hackathon participants can do is to add to that list if they feel a topic is missing.

One thing I'm a bit worried about is overlap of pull requests, i.e. many people submitting patches for the same exercises. That would create a lot of work to resolve. At the same time it's unrealistic to expect people to cover an exercise for all possible languages since most of them will only know one or a few languages.

Maybe it's an idea to temporarily allow people to add extra .yml files of the pattern exercise.track.yml (e.g. elixir.list-ops.yml) with only the metadata for that track + common. I can later semi-automatically merge those together.

from problem-specifications.

After a lot of pondering I don't think this is good hackathon material. I've started to doubt the wisdom of providing an optimal ordering for the existing exercises for the simple reason that it would put like 10 very easy exercises at the front. That's likely to scare off non-newbies who get the impression exercism is about really trivial stuff and because those exercises are so simple reviewers tend to get reviewer-fatigue fairly quickly (it's boring to point out the same stuff over and over again).

Instead, I think, it's most important at this point in time to figure out which exercises are actually good. An interesting challenge for the hackathon may be to discuss what makes an exercise good and how you can separate the fun/interesting/useful exercises from the more boring ones. It's not exactly hacking, but it is problem solving and thinking about this kind of stuff is likely to make people aware of good coding style. Plus, discussing such a vague issue is good practice for open source development skills.

Of course, this is just me trying to offload some track-related headaches on unsuspecting passers-by. ;)

from problem-specifications.

Of course, this is just me trying to offload some track-related headaches on unsuspecting passers-by. ;)

As you should :)

I think you're right. I've been thinking about this a lot over the past few days, and I wonder if it would be worth whipping up a little app that lets you choose a particular language/exercise and then just click through all the existing implementations with their comments (anonymized) -- without any sort of ability to comment. The idea would be that this could let someone quickly get an idea of whether or not there are multiple common approaches, common problems, lots of discussion (or not), etc.

This could be the basis for having a discussion about whether or not a problem is good, and as an extension to that, what makes a good/interesting problem.

from problem-specifications.

I'll be asking people to comment in a shared thread about which exercise they intend to work on so that there are fewer chances for conflict and overlap.

from problem-specifications.

Hi. It looks like we added such items to some exercises' yml files in this repo, but then we removed them in #597 (because we were inconsistent about it) and #604. At this point, the topics classification has been moved to individual tracks, so this has been replaced by exercism/discussions#60

The other item discussed here, exercise type, is still covered by #63.

from problem-specifications.