I suggest the wording of the Meltdown Mitigation exercise is improved. Doing so can ensure the reader understands that the requirements stated below are for the reactor to be “balanced critically,” NOT to be “critical” itself.
Prior phrasing could allow for misinterpretation that the subsequent requirements are for a reactor to “go critical,” which essentially places the reactor in a “bad state.” These requirements are listed to identify what is necessary for the reactor to be in a “good state.”
Line 15 of exercises/concept/meltdown-mitigation/.docs/instructions.md reads as follows:
A reactor is said to be critical if it satisfies the following conditions:
Recommended change:
A reactor is said to be balanced in criticality if it satisfies the following conditions:
Key change: “[…] said to be criticalbalanced in criticality if it […]”
Stating that it is balanced in criticality is essential to identifying to the reader that it is a good thing that these requirements are satisfied.
That’s hilarious @BethanyG. I cloned the repo, made a fix, opened a branch, and was about to open a PR, when I read the guidelines and said that you were no longer accepting contributions and should open a topic on the forum for change requests!
While it can be read as ambiguous, the note on the repo is there for a reason: we don’t accept PRs or issues from non long-time contributors on the Python track without pre-discussing and pre-approving the work here on the forum. Most Exercism repos - not just Python - have similar policies.
We’ve had too many people go to a lot of work without reading documentation or requirements. They then get very upset when their PRs are not accepted, or they’re told to heavily re-work things.
We’ve had people submit malicious code and we’ve had them re-format the entire repo, and expect us to review 100’s of files as a result. We also get a lot of spam issues and PRs. It creates overhead that then takes away from other tasks like creating new exercises, mentoring, or upgrading tooling.
Even with isolated typos It seemed better to be very up-front. We don’t accept direct and unsolicited contributions to the GitHub repos. However, we do often accept contributions from people who discuss the work here first, and get the go-ahead from a maintainer.
Change wording or carefully chosen phrases that stem from lengthy discussions
Contradict maintainers intention
To avoid frustration and too many parallel discussions please start a discussion on the forum first, and then follow up with a PR when that makes everybody happy. @BethanyG is known for fast and nice responses, so it will not slow you down too much.
Thanks for finding and reporting it. 
