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.
in this first exercise, i face the problem that Gradle was not installed on my device. the tutorial doesn't mention this part. even before i fetch the exercise there was no mention to the Gradle in the installation. so I think as a beginner it might help to add this part to the new people will try and use the tutorial in future and some of them will probably face this issue.
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.
Replace exercise templates with track-level default
You can still override the track-level default template by adding a .meta/readme.go.tmpl for the exercise in question.
This removes the stray newline at the end of the generated READMEs.
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.
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.
The template uses the Go text/template package, and the default templates
generate the exact same READMEs as we have been generating on the fly.
Katrina Owen
FridaTveit
mohamedFalah
MichaelSpets
Stuart Kent
Frida Tveit
Stuart Kent
Logan Stucki
Rootul Patel
Leon D'souza
Leon D'souza