Skip to content

Handling beta kata retirement more gracefully and better informing new kata authors of beta process quality assurance #1672

@Voileexperiments

Description

@Voileexperiments

Coming from #1645.

Currently beta katas are retired after receiving a very low satisfaction rate, which can happen quickly when a new beta kata has significant issues. The problem here is:

  • 1. This process happens too fast. Usually kata authors aren't fast enough to catch on the issues before everyone voted according to kata quality factors and the beta kata gets retired.
    (Maybe it can be solved by making retirement temporary for 1 day where existing votes can still be changed to stop the retirement, then permanent?)
    2. There are no documentations of retirement feature anywhere. We can't even tell the exact criteria for a kata to be retired, or that katas are even retired in the first place. For most users who aren't around long enough, they wouldn't know anything except that their kata got retired for no apparent reasons, which doesn't make any sense and results in a salty experience.
    3. Kata best practice is still hidden to practically everyone. This and this are buried so deep unless someone knows they exist or are sent a link of them, they wouldn't even know they existed, and so they wouldn't know what constitutes the quality in the first place.
    4. There are no mentions that beta katas are supposed to be CW content either, which have to be curated and assured of their quality. Basically, once a kata is published from draft, it stops being the user's baby anymore and they cannot just do whatever to the kata as they please.
    5. The wording around the entire beta process is... not very ideal and perhaps a bit too hostile. e.g:
    image

Incidentally (and unsurprisingly), stackoverflow meta has encountered such kind of issues for a long time, and they have some very good suggestions.


┆Issue is synchronized with this Clickup by Unito

Activity

CliffStamp

CliffStamp commented on Jan 11, 2019

@CliffStamp
Voileexperiments

Voileexperiments commented on Jan 11, 2019

@Voileexperiments
Author
Blind4Basics

Blind4Basics commented on Jan 12, 2019

@Blind4Basics

I'm not sure there is an ideal way to handle all of this, but, about the retirement process being to quick, what about one of those:

  • automatic unpublishing with notification to the author for a beta having an issue opened (only for recent published kata, otherwise old betas will definitely disappear)
  • maybe the same with a new "not satisfied" vote? (tho there might be the problem of the lacking feeback about what to do)

This, way, the kata isn't retired yet, isn't accessible "anymore/for now" so that should let time to the author to look into this. and being put to draft, the kata isn't completable anymore (no submit final) so for PU who scrutinize their dashboard and access the kata seeing the issue raised, they still can raise other issues, but cannot downvote (for now), so that'd stop the "hemorrhage".

Just ideas...

CliffStamp

CliffStamp commented on Jan 13, 2019

@CliffStamp
kazk

kazk commented on Jan 13, 2019

@kazk
Blind4Basics

Blind4Basics commented on Jan 13, 2019

@Blind4Basics
Voileexperiments

Voileexperiments commented on Jan 14, 2019

@Voileexperiments
Author

I think I should perhaps add a number 6 to the list in the OP:

Since beta katas award honor for ranking and satisfaction votes, and you lose the ability to make ranking votes after it's approved (and both after it's unpublished/retired), it encourages users to leave a vote no matter what. Which was good in the past because the approval criteria was high and you need up to 12 votes with at least 90% satisfaction rating to get past beta, but not needed anymore with beta approval requirement being as low as it is right now, and in fact is now being somewhat harmful in two ways:

  • user voted "very satisfied" out of common courtesy, made problematic katas past 80% satisfaction criteria as a result
  • user voted "somewhat satisfied" or "not satisfied" because there are significant issues with the kata, but the votes are coming too quick! There is no time for the kata author to react

I don't really think giving missable honor for voting is a good idea at now when most of the time votes are made just to not miss out that additional tiny bit of honor. At least there should be good reasons for us to hold out our votes for something, which currently is nothing.

Blind4Basics

Blind4Basics commented on Jan 26, 2019

@Blind4Basics
kazk

kazk commented on Jan 26, 2019

@kazk
FArekkusu

FArekkusu commented on Jan 26, 2019

@FArekkusu

