Fair. You're correct.

The kata aka specification states that a boolean is given, so in real life an error should be raised. However, kind of exception handling is out of scope of kata imHo.
Therefore, the solution is fine.

I tend to agree. Code that works when it shouldn't can be more dangerous as code that doesn't. Think in terms of someone sending what they believe is a boolean "false" but instead sends the string "false". Ruby will evaluate that as "true", so if this is meant to only get results from booleans (no matter how you nitpick Ruby's implementation of them) instead of how the passed value is evaluated by Ruby's definition of truthiness, there should probably be a case to make sure those either fail or return a discernable value like "false" or "nil" that could be used by anything calling it.

Codewars shouldn't be just about passing the tests. It should be about encouraging good practices.

Good for returning after a Boolean value is passed, but will also return for things that evaluate as true or false. At any level higher than 8, I'd suggest the test should probably be written to reject this solution, but it definitely fulfills the test criteria.

Created a fork and took care of the merge conflicts as far as I can tell.

I'll get on that later today. Thanks again! First time submitting a translation on here. Unfortuante that it's not a bit more directly git-like, or possibly if it utilized github since they offer that as a login option.

Merge issues. You should fork your translation, remove the differences in the description, and publish it.

This is how inconsistencices looks like in case you didn't know: anything between <<<<<<< mine and ======= is the current description, and anything between ======= and >>>>>>> yours is how the same part of text (be it worded/formatted in a different way or missing entirely) looks like in your translation:

<<<<<<<  mine
*current text*
*current text*
*current text*
=======
*your text*
*your text*
*your text*
>>>>>>>  yours

Fixed both. Thanks for reviewing it. Anything else you see?

Test.assert_equals(final_grade(55, 0), 0); fixed test is missing.
The exam value is potentially greater than 100.

Ruby translation available! please approve.

You do realize, that when you are "experimenting", you're using server's CPU for heavy computational task for free, don't you? If there was no timeout, some "experiments" would just kill the server for everyone else.

That's what I did, and why I listed it as an annoyance with the timeout and not an actual problem.

Solve it in your own IDE instead then

Which has literally nothing to do with my complaint. I did in fact achieve a more efficient solution, but often while coming up with a solution, one tests various things to see what is and isn't working, and that code is seldom as efficient. My issue is that the timeouts are annoying when experimenting since they prevent you from getting a result at all during that experiment.

That because you need an efficient solution rather than a slow one