Subject: Request a Disqualification here.
Hi. Got some question regarding your statement:
However, I'd like to ask if this system could be great in terms of "time efficiency". You've even mentioned the procedures that can be stepped when an 'invalid concern' lead to a DQ. As you are already awared of, that DQ'ed beatmap with an invalid reason should wait an extra time since it first got qualified ~ it getting requalified. That period of time would turn out to become a loss of time resource, and also result some waste of human resources to figure out that concern as something invalid. True that assuring quality of a beatmap is something really important. Still, do you think the potential inefficiency of beatmap ranking process (caused by a DQ made without QAT checking it's validity) worths in the system?
If DQ happens everytime when a particular issue arises from a qualified, without that risen issue getting checked beforehand, then why should a QAT exist? Aren't QAT's a QAT for a good reason? They would have the ability and eye to judge whether the proposed issue is valid or not. Not letting them to check the issue's validity will then be another waste of human resources, and if that issue turns out to become invalid eventually, then that's when the inefficient ranking process happens.
The community checks the map, and provide random issues. QAT makes a DQ without revising the validity of issues. That certainly is one powerful way to assure quality of beatmaps, but I've personally started to confuse what the main task of QAT is.
tl;dr
________________________________________________________________________________________________
The above was my message towards Loctav, but made this public anyways.
DQ is good because it usually gives a second chance for quality improvement, but would DQ'ing per every request efficient?
Hi. Got some question regarding your statement:
So you've used the term 'time pressure' as a reason why you've decided the system to become DQ-first-discuss-next. That 'time pressure' seems to be the time limit of a qualified week if I understanded correct. Surely opening a discussion, which fails to reach a consensus before the qualified map gets permanently ranked, does never makes sense. I like the purpose of this system to ensure discussions being properly done with enough time.Loctav wrote:
We first DQ, then we discuss. We do not figure out first if the concerns are valid, we figure that out after the DQ, so we have no time pressure.
However, I'd like to ask if this system could be great in terms of "time efficiency". You've even mentioned the procedures that can be stepped when an 'invalid concern' lead to a DQ. As you are already awared of, that DQ'ed beatmap with an invalid reason should wait an extra time since it first got qualified ~ it getting requalified. That period of time would turn out to become a loss of time resource, and also result some waste of human resources to figure out that concern as something invalid. True that assuring quality of a beatmap is something really important. Still, do you think the potential inefficiency of beatmap ranking process (caused by a DQ made without QAT checking it's validity) worths in the system?
If DQ happens everytime when a particular issue arises from a qualified, without that risen issue getting checked beforehand, then why should a QAT exist? Aren't QAT's a QAT for a good reason? They would have the ability and eye to judge whether the proposed issue is valid or not. Not letting them to check the issue's validity will then be another waste of human resources, and if that issue turns out to become invalid eventually, then that's when the inefficient ranking process happens.
The community checks the map, and provide random issues. QAT makes a DQ without revising the validity of issues. That certainly is one powerful way to assure quality of beatmaps, but I've personally started to confuse what the main task of QAT is.
tl;dr
- Invalid DQ should never happen, and to ensure that, QAT or staff members getting involved through the DQ should take responsibility and check the validity of the proposed concern.
- Exceptions; if a proposed issue was significant enough and an 'actual discussion' has started during the qualified period, QAT should commit a DQ regardless of the validity of the risen issue.
________________________________________________________________________________________________
The above was my message towards Loctav, but made this public anyways.
DQ is good because it usually gives a second chance for quality improvement, but would DQ'ing per every request efficient?