Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow marking exercise as un-actionable #23

Closed
ErikSchierboom opened this issue Oct 10, 2019 · 18 comments · Fixed by #27
Closed

Allow marking exercise as un-actionable #23

ErikSchierboom opened this issue Oct 10, 2019 · 18 comments · Fixed by #27

Comments

@ErikSchierboom
Copy link
Member

ErikSchierboom commented Oct 10, 2019

Some exercises are specifically designed in a way that it cannot be based on the canonical data. Currently, those exercises show as a actionable; i.e. it looks like they need to be updated to the latest canonical data. It would be useful if we could allow marking these exercises as fixed or un-actionable (or whatever the appropriate term is), which means that they will never show up as actionable. Perhaps hard-coding them into the tracks.json file is the easiest solution, as it will allow track maintainers to easily submit PR's.

@SleeplessByte
Copy link
Member

I think via PR -> store it in tracks.json is a good idea.

unactionable: [slug, slug, slug]

@ErikSchierboom
Copy link
Member Author

Agreed!

@glennj
Copy link
Contributor

glennj commented Oct 10, 2019

An alternative thought: don't hardcode the exercises, but accept a special version string, such as "non-canonical" or "not actionable".

@SleeplessByte
Copy link
Member

UNVERSIONED would be a standard

@ErikSchierboom
Copy link
Member Author

I don't mind either option (hard-coded or special version). Which version do people prefer? Please give this comment a thumbs-up for the hard-coded version, and a heart icon for the special version.

@SleeplessByte
Copy link
Member

The UPSIDES of using UNVERSIONED are:

  • if canonical data is added later, there is no clash
  • it's sorta semi-standardised
  • it allows you to do this in the source repo

The UPSIDES of using a hardcoded list here are:

  • versioning can be done regardless of canonical data
  • it doesn't require an exercise to forego versioning, just forego canonical data
  • it's all co-located here so easy to look-up which exercises are foregoing caonical data matching. We can display them as a list, which is impossible with the method above (without fetching them all).

@glennj
Copy link
Contributor

glennj commented Oct 11, 2019

@SleeplessByte, I do prefer that track maintainers can manage their own exercise version opt-out without having to submit a PR here. You do make some good points in favour of the list approach.

On the bash track we decided to use the .meta/version file to hold the canonical version, and we added a special comment into the test scripts that allow track versioning. We added some code into the CI check script to verify the two versions remain in sync.

@SleeplessByte
Copy link
Member

My guess is that you would really only need to PR here once or twice, and it wouldn't be a regular thing.

@ErikSchierboom
Copy link
Member Author

it doesn't require an exercise to forego versioning, just forego canonical data

To me, this is the argument that makes we choose for the hardcoded list option.

@sshine
Copy link

sshine commented Oct 17, 2019

Some exercises are specifically designed in a way that it cannot be based on the canonical data.

It is not clear to me if you mean both version bumps and description changes.

Haskell track has 4 cases where we'd like to skip version bumps, but retain description changes.

@ErikSchierboom
Copy link
Member Author

Haskell track has 4 cases where we'd like to skip version bumps, but retain description changes.

This was indeed what I was referring to. Sorry for the confusion!

Is there any opposed to the hardcoded list option?

@SleeplessByte
Copy link
Member

@glennj I think is in favour of do it in the track repo, but will be okay with it being hardcoded.

@sshine
Copy link

sshine commented Oct 19, 2019

@ErikSchierboom, @SleeplessByte: I think hardcoding is fine. Sorry for taking time to respond.

While having a grace period for track maintainers to respond (such that we get the most useful features across tracks for which there are maintainers who like to give input), I also think that the working group (which is currently @SleeplessByte, as far as I can tell from the commit history) define any deadlines to avoid response-time gridlocks.

(Lately on the Haskell track we've been using e.g. the phrase "I'll give other maintainers 48/72 hours to respond before merging" to avoid this.)

@sshine
Copy link

sshine commented Oct 19, 2019

@glennj wrote:

I do prefer that track maintainers can manage their own exercise version opt-out without having to submit a PR here.

So do I. The Haskell track's versioning policy says that packages with a version of 0.1.0.i should not be bumped. We have another undocumented preference of slightly diverging from canonical tests in a way that preserves the canonical version, exemplified here.

But such versioning conventions are, as far as I know, not general across tracks.

I'd like for them to be, but I don't know if we're in the right situation to expand on things derived from problem-specifications. So perhaps an easy workaround is to have hardcoded opt-outs in this repo until we have a more comfortable working environment for building more project-wide conventions?

@SleeplessByte
Copy link
Member

I'd like for them to be, but I don't know if we're in the right situation to expand on things derived from problem-specifications. So perhaps an easy workaround is to have hardcoded opt-outs in this repo until we have a more comfortable working environment for building more project-wide conventions?

I agree with this. It's not expensive to change this later.

@ErikSchierboom
Copy link
Member Author

I'd like for them to be, but I don't know if we're in the right situation to expand on things derived from problem-specifications. So perhaps an easy workaround is to have hardcoded opt-outs in this repo until we have a more comfortable working environment for building more project-wide conventions?

I also agree with this. Let's settle for the hardcoded option for the moment.

@SleeplessByte
Copy link
Member

Sweet. I'm locking this as soon as I get to it and then I'll implement it. @ErikSchierboom @sshine please send me a list of slugs (slack) if you want me to kick-start yours.

@exercism exercism locked as resolved and limited conversation to collaborators Oct 20, 2019
SleeplessByte added a commit that referenced this issue Oct 20, 2019
SleeplessByte added a commit that referenced this issue Oct 20, 2019
@ErikSchierboom
Copy link
Member Author

Lovely!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants