exercism / deprecated-mentors

For support, please post in the new Exercism forum. New posts here will be closed.

---

Welcome to Exercism

Where to open issues

For the time being we are triaging all issues from our forum. Please start a new topic there for your issue (presuming there isn't one already). Issues opened here will be automatically closed and you will receive a message redirecting you to the forum.

Feeling uncomfortable?

If you need to report a code of conduct violation, please email us at [email protected] and include [CoC] in the subject line. We will follow up with you as a priority.

Where to find the code

The code for the website lives in exercism/website. The code for the old website is in this repository, in the v1.exercism.io branch.

Who's behind Exercism?

Read about our Team on the site: https://exercism.org/team

deprecated-mentors's Issues

Allow for track-specific (generic) content

Currently, we are creating mentoring notes for individual exercises. This is great, but a lot of mentoring notes/tips/pointers are very generic, and apply to all exercises. A good example of this are coding style guidelines. I think it would be nice if there could be a README.md for each track listing such global notes.

Commit message format

In the problem-specifications repository, we put a lot of effort in ensuring that the commit messages are very descriptive. Most commit messages use a format of: "[exercise name]: [change made]". This makes for quite a descriptive commit history. Maybe we should apply a similar naming policy here? For example something like: "[track name]: [change made]"? An example commit message would then be: "csharp: Add mentoring notes for anagram exercise". An alternative could be "[track name]/[exercise]: [change made]", which could look like this: "csharp/anagram: Add mentoring notes". I think I like the last one best.

The master branch will be renamed to main

In line with our new org-wide policy, the master branch of this repo will be renamed to main. All open PRs will be automatically repointed.

GitHub will show you a notification about this when you look at this repo after renaming:

In case it doesn't, this is the command it suggests:

git branch -m master main
git fetch origin
git branch -u origin/main main

You may like to update the primary branch on your forks too, which you can do under Settings->Branches and clicking the pencil icon on the right-hand-side under Default Branch:

We will post a comment below when this is done. We expect it to happen within the next 12 hours.

Why this repository?

Just a question:

Why are track specific mentoring notes being kept here rather than in the track repositories?

Ruby Hamming

The mentor notes mention Enumerable#each but there is no such method. each is a dependency of Enumerable module, similar to <=> being a dependency of Comparable. The object that wants to take advantage of these, needs to define those methods, respectively.

Should we remove that portion of the notes, or expand on it?

Allow for exercise-specific (generic) content

In the same vein than : #24 Allow for track specific (generic) content

Would not it be useful to have exercise-specific generic content as well ?

That could cover langage-agnostic algorithm considerations, which could be redundant on every tracks (but is it ?).
I imagine the mentors notes on the exercise page being a concatenation of this 3 levels of content :

• Track generic content (good practices, style guidelines, …)
• Exercise generic content (algorithm, complexity, space, …)
• Track's exercise specific content (actual documents)

We could have sooner some notes for every exercise ( Track + exercise generic content ) for specific exercise that have no notes yet.

What do you think ?