Only allow a Beta Kata to be approved when every language it is translated in gets >1 upvote(s) from a Moderator

[DonaldKellett]

In a heated discussion in this 8kyu Kata, I discovered a very good suggestion from kazk regarding how the Beta process could be improved to prevent a Kata that contains major issues in one (or more) particular language but not in others from being accidentally approved by a Moderator who may have only completed a non-problematic version of that Kata. All credit for this Suggestion belongs to kazk alone, I'm only here to spread the word:

One idea I came up while reading this thread is to send out notifications to all moderators who solved the kata when someone tries to approve the kata. Then only finalize the approval if at least one agreement for each language is given within some timeframe (like few days). If a language doesn't get any votes, the status should say so and any moderator can test that language and vote. If disagreement vote was given in any language, the entire kata is put in the state of "Waiting for {LANGUAGE}: {REASON}". For this kata, "Waiting for JavaScript: Needs random test cases". Any of the moderators can help by adding that.

As kazk mentions earlier in his comment on Codewars, this should probably improve the Beta process by further diminishing the chances of a Kata that is crappy in a particular language (but not in others) being accidentally approved but hopefully will not be as hard to implement as g964 's original suggestion that each language for a Kata should have a separate Beta process. What do you think jhoffner ?

┆Issue is synchronized with this Clickup by Unito

[kazk]

Thanks for opening this. I think it's necessary to spread the responsibility especially as the number of supported languages increases.

If this is too much work, another idea is to require some period without disagreement to finalize approval. The period must be consecutive and countdown restarts on every disagreement (issue).

1. Alice approves the kata after completing in Ruby 😃
2. The kata enters "pending" period (24 hours, for example) a. Maybe notify "power-users" when this happens
3. Bob sees the "pending" status and notices that JavaScript is lacking random tests 😞
4. Bob opens an issue which causes the status to go back to Beta 👎 a. The system remembers that Alice approved this kata and triggers approval process again once issues are resolved
5. Chuck resolves the issue opened by Bob without actually adding random tests 😑
6. The kata reenters "pending" period (restarting from 24 hours)
7. Bob notices that the issue was resolved, but JavaScript is still lacking random tests 😲
8. Bob opens another issue 😠
9. The status goes back to Beta
10. Donald adds random tests to JavaScript and resolves the issue 😎
11. The kata reenters "pending" period (24 hours)
12. Others ensures the quality of this kata in the languages they used during this period. Not opening an issue will advance the status 👀 👍
13. No issue opened for 24 hours. The kata is approved ✨

[SteffenVogel79]

I think the beta process should not be reversable. In my opinion status going back to beta is not a good idea,

Often users have a question or problem with their own code and create an issue. It is not ok, if any user can set back any katas with issues to beta...

Please be careful with decisions for this process.

[kazk]

@SteffenVogel79, if you're concerned about my comment, that "The status goes back to Beta" is from "pending" status to beta and doesn't apply to already approved ones. Maybe I should have written more clearly, but I assumed that this discussion was about how to prevent premature approvals and keep quality uniform between languages.

[SteffenVogel79]

@kazk: Ahhh, thanks for the explaination! Then I misunderstood this.