Personally, I liked the system before the fix more :(

It's unfair that some katas get retired quickly, but nobody seems to care about the fact that the majority of them are objectively very bad, and it may be a much better idea to kill those.

For example, this kata is plain worthless: alias an existing method with input validation thrown in; it has no novelty (and most probably a duplicate), and dealing with the input validation brings nothing game-changing to the task (and usually it's plain annoying). Yet with 0 very, 1 somewhat and 4 not satisfied votes it's still up...

31 remaining items

NadChel

NadChel commented on Feb 25, 2023

@NadChel

Once a kata has any solves, it can no longer be deleted. But any kata which is in Draft or Retired state cannot be found in the kata search page, only people with a direct link can see it. Also, even if people do have a link to a draft or retired kata, they can not submit solutions to it.

@Kacarott what's the point of the beta phase if it can still be downvoted into nonexistence in the blink of an eye? It wasn't even my mistake (I never included a JS version; I guess it was automatically added because JS is one of my trained languages). Still, I reacted swiftly and translated it into JS merely hours after the publication. And it didn't help me anyway! How fair is that?

JohanWiltink

JohanWiltink commented on Feb 25, 2023

@JohanWiltink

Review is the point of the Beta phase. If your kata gathers so many downvotes it should obviously never be approved, retirement is better than letting it languish in Beta ( gathering ever more downvotes ).

There is, at least in theory, a difference between downvoting a kata and raising issues on it. Issues can be addressed, but a downvote means the kata should not exist. Not all voters take this approach, but that's the intention of the system.

If your kata is a duplicate, or the essential task is not fit to be made into a kata, downvoting it is the correct expression of that. If your kata does not have random tests, raising an issue would be. In practice, if a kata is published without random tests, I downvote it. Author should have know better. ( Not applicable to your case - I didn't even solve yours. )

hobovsky

hobovsky commented on Feb 25, 2023

@hobovsky

You don't need to address all your questions directly to Kacarott, other uses can answer them too :)

The point of beta phase is to curate content published by users before it reaches a permanent state. It tends to happen quite swiftly, because there's quite a few very active reviewers, and any newly published kata attracts attention in minutes. If a kata is of insufficient quality, it's guaranteed to receive issues quite soon. If a kata is published in a condition which does not even make it suitable for publication, it's probable to be downvoted quickly.

You are right that downvoting a kata without any feedback is not great, but this is what many of reviewers don't understand, and some of them find clicking a red button much easier than typing in a couple of words into a text box. Well, writing is hard, I believe, and clicking red buttons seems to be top of capabilities for some.

Having said that, it does not happen often that a kata gets nothing but downvotes if it is any good. It is very probable that in this particular case, it got downvoted quickly because it made an impression of being simply broken. And reacting in a few hours is still not quick enough, because reviewers are often faster than that.

The JS version being added accidentally is highly unlikely. It could be selected by default by kata creator, but it would not be persisted if the kata would not be saved like that. At some point, the JS version had to be saved. Currently there is no known issue about JS versions popping up out of nowhere. If you can reproduce this behavior, feel free to report a bug.

On top of all of this, I am not sure how "unfair" is this, or how much of a problem recreating a kata is. It boils down to copying 5 snippets, and dropping a link to the draft on Discord. You'd get an immediate feedback without getting a single downvote. Go through a round or two of fixing problems reported on Discord, and then publish for beta a (hopefully) cleaned up version. Is this, for some reason, a bad way to go?

NadChel

NadChel commented on Feb 25, 2023

@NadChel

Review is the point of the Beta phase. If your kata gathers so many downvotes it should obviously never be approved, retirement is better than letting it languish in Beta ( gathering ever more downvotes ).

There is, at least in theory, a difference between downvoting a kata and raising issues on it. Issues can be addressed, but a downvote means the kata should not exist. Not all voters take this approach, but that's the intention of the system.

If your kata is a duplicate, or the essential task is not fit to be made into a kata, downvoting it is the correct expression of that. If your kata does not have random tests, raising an issue would be. In practice, if a kata is published without random tests, I downvote it. Author should have know better. ( Not applicable to your case - I didn't even solve yours. )

@JohanWiltink "so many"? You mean five? Three of them were added by JS coders at the time no JS translation was even written! It's gratuitous and toxic. What makes you think it would gather "ever more downvotes"?

Here's my vision: no downvotes should be allowed at all, at least not in the beta phase, only suggestions and issue reporting. Why? Because you can't act on a downvote (you can act on a specific suggestion, though). A kata should be approved if no unresolved problems exist and it gains X likes (say, five)

Kacarott

Kacarott commented on Feb 25, 2023

@Kacarott

I guess it was automatically added because JS is one of my trained languages)

It wasn't. When opening a new kata, the default language is JS (I believe because its popular and also the first language available on CW), so what likely happened is that you accidentally/unknowingly made some small change to the JS code setup before realising and switching to another language. Then when you saved, the editor thought that you intended for both a Java and JS version, and so published both.

As for downvotes being toxic, I don't see how. You might be surprised to hear this but it is actually fairly common the people will post completely unfinished/zero effort kata, which lack almost any kind of tests, often a bad description, etc. These are very quickly retired/unpublished. If downvoting was removed, and all beta kata were allowed to stay in beta until eventually getting enough upvotes, then there would be multiple thousands of zero-effort kata filling up the space. It would be extremely difficult to find any beta of actual quality to train on and to try get approved. Even with the system we currently have, there is still thousands of beta kata just sitting there, of which probably only a couple hundred are of high enough quality to be approved one day.

In regards to it being unfair to kata authors, this is understandable, and we have actually somewhat recently introduced a new mechanic to help that: see here however this is only triggered when 2 issues or more are raised, so it never triggered on your kata.

So in summary, an honest mistake by you caused a kata to be published, which looked like just another low effort kata to people attempting to solve it in JS, so they downvoted it to remove it from beta. If your kata was actually of high quality, then this was simply an honest mistake on their part. Ideally, another issue would have been raised to send it to draft instead, however that didn't happen. It seems to me like an obvious and very easy solution would be to simply copy over your work to a new kata, ensure the JS version is removed (or keep the one you ended up translating), and perhaps leave a note in the discourse to let people know that you are remaking it with a proper JS version.

NadChel

NadChel commented on Feb 25, 2023

@NadChel

You don't need to address all your questions directly to Kacarott, other uses can answer them too :)

The point of beta phase is to curate content published by users before it reaches a permanent state. It tends to happen quite swiftly, because there's quite a few very active reviewers, and any newly published kata attracts attention in minutes. If a kata is of insufficient quality, it's guaranteed to receive issues quite soon. If a kata is published in a condition which does not even make it suitable for publication, it's probable to be downvoted quickly.

You are right that downvoting a kata without any feedback is not great, but this is what many of reviewers don't understand, and some of them find clicking a red button much easier than typing in a couple of words into a text box. Well, writing is hard, I believe, and clicking red buttons seems to be top of capabilities for some.

Having said that, it does not happen often that a kata gets nothing but downvotes if it is any good. It is very probable that in this particular case, it got downvoted quickly because it made an impression of being simply broken. And reacting in a few hours is still not quick enough, because reviewers are often faster than that.

The JS version being added accidentally is highly unlikely. It could be selected by default by kata creator, but it would not be persisted if the kata would not be saved like that. At some point, the JS version had to be saved. Currently there is no known issue about JS versions popping up out of nowhere. If you can reproduce this behavior, feel free to report a bug.

On top of all of this, I am not sure how "unfair" is this, or how much of a problem recreating a kata is. It boils down to copying 5 snippets, and dropping a link to the draft on Discord. You'd get an immediate feedback without getting a single downvote. Go through a round or two of fixing problems reported on Discord, and then publish for beta a (hopefully) cleaned up version. Is this, for some reason, a bad way to go?

@hobovsky I can't even join the Discord channel. I have checked probably a thousand pandas with glasses, no go 🤦‍♂️

hobovsky

hobovsky commented on Feb 25, 2023

@hobovsky

Here's my vision: no downvotes should be allowed at all, at least not in the beta phase, only suggestions and issue reporting. Why? Because you can't act on a downvote (you can act on a specific suggestion, though). A kata should be approved if no unresolved problems exist and it gains X likes (say, five)

I think idea is based on a premise that every published beta kata created by users is eventually approvable, while it's not always (and frankly, not that often) a case. There are kata which are copies of other kata, duplicates, homework questions fishing for solutions, broken (unsolvable, or without tests, or with critical mistakes in tests), or just with a minimal effort put from authors side. Feedback and issues on kata of this kind often proved to be pointless because authors were not interested in acting on them. There are also kata which are technically good, just conceptually bad, or boring, or not great for reasons other than technical, and satisfaction votes are meant to reflect this aspect: some kata should not be approved even if there is no technical issue with them.

Please note that I explain how things work in general, and not necessarily in relation to your kata. I also do not say that the beta process is good as it is now. If it were good, this ticket would not be even necessary. Any ideas for improvements are really welcome, because the beta process definitely should not be an unpleasant experience. But the beta process should be able to handle many more problems than just kata with some small, fixable problems with their technical implementation. Some kata are just too bad. And kata with no tests which can make an impression of unfinished and not ready for publication are one of them. As a mod, I can just force them back to draft and ask author for fixing before publishing. But I can imagine how other users can just downvote a kata with no tests. But again, if this was a honest mistake, why not just recreate it, in a correct language, and with all tests?

It's also worth to remember that it's difficult to create something what everyone else would like. It's possible that someone still won't like a perfectly executed idea, or audience in general won't share author's enthusiasm about the idea. 100% satisfaction rate is very difficult to get.

NadChel

NadChel commented on Feb 26, 2023

@NadChel

Yes, the new kata can have the same title as the old one.

@hobovsky It doesn't seem so. "Name is already taken"

JohanWiltink

JohanWiltink commented on Feb 26, 2023

@JohanWiltink

Can you rename the retired one?

NadChel

NadChel commented on Feb 26, 2023

@NadChel

Review is the point of the Beta phase. If your kata gathers so many downvotes it should obviously never be approved, retirement is better than letting it languish in Beta ( gathering ever more downvotes ).

There is, at least in theory, a difference between downvoting a kata and raising issues on it. Issues can be addressed, but a downvote means the kata should not exist. Not all voters take this approach, but that's the intention of the system.

If your kata is a duplicate, or the essential task is not fit to be made into a kata, downvoting it is the correct expression of that. If your kata does not have random tests, raising an issue would be. In practice, if a kata is published without random tests, I downvote it. Author should have know better. ( Not applicable to your case - I didn't even solve yours. )

You said, if I understood you correctly, my kata doesn't need random tests. However, I'm still asked to add them. Do I need them or not? And what are random tests exactly? Should I include tests that use randomly generated sequences of letters?

JohanWiltink

JohanWiltink commented on Feb 26, 2023

@JohanWiltink

You did not understand me correctly. Yes, you need random tests.

Please read available documentation.

Dmytro2V

Dmytro2V commented on Sep 10, 2023

@Dmytro2V

Met quite a complex real case resently. Spent hours to make it. Have studied regEx for this. It was really cool after success.

Decided to make a series of kata from easy to top. It all was about converting string object-like data to real objects. With nested ones and double quotas and commas inside inner string it is a real mess.

So for practice created first one, possible about 7 level kata. Easy, without nest, preformatted for simly JSON.parse. It could be quite interesting for me when I was on 7 level to meet such topic and try JSON. And good start for all the series planned.

But what I see? Beta was tested by 4 top experienced members and retired. No feedback, no obvious reason. Probably I will not waste more time for all the series up to top hard with nested and regex.

Voileexperiments

Voileexperiments commented on Sep 10, 2023

@Voileexperiments
Author

@Dmytro2V This is the kata you're talking about. I am one of those who voted "not satisfied". This kata has nothing to do with this issue.

If your author solution is if(string) return JSON.parse(string); it's really just a boring kata. Does your kata teaches anything with that? Is it novel? I do not believe anyone else would agree with that.

If you want to get a second opinion you should probably ask in the CW Discord instead. Most people who participated in beta is probably also inside anyway. But they'd probably say the same thing.

Also, it appears that you completely missed the kata authoring guidelines, specifically the part that every kata should have random tests unless under very special circumstances.

Dmytro2V

Dmytro2V commented on Sep 12, 2023

@Dmytro2V

@Voileexperiments I didn't read all the thread too thoroughly. I thought, it is about interface a bit unfriendly for new kata creating. Sorry if I misunderstood the topic.

shreedave0

shreedave0 commented on Mar 24, 2025

@shreedave0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @kazk@Voileexperiments@JohanWiltink@hobovsky@nomennescio

        Issue actions

          Handling beta kata retirement more gracefully and better informing new kata authors of beta process quality assurance · Issue #1672 · codewars/codewars.com