I don't know if the description changes per language used but it says the following:

Return True if you're better, else False!

which would imply that I need to return string True or False, since the keywords in JS are lowercase.

Could that be a quick fix?

I'm not sure, you could surely ask your other moderators or contributors for help. But I'd say for 8 kyu, friendly reminders are nice to see. You could also reference the katas that have received very positive feedback and see how to establish a consistent submission of katas that are well constructed.

All I am trying to do is to establish to what lenghts should descriptions go to avoid this kind of problems. If the above suggestion would be considered as necessary to address, many other kata which rely on the fact that one second is 1000 milliseconds, or that one minute is 60 seconds, or that one hour is 60 minutes, would have to be updated as well. I am just trying to figure out if that's what has to be done.

Me sorry for bad Englisch, I'm not Englisch. Hope u understand what I ask.

damn didn't know Mods here were condescending, that's crazy.

But to answer your question that was barely readable: not sure, probably not. But actually, I didn't know that 1000ms = 1s. Maybe I just forgot, but if I did, so will others.

So what I recommend is that you add that conversion in there as a friendly reminder.

I have a honest question: what could even be some another example, where one second would be something else than 1000ms?

Could we also add the conversion of milliseconds to seconds? I believe in this example it's 1000ms = 1s, but it would be appreciate if that was written down

yeah this makes no sense to me. maybe @Cito could explain this in more detail

yeah quite complicated for an 8 kyu.

and is s = stairs? I'm not sure because they dont use the same variable names in the example...

Examples should not help you understand a problem. Specifications should do that.

"Remove spaces" really should not need examples, unless you are hell-bent on reverse engineering the examples to avoid reading the specifications. I see a lot of that ( people insisting on examples ), and I think it's an awful habit to have.

Conversely, a problem specified by examples only very quickly becomes "just read my mind."

If you read the specifications, can't figure out the task, and then resort to reverse engineering the examples to figure out what an author apparently, probably, meant to be the task, it's entirely possible the specs were written badly, but it's also entirely possible you are refusing to read the specs.

Do not refuse to read the specs.

( If the description is written badly, raise an Issue. But really, how bad can "remove spaces" be? Which of those words do you need defined? )

( This advice worth what you paid for it. Other opinions may be available - but they might be wrong. )

Yeah I think that's much better, thanks Chrono :)

I'm sure all of us beginners will appreciate this.