finished my popcorn can we get back on topic?
Please do so, sorry to go on a tangent here everyone, but this was the only chance to reply to this topic.pimp wrote:
finished my popcorn can we get back on topic?
Cool! didn't realize it was supposed to be yearly since I don't believe we got elite nominators last year. Thanks for the correction!Ephemeral wrote:
elite is supposed to be yearly and a big fat new batch is coming in the next few days with community contributor
wafer wrote:
Cool! didn't realize it was supposed to be yearly since I don't believe we got elite nominators last year. Thanks for the correction!Ephemeral wrote:
elite is supposed to be yearly and a big fat new batch is coming in the next few days with community contributor
Excited to see who else gets put up as elite nominator :eyes:
The whole document and it's idea was under the assumption that we had to work with either literally what we got or only minor dev thingsSylvarus wrote:
To get back on topic, I'd be interested to know people's reason why they think QAH should exist in the first place and if those goals can even be realistically achieved in any way.
In my mind removing QAH won't be much different from the current state.
Any web changes that need to be made can be made by someone in the community who knows how to code web frontend/backend. Bounties are offered to people willing to help on the dev side. I dunno if by "fixes that we cant implement as the community ourselves" you thought someone from community can't implement changes, or if you meant that you don't think there is anybody in community with coding skills for it.DeviousPanda wrote:
...but at some point you need to stop relying 100% on the community to run the mapping scene for you when we desperately have been asking for changes and fixes for a while now - fixes that we cant implement as the community ourselves (and this is what nao is reffering to when disconnecting core team and community)
if you want an example of why this disconnect is real - just look at the bn server - the activity and discussion of the dev team is literally non-existent there (and that is the primary place where bns organise themselves)
Probably because there isn't anyone who could or would program such an AI?JPK314 wrote:
Is there a reason this hasn't been proposed before?
There's a reason I said that it was a bad idea, but the point is that 2 BNs are not enough to catch unrankables, so unless we have QA as a safety net, something else will need to be done. An AI program (imo) isn't feasible given that a lot of disqualifications are for inherently subjective things anyways (look at Super Driver for an example of that. Nothing inherently unrankable there, and I'm pretty sure there were 3+ BNs willing to nominate it).wafer wrote:
3 BNs would be a terrible idea. It would make ranking maps an INFINITELY harder chore, especially more niche maps that only a few bns may like.
This is not the solution, and your statement about monetary incentive is the best incentive is just factually wrong. Money is in no way the best incentive, and the only sustainable way to motivate people is to provide intrinsic motivators rather than extrinsic. Doing that is difficult, but I definitely am strongly against offering supporter for those participating in my suggestion.M i X wrote:
I say even throw in a supporter tag for QA members, and tie it to the minimum required activity per month or something. Monetary incentive is the best incentive.
This is definitely not the reason. An AI in the machine learning sense is NOT what I'm talking about - the bigger part of the suggestion is applying slight modifications to the more ambiguous unrankable criteria so that it IS easy to code a program to check it automatically.-White wrote:
Probably because there isn't anyone who could or would program such an AI?JPK314 wrote:
Is there a reason this hasn't been proposed before?
I feel like on paper not needing QA is a good idea, but that leads down the rabbit hole of "how do evals work if there are no DQs" and "what determines if a BN should get probation because of their noms".yaspo wrote:
In terms of Quality Control I'd personally probably prefer a different approach than checking every single damn mapset on a qualitative basis.
I think we'd gain a lot more mileage by digging down (Root Cause Analysis type beat) and figuring out what's really behind these common quality issues, and then looking for a broader approach? Broader being stuff like knowledge sharing, stimulating actually modding, looking into adjusting how we deliver content to different target audiences, etc; anything that can meaningfully change the environment rather than having to fight against the current. It's less controlling but ends up being a more positive effort.
Also agree here, would really help us stop running in circles.VINXIS wrote:
doing a Root Cause Analysis flowchart or some form of workflow/process diagram in listing these issues would definitely help organize everything regardless of the feasibility of that tho
and it also looks like its more of a necessity for this as each day passes honestly, would also help in figuring out which suggestion/recommendation to try out first
apparently we have freedom to change the ranking system as we see fit so if no meaningful changes happen it's only because the people managing the ranking system don't want to or are scared to do any meaningful change.peppy wrote:
we will continue to support any changes that you guys see beneficial (and roll them back if they turn out not to be).
the issues that causes dqs other than what's already in the RC is subjective stuff that needs to be evaluated from case to case, there isn't a practical way to implement those issues in the RCBot wrote:
I propose that we allow the QAH group to add/change the RC every few months or at set points in the year. It can work like congress where members propose rules and if a majority pass it, it gets in. This system would help solve most of the quality control issues as the QAH group would be made of members who are very experienced in the issues that get pass the current RC. It would also provide a better incentive for people to try and join the QAH group and get what they want from the RC.
Currently BNs get punished lightly if a mistake is not an obvious or glaring issue from what I understand based on VINXIS' statements. However issues like snap and things on the RC are punished more heavily. If we go through with this change, we can remove BNs that aren't checking the map as they are suppose to and can hopefully limit the amount of QA needed in the future. (cause all the bad stuff would already be outlined in rc)
(^if that isn't already the case, we should punish BNs who rank maps that go against the RC harder, its a list of things to check, just go down the list and check off 1 thing at a time)
"DQS are bad" We can limit the arguments about subjective issues by using the RC. Any judgments made on subjective issues can be added to the RC by the QAH group and going forward, people can propose new rules to make all DQs objective based on the RC.
We can just do polls between BNs/Nat/whoever within a certain timeframe of a subjective issue, and go with majority rules on subjective topics, then we can add that decision on rcKudosu wrote:
the issues that causes dqs other than what's already in the RC is subjective stuff that needs to be evaluated from case to case, there isn't a practical way to implement those issues in the RCBot wrote:
I propose that we allow the QAH group to add/change the RC every few months or at set points in the year. It can work like congress where members propose rules and if a majority pass it, it gets in. This system would help solve most of the quality control issues as the QAH group would be made of members who are very experienced in the issues that get pass the current RC. It would also provide a better incentive for people to try and join the QAH group and get what they want from the RC.
Currently BNs get punished lightly if a mistake is not an obvious or glaring issue from what I understand based on VINXIS' statements. However issues like snap and things on the RC are punished more heavily. If we go through with this change, we can remove BNs that aren't checking the map as they are suppose to and can hopefully limit the amount of QA needed in the future. (cause all the bad stuff would already be outlined in rc)
(^if that isn't already the case, we should punish BNs who rank maps that go against the RC harder, its a list of things to check, just go down the list and check off 1 thing at a time)
"DQS are bad" We can limit the arguments about subjective issues by using the RC. Any judgments made on subjective issues can be added to the RC by the QAH group and going forward, people can propose new rules to make all DQs objective based on the RC.
"Unrankables" doesn't always refer to stuff in ranking criteria. It can also refer to subjective stuff like a slider not facing the correct direction to be create a more symmetrical pattern, a map being too bland, wrong hitsound usage based on song, or whatever other thing it might be. You basically need something that guesses what imperfections in abstract material might be and suggests how to make it better. That's a no easy feat.JPK314 wrote:
This is definitely not the reason. An AI in the machine learning sense is NOT what I'm talking about - the bigger part of the suggestion is applying slight modifications to the more ambiguous unrankable criteria so that it IS easy to code a program to check it automatically.-White wrote:
Probably because there isn't anyone who could or would program such an AI?JPK314 wrote:
Is there a reason this hasn't been proposed before?
Everyone has that power already, making a second, completely separate way to change the RC is just counterproductive. Discussing potential changes on the forums is infinitely better than any sort of system that's limited to a privileged group.Bot wrote:
the power to change the rc
Isn't that what BNs are for, though?? I'm not saying we remove BNs, just that we remove the need for DQs by increasing the standard that reaches BNs in the first place to beyond anything DQable. Are you really saying that subjective issues that not all BNs agree upon (demonstrated by the fact that at least two BNs approve) are worth DQing a mapset over?abraker wrote:
"Unrankables" doesn't always refer to stuff in ranking criteria. It can also refer to subjective stuff like a slider not facing the correct direction to be create a more symmetrical pattern, a map being too bland, wrong hitsound usage based on song, or whatever other thing it might be. You basically need something that guesses what imperfections in abstract material might be and suggests how to make it better. That's a no easy feat.JPK314 wrote:
This is definitely not the reason. An AI in the machine learning sense is NOT what I'm talking about - the bigger part of the suggestion is applying slight modifications to the more ambiguous unrankable criteria so that it IS easy to code a program to check it automatically.-White wrote:
Probably because there isn't anyone who could or would program such an AI?JPK314 wrote:
Is there a reason this hasn't been proposed before?
@Ephemeral im p sure that's what this was for, lists proposed solutions and their pros/consCheri wrote:
Considering that the thread only has this
community/forums/topics/1268711?n=14 <-- referring an QA extension/Adding a branch
community/forums/topics/1268711?n=15 ^ Me at the same time basically stated a similar thing in detail in a document
CONS ^ was similar to QAT and tried it before didn't work/don't want to repeat anything and lack of interest still
community/forums/topics/1268711?n=59 my adjustments on -White's post
Basically about making a third group w/no BN benefits for non-bns to do QAH to add incentive instead of relying on BNs who don't want to do it.
community/forums/topics/1268711?n=46 ^ the original
CONS ^ No point in doing this after being BN, Having to trust non-bns is risky even with considering they can't dq, not has reliable as an BN, rewards can be considered iffy,etc.
community/forums/topics/1268711?n=85 <--- abolishing the system
community/forums/topics/1268711?n=126 ^ my tl;dr version why just abolishing it isn't the best idea
community/forums/topics/1268711?n=107 ^ the full version + just be me
explaining the same thing in my document a bit better
community/forums/topics/1268711?n=123 <-- refers to having QA as a group making RC proposal and such
community/forums/topics/1268711?n=130 ^ basically rejecting it as RC is fine as is
Outside of that there hasn't been much solutions as far as I see (Vinxis first post don't count as store history is already being added) and anything else that I can add here is redundant (I summarize the cons on the first 2 but it was just skimmed)
tl;dr there is basically only 3 solutions on this thread that is relevant to the topic
Ephemeral wrote:
it takes time to formulate results for these kinds of proposals (especially in this sort of volume). the issue is being discussed though and i'm sure there will be movement on the matter eventually, though i doubt it'll be a 100% pull from any of the proposals floated in here, since that's generally not how things work.
that being said, this thread is a super mess. would be nice to get some bullet point summaries of what the issues are and any proposed solutions since i imagine i'm not alone with my head swimming at the prospect of having to pick through this 140+ response thread and several gdocs to see where stuff is at
-Mo- wrote:
Hi, just a short update from my end of things since I get the silence can be a little deafening.
A few of us have been bombarded with questions the past couple of weeks about whether we are going to do anything. Please be rest assured that we haven't forgotten about the concerns brought up in this thread. While we're still unsure of a solid plan to go forward on, most, if not all, of the NAT agree that some changes are necessary.
As it is right now, we're unlikely to take any of the proposals outlined in this thread as is, however that doesn't mean we're going to dismiss them completely. There's currently some plans behind the scenes to put together alternative solutions, and while I can't give an ETA, we aim to get everyone's input on it as soon as it is reasonably possible to do so.
All I'm asking is to just sit tight for a little bit longer.
Not to be impatient or anything but I feel this is a pretty major issue and there's been some decent suggestions made in the thread that haven't been addressed properly at all. We all agree that changes are necessary, so some kind of update might be nice after 3 months.-Mo- wrote:
All I'm asking is to just sit tight for a little bit longer.
6 months and still sitting tight eh ?-White wrote:
Not to be impatient or anything but I feel this is a pretty major issue and there's been some decent suggestions made in the thread that haven't been addressed properly at all. We all agree that changes are necessary, so some kind of update might be nice after 3 months.-Mo- wrote:
All I'm asking is to just sit tight for a little bit longer.
The lack of a sense of urgency is disappointing, at least to me. Even if the suggestions proposed in the thread aren't perfect, they're probably better than the current implementation (or at least worth trying) until a better solution can be implemented.