Instead of having logic for a fallback in the backend, we're choosing a
default for the snippet file.
For tracks that have core exercises, we pick the first core exercise.
For tracks without these, we pick the first exercise listed in the config.
Note that we're aiming for 10 lines and a max-width of 40 columns.
This solution has 11 lines, so we may want to adjust it.
We wish to feature the maintainers of each track on the new (nextercism) website. Ideally, the bios will be tailored to each track, giving a friendly view into each maintainer's background and interest in the language, and even (perhaps) what they enjoy most about maintaining the track, or what type of things they tend to focus on.
The main reasons for including these are to:
* provide a stronger basis for empathy with maintainers
* give well-deserved recognition
* plant a seed in people's minds that _Exercism tracks are maintained by people like me... I could do that!_
Being featured on the Exercism website is entirely optional, and we're generating all the data with show_on_website=false so that if you don't want to bother, you don't have to change anything.
If you've moved on, or decide to do so, please submit and merge a PR (for visibility to the others involved) that sets **alumnus** to _true_ for your maintainer entry. I'm working on a bot that will update the GitHub team to reflect the current state of this file.
We can merge this as is, and any changes can be added in subsequent pull requests.
The slug is not used anywhere. We initialize a track based on knowing the Track ID.
Since the repository is always named after the track ID, this field, too, is redundant,
as it can be inferred.
We are working towards making exercises stand-alone. That is to say: no more generating READMEs on the fly.
This will give maintainers more control over each individual exercise README, and it will also make some of the backend logic for delivering exercises simpler.
The README template uses the Go text/template package, and the default templates generate the same READMEs as we have been generating on the fly. See the documentation in [regenerating exercise readmes][regenerate-docs] for details.
The READMEs can be generated at any time using a new 'generate' command in configlet. This command has not yet landed in master or been released, but can be built from source in the generate-readmes branch on [configlet][].
[configlet]: https://github.com/exercism/configlet
[regenerate-docs]: https://github.com/exercism/docs/blob/master/maintaining-a-track/regenerating-exercise-readmes.md
We will be moving to a tree-shaped track rather than a linear one, as described in the [progression & learning in Exercism](https://github.com/exercism/docs/blob/master/about/conception/progression.md) design document.
In order to support this, we need to expand the metadata that exercises are configured with.
Note that 'core' exercises are never unlocked by any other exercises. Core exercises appear in the track in the order that they are listed in the array.
Non-core exercises depend on only one exercise (unlocked_by: ). At the moment we are assuming that this is a core exercise, but there is no reason that it needs to be.
Until now we have operated with a separate deprecated array. These are now being moved into the exercises array with a deprecated field.
With these defaults the track in nextercism will have no core exercises, and all the exercises will be available as 'extras' from the start.
If you haven't already, now would be a good time to do the following:
* add a rough estimate of difficulty to each exercise (scale: 1-10)
* add topics to each exercise
* choose *at most 20 exercises* to be core exercises (set core: true, and delete the unlocked_by key)
* for each exercise that is not core, decide which exercise is the prerequisite (max 1)
If possible, leave 3 or 4 simple exercises as (core: false, unlocked_by: null), as this will provide new participants with some exercises that they can tackle even if they have not finished the first core exercise.
This changes configlet to pass a subcommand.
For now, we've released a version of configlet which handles both the old command:
configlet path/to/track
as well as the new command:
configlet lint path/to/track
This will let us update all the travis files to include the subcommand before we
release the version of configlet that requires the subcommand.
I failed to notice with the initial commit that the first tests in these
files are just the "version sanity check". This should start learners
off with a useful first failure.
This allows learners to gradually approach exercise. However, unlike
commented tests, the Elm compiler is still able to infer type
information from the skipped tests.
We renamed the language track repositories, removing the leading 'x',
as this is cleaner and more understandable.
This does minor cleanup to fix references to the old name.
The leading 'x' is kind of arbitrary. Especially now that we can set
topics on the repositories, we don't need a pattern to distinguish what
is a track or not.
The repository itself has already been renamed. GitHub redirects from
the old name to the new name, so we do not have to rush to fix links to
the old repository name, though we should update them for the sake of
clarity.
Since the exercise implementations are all in the exercises directory
we no longer need to ignore any non-exercise directories in the root
of the track.
We've had some difficulty coming up with a good name for the file
that gets included in all of the exercise READMEs for a given track.
These are global hints, like how to run the test suite, which are
relevant to all the exercises on a track.
We started with SETUP.md in the root of the repository, then renamed
that to exercises/TRACK_HINTS.md because SETUP.md was misleading and
confusing, but then we realized that TRACK_HINTS.md was a bit ambiguous
and confusing as well.
Finally we settled on putting the file in the docs directory, since
this is user-facing documentation, and calling the file
EXERCISE_README_INSERT.md
See https://github.com/exercism/meta/issues/5 for context.
We don't need the duplication, especially now that the GitHub interface shows the
license information on the main page of the repository when it can be detected
directly from the LICENSE file.
