I think that we can use technological measures to minimize bandwagoning by benignly-intentioned users, but Wikidot doesn't give us the tools that we need to prevent malicious voting. The best we could do would be to respond to it as it happens, unfortunately.

Otherwise I can support all measures outside of the first one, as it hasn't been tested in another contest before. I do not think they're intrusive enough to cause issue to the userbase, but may help in at least banning some of the malicious votes that occur directly through swapping votes as one entry approaches another on the leaderboard. (I will admit though that I haven't interacted much with the leaderboard part of contests myself).

I do think #1 is an idea worth trying for another contest, just a smaller-scale one first.

I can support both discoverability aid options, but for the second one I have slight worries of clashing with personalized CSS. I think ideally the listpage in this case should have a similar visual style to the wiki-walk footer which all SCP articles are already required to include at some point.

I only suggested the Disciplinary Team because they seem to be a group of people already willing to sort through large amounts of data. It also makes sense because it's already their job to hear malicious voting cases, so there's no reason for them to stand by especially during the big SCP event of the season.

The issue with adding more members to the Contest Team is that it necessarily requires the person joining to be banned from participating in contests for all eternity. Not many users are willing to join the team knowing that they will be cursed in this way, so it is difficult to recruit any members at all…

I'm internally still debating on not showing rating; however, I'm leaning toward not showing the rating but I'm in favour of keeping the leaderboard and ranking. Overall, I agree with Ariadne that 'no rating' should be tested on the next contest. Doing an untested measure in a contest as big as an XKcon feels like a massive gamble to implement.

For Crom, we shouldn't touch this at all since it's another users bot that they manage (and pay for) in their spare time. This feels like it would be an incredible amount of work for them, and quite frankly an unfair demand from staff. (I'm aware that Crom would still show the rating, this feels like a decent middle ground for the proposed obfuscation of rating on the article itself.)

In as far as the contest team, forcing Disciplinary to be apart of the contest team during a XKcon feels like it would put an unnecessary amount of stress on an already stressed team. For the contest team, only three staff seems like a woeful amount of people to mediate contests, especially contests that have well over 100 articles submitted.

I suggest adding more (willing!) trusted staff to the contest team to help alleviate the work load.

I'm rescinding my support for this entire proposal.

After speaking with psychicProgrammer on Discord, these measures seem to have been made while presupposing that:

1. the malicious voters are determined enough to make many alt accounts
2. the malicious voters do not know what CSS is or how to use the Inspect Element tool.
3. the malicious voters are not determined enough to learn how to circumvent these things, a hefty endeavor that requires five minutes of a person's time.

I don't believe this is a realistic profile of the hypothetical malicious voter, and so, I don't believe this proposal will be effective in any way. And given the concerns raised by other people, I cannot support something that harms the experience of the common folk without providing any tangible benefits in return.

As for my own analysis of the situation, I believe that the root cause of the problem is a shortage of manpower. This is because only three people — psychicProgrammer, Naepic, and Whiteguard — were involved in the process of sorting out malicious votes during the SCP-8000 contest. Because of the work-load they had to endure, these members of the Contest Team received grievous injuries and almost died. Well, I have a solution…

I recommend impressing the entirety of the Disciplinary Team into an Anti-Brigading Contest Task Force that will work closely with the Contest Team to rapidly identify, apprehend, and eliminate all malicious voters during the contest. This will remove weight from the shoulders of the Contest Team and put these matters to a swift end. The Disciplinary Team has also very recently demonstrated their ability to expedite malicious voting cases, so this seems to be the most clear and obvious solution to the problem…

Well, this is just my opinion, but please let me know what you think…

I do agree with Dagon though that a 'hide-a-vote' contest would be really interesting as a stand alone! I think doing that as a contest next year as a much better idea, to get an idea of the challenges of running something like that in a far less high-stakes environment. Much like Classic-con, I really do think we might see some real upticks in posting, as well as a sort of excitement we're not used to that could energize the writing base. Just again, not as a kcon.

Plus, people will complain and break down whether they can or cannot see votes. So I personally think hiding the vote numbers is fun and worth giving a shot. Ideally it should have been done on a previous, lower stakes contest, but thats not how time works

as for my thoughts on 1, i dont think it would be good for the collective mental health of the site to have the rating of your article effectively be in limbo for a month and a half. without naming names, two users who were in the top running of the contest were effectively breaking down daily because of the uncertainty caused by the brigades, closeness of votes, and incoming adjustments. now imagine everyone thinking they are both winning and losing simultaneously, collectively, on a mass scale. this is a recipe for disaster.

The other points i agree.

But as was discussed in previous threads, one of the most sure ways to prevent another 8kcon incident is to close applications for the duration of the kcon, wether you like that or not.

1: All entries in 9Kcon will be under a special 9000: category with CSS to hide the score of articles

I’m not at all a fan of this. This is a measure that doesn’t solve any issues and only serves to make more work for everyone involved in the contest.

As a “victim” of the SCP-8000 contest controversy, I outright oppose this specific solution. If this were implemented for 8kcon, it likely would’ve made my experience worse. It’s incredibly important that there is some metric for authors to see how their articles are performing. It sets expectations, and will prevent people from getting extremely stressed out like I did.

A lot of these solutions focus more on punitive measures rather than creating an environment where the authors feel supported, the readers can enjoy the content, and staff can mediate. Instead, this sets up a system where authors will be left unclear on their positions, leading to potential stress and confusion. Authors will find ways to view their scores, but if that’s found out, they’ll be punished.

Expecting users to go a month to a month and a half without knowing where they rank is absolutely unacceptable.

There’s also the possibility that, without being able to see upvotes as a vague metric of quality, offsite readers only read articles written by authors they know produce writing they enjoy. We saw with ClassicCon that the site can rally around two newer or lesser known authors and the vote count allows everyone a way to show support. Removing it removes an active socialization tool, and may push readers to stay confined in what they know rather than exploring the plethora of writing Kcons produce.

I think pushing for less room for malicious actions is good, however, this is not the solution. It only obfuscates the issue and pretends is doesn’t exist, rather than tackling it as the source.

I support the banning of leaderboards on author pages and the removal of the CROM list ranking.

ETA: I don't think the removal of leaderboards, the removal of the CROM list, or banning the entries from the Top of the Month does anything to meaningfully solve the issue of malicious voting as well. After some thinking, I don't support any part of this proposal.

Historically we have had two Kcons where there was large scale vote manipulation, namely 8kcon and 6kcon. As far as we can tell these only happen in cases where there are two or more entries that are numerically close and tend to be driven by the semi onsite fanbase. As such we propose obfuscating voting as much as possible.

Now our proposal for this is a multi step plan:

1: All entries in 9Kcon will be under a special 9000: category with CSS to hide the score of articles
2: We remove 9000 entries from top rated by month and other top rated pages
3: The exception is lowest rated pages to allow for normal deletions, articles under -10 will be moved to the default category for vote inspection
4: A formal ban any use of listpages on author pages or work benches for identifying contest votes
5: Crom has been set such that any 9000 entry will not show its score and the 9000 tag has been blocked from list (SCPPER will not need any changes as it does not display non _default pages)

This should solve the problem of malicious votes by denying the opportunity to identify close races.

Additionally there are two other things we would like to add to aid in discoverability:

1: Somewhere on the front page we have a link to a random SCP entry
2: At the end of each 9K entry we require a link to another random entry via listpages, we put this into a div to make it clear it is not part of entry.

This discussion will go on for one week