Generally, the next steps involve other maintainers taking a look and poking around to see if there are any rough edges. After that point, whenever you’re ready, just flip the status in the track config to "active" and the track is available to the general public.
Note that this isn’t a hard requirement but still strongly recommended as a QoL feature. Some tracks don’t lend themselves to exercism test like Pharo.
How I can use a local modification of the test-runner instead of “latest” from official repository to check with verify-exercises-in-docker script? I’ve found bugs and I’m trying to test all exercises locally before create the PR.
Once a track is preparing to launch, the admins enable GitHub branch protection. Then maintainers can’t directly commit to main, but instead merge PRs after they have been reviewed (by another maintainer, or a cross-track-maintainer if the track has less than two maintainers).
The behavior that I usually expect is exit_status > 0 whenever any attempted test fails. So if we only attempt the first test and it passes, I expect exit_status 0, while if we attempt all tests and some fail, I expect exit_status > 0
free-pascal/docs/LEARNING.md at 7e7404d18e0231b78c3bb175abe782fa04553e6d · exercism/free-pascal · GitHub should probably be in the testing docs as well. I had removed result in my Leap stub when I deleted the line raising the not implemented exception. I checked the testing docs for information, but it didn’t provide any details. Given LEARNING.md is about learning the language, it wasn’t obvious to me to check there until after I checked GitHub when I saw the example using result. I tried a different variable after the tests passed and then realized this was something special for the test runner. At that point, I went through all the docs and found that note about result.