Revisit starter implementation policy for nextercism

[stkent]

The next version of Exercism breaks exercises into core exercises and branch exercises. It will therefore be possible for users to complete exercises in many different orders.

In light of this, we should revisit our current policy regarding starter implementations, which "assumes" a fixed order of exercise completion, and decide whether/how to update it. Discussion should occur in this issue thread.

Current policy for reference:

• Exercises 1-20: provide stubs for all required constructors and methods. Stubs should include the following body:
  throw new UnsupportedOperationException("Delete this statement and write your own implementation.");
• Exercises 21+: provide no stubs by default, but either (1) add hints to the hints.md file (which gets merged into the README.md for the exercise) or (2) provide stubs as in exercises 1-20 for exercises that demand complicated method signatures.

References: [1], [2]

[FridaTveit]

Great suggestion :)

We have 17 core exercises currently I think. So maybe for the first five core exercises we can provide starter implementation for the core exercise and all the exercises it unlocks. And then for the next five we provide starter implementation for the core exercise but not for the ones it unlocks. And for anything after that we don't provide any starter implementation (but with the same exception that we had before for exercises that demand complicated method signatures).

That's just a suggestion though. I'd be happy to consider other suggestions or to keep it the same as it currently is :)

What do you think? :)

[stkent]

I think that's a good balance! My only concern is that it may be even harder than the current system to keep up-to-date as we add or reorder exercises. I'm tempted to say we should just provide implementations for every exercise and be done with it!

[FridaTveit]

That's a good point. I do think it's an important part of the learning process to know how to create java files and work out method signatures though. Maybe we could decide on a difficulty below which all exercises should have starter implementations? For example, all exercises with difficulty 4 or below could have starter implementations. That might be easier to keep up to date. What do you think?

[stkent]

Ooh, I like that, much nicer than having to keep count!

[stkent]

I'm happy to open up a PR with that policy change if you'd like!

[FridaTveit]

Sure, go for it :)

Should we open good first patch issues for removing starter implementations? If we're using difficulty 4 as our cut off point I don't think there are any exercises that need starter implementation that don't have them already. But there will probably be quite a few that need to have their starter implementation removed.

[stkent]

If we're using difficulty 4 as our cut off point I don't think there are any exercises that need starter implementation that don't have them already. But there will probably be quite a few that need to have their starter implementation removed.

I think it's the opposite, after looking at the config file; the old 20th exercise was difficulty 4, and there are a few later (21+) exercises still at difficulty 4.

[stkent]

In light of that ^ new information, I still like 4 as a cut-off difficulty.

[FridaTveit]

Oh, I see. Should we open some good first patch issues to add starter implementation then? :)

[stkent]

Sure! I'll PR the policy change today :)

[FridaTveit]

Great! I'll start making good first patch issues :)

[FridaTveit]

Actually, I'll start making good first patch issues once the policy change has got merged since it would be good to have a policy to point people to :)

[stkent]

See #986!

[stkent]

Closed by #986!