O4 LINK

https://scp-wiki.wikidot.com/forum/t-18119919/discussion-change-in-jstaff-promotion-policy-and-implementat

FOREWORD

It is no secret that staff have a bit of a recruitment crisis. We have lots of bottlenecks, with some teams being carried entirely by one or two people. This proposal aims to man the decks, so to speak, and introduce a bunch of fresh blood to keep our system pumping. This is not only a proposal for policy change, but also for a new team! The Promotion Team! (PT)

SO NOW WHAT?

This proposal would see the PT replacing all current recruitment threads with a few more specialized ones, and would work as a fast track system from normal member to jstaff. As we all know, jstaff is meant to be a low-risk, brisk, trial role where we see if the user in said role is capable at what they do. If they are, they are promoted. If they're not, they are either kept around for another cycle to allow their skills to develop, or are removed.

Sub/Captain will be presented with candidates for their teams, and PT will be in charge of communicating with candidates on whether or not they have been accepted. Teams that will not be affected by this include: Admin, Anti Harassment, Disciplinary, and Internet Outreach for what I hope are obvious reasons. Internet Outreach is a bit of a special case, but it requires special vetting, so it might still go up for open recruitment. Anyway, in order avoid certain problems, all jstaff candidates will be required to be site members for at least 100 days before being considered for staff.

HOW WILL THIS LOOK?

It will be a little different than current promotion systems, but it will remain similar. Sub/Captains will still have final say, but candidates will be suggested to them by members of PT who actively keep track of the threads for jstaff promotions.

One minor thing, MAST will no longer be in charge of promotions, thus shifting a bit of priorities from the team and lessening their scope. It will work exactly the same, with all candidates being submitted to a team member who will collate everything into a promotion master post.

WHAT HAPPENS IF WE DON'T DO THIS

Shit stays as it is. This system may not be perfect, but it's better to try something new than nothing at all and choke ourselves out because we miss out on potentially good candidates.

MORE SPECIFICS

So to summarize, the scope of this team will be as follows:

• PT members will monitor staff recruitment threads for new candidates
• PT members will be required to be familiar with Team Sub/Captains
• PT members will ping Team Sub/Captains in a new channel in Staffcord, creating a new thread for the candidate where the Sub/Captains will discuss and ultimately approve/deny the candidate.
• PT members will communicate with new jstaff members and invite them to Staffcord
• PT members will provide new jstaff members with the usual orientation given to every new jstaffer by Nico.¹
• PT members will be in charge of gathering promotion candidates and tallying votes.

I, Nico² , will be captain of this team and will be looking for volunteers within staff and outside to staff this team. I have asked Bread to join, since they are the usual person who runs promos, and I would be thrilled to have them on my team. Autorickshaw for life.

Threads will be more geared to asking questions forwarded by Team Sub/Captains or asking questions such as "What are your qualifications for joining this team?"

POSSIBLE PITFALLS

"But wouldn't this increase bureaucracy?"

Eh? Not really. Team Sub/Captains are too busy doing actual work to look at the promo threads. Think of this as lighting a fire under their ass to actually respond.

THE END

Thank you for your time.

Special thanks to Prismal, Ari, and Aster for reviewing this and Harry for being my friend.

Discussion will go on for 1 week.

+ show block

– hide block

Footnotes

1.

2.

Hello there everyone! We deeply apologise for the delay on getting these answers ported over, a lot of other staff projects ended up taking priority for many members, and the Data Analysis team went through a lot of changes in membership as well. Data Analysis as a team is more solid again so we now have the responses ready for you all.

We don't know how often Town Halls will be held in future, but we would like for them to pop up again. We would also like to remind all members to remain civil in their questions, as we had to ignore some received bits of feedback that were particularly pointed/rude.

This is your chance to express thoughts and opinions on responses, so if there's any issues with the responses feel free to speak up now!

Discussion will last for a week.

Contests

Not really a complaint at all but it seems as though events have been handled really well this year. PDcon absolutely knocked it out of the park and it already appears as though Classiccon is a huge hit. I'm not sure the right term for the more "unofficial" events (e.g. draft swap, intcanoncon, Pridefest) but those have also knocked it out of the park and have been incredibly engaging. The event staff have been incredibly diligent, both across the wiki and on the discord. I also have to give props to them with how the overlap between Pridfest and Classiccon was handled, everything was done in a truly respectful manner and was a fantastic step up from the wrathcon stuff from last year. Community Outreach also did a really good job at promoting Pridefest and seem to be doing good to promote Classiccon right now.

Now that we're a little over halfway through the year, I feel pretty confident in saying that revealing the approximate dates of (official) contests is an improvement on the way things used to operate, if for no other reason than the fact it helps fight FOMO if you don't have the time/energy to take part in any particular contest. I hope the team decides to do that again next year!

Seconded, it's amazing to have a preview of what contests are gonna hit, especially when you have a very rigid schedule and want to plan ahead. Great idea for sure!

Just wanting to say you're doing an amazing job with contest lately. Hubs are beautiful, and themes are really cool. Congratulations for that! Keep up with the great work

Everyone with positive feedback for the contests team was so kind, thank you. We’ve been trying to improve scheduling transparency and are working on a calendar to make it even better in 2026, so it’s good to hear it’s already been making a difference.

My one "complaint" is that I would like to see the art side of the wiki involved a little more in these events. I was a little disappointed when the art component was removed from whatever Classiccon was going to be but Pridefest handled art really well. Granted I am almost entirely certain my itch for an art event will be satisfied with sciptember and art exchange and I have full faith the event teams will handle those well.

Gonna mirror cptsquid's comment a bit and say that I would really like to see a fully artwork themed contest. Maybe it could even be linked with a writing contest and we have artists submit their work for writers to pick from for creating articles to attach to the pieces. I think it could be a fun indirect collaboration effort. Really any art based contest I think could be a lot of fun.

While we're still debating the feasibility of art & writing contests, we will def take the demand for an art-exclusive contest into account.

I think the events on the wiki are great, and that making and regimenting the calendar for the events , along with making it more visible, would be able to help shine some light on these events. I think that just adding a link under "Contest Archives" to a page like "Upcoming Events", and putting a table there with the information, would be a great move.

A schedule page with a yearly calendar is currently in the works. It'll have its own page alongside a submission form for unofficial contests to be placed on the calendar, so as not to clutter the existing archives page.

Agree with Wynths, there should be a Contest Archive page a la the Canon Hub, Curated Lists, etc.

We already have a contest archive! You can find it here: Contest Archive

Perhaps more prep time for events? i sometimes will skip them if the writing time is particularly short.

Prep time depends on the type of contest at hand, so short prep times are usually intentional. If there’s general demand that our largest contests (like Kcons) should have longer prep times, we’ll totally consider it, but as of right now that doesn’t seem to be the case.

the anthology events were really cool. I appreciate the effort people put in to create unique events.

Thank you for the kind words, but we don’t run anthology! We’ll let them know you thought so :)

Please actually make Pride Fest last all month in the future. No interrupting it with a contest announcement ten days before the month ends, no saying "We're only doing features for half a month", none of that. The world's scary for queer folks right now and seeing an allegedly queer-friendly space take half-measures for the sake of an arbitrary schedule is disappointing.

Staff are currently working to make Pridefest an official event, so rest easy on that front! Additionally, June will now be dedicated exclusively to Pridefest, and no other official events will occur that month with the exception of five-year anniversaries. Staff discussion concluded that since we can't really move the anniversary date, five-year anniversaries will also occur in June.

Internet Outreach

I think it would be good to see Community Outreach post more regularly on the Wiki’s official social media pages. Right now, quite a few of the official pages haven’t seen activity in months, or only see infrequent posts, which is a shame because these spaces are great ways to reach people and get more eyes on the Wiki. As it currently stands, here are the stats:
Facebook: The last post was from January 23rd, and the second last post was from August 27th 2024.
Twitter: The last post was from June 22nd, promoting Classic Con, and the second last post was from November 2nd 2022.
TikTok: There aren’t any posts by the Wiki. Further, there are only 5 reposts and 6 videos in playlists, all of which seem to have been from around 2 to 3 years ago.
BlueSky: I want to compliment whoever is running this page, as it receives fairly frequent updates that include sharing art, different works, and recent happenings on the Wiki, such as contests. However, this social media page isn’t advertised with the others in the Wiki’s sidebar. At the very least, it should be added, perhaps as a replacement for Twitter if the Wiki wants to go that route.
Instagram: Once again, I want to compliment whoever has worked on the most recent posts on this page. They’ve gotten good engagement, and people are clearly enjoying the content being posted. However, posting on this page has been infrequent. They’ve been 4 posts over the last 2 weeks, followed by 1 in May, 2 in March, then 1 on August 27th 2024. Also, there hasn't been any posts regarding contests or other Wiki happenings. While I do like the current content being posted, and it's clearly working, I do think there should be a mix of fun posts and posts about news/events, rather than purely fun.
Reddit: This is by far the most active social media page the Wiki has. Full compliments to the team that keeps this page active and moderated. They’re doing a spectacular job.
I know from experience that maintaining a social media page is difficult. Creating and posting content, reading and replying to comments and keeping the page updated with new profile pictures, descriptions, etc is hard and time-consuming. I also don’t expect Wiki to post multiple times daily or to produce highly edited content that takes hours to produce.
But there should be more frequent posts, especially on platforms like Twitter and TikTok that have seen little or no activity. There are always new/old articles and art that can be posted and promoted, as well as important events like contests or town halls like this one. And with more activity comes new eyes that will make their way to the Wiki to read and perhaps contribute. At the very least, I think a few articles being promoted each week would be a great first step, and help get more eyes on the Wiki's socials and the Wiki itself.

The Internet Outreach subteam has been having consistency issues primarily due to a lack of personnel. As mentioned in your post, maintaining dedicated social media platforms with consistent activity is a multi-person endeavor, and IO has been seeking skilled individuals to recruit for a while. We hope in the future to continue expanding IO and ensuring its operations are entirely self-sufficient and (most importantly for volunteer work) fun.

To address specific platforms:

The Facebook was largely maintained by a singular member of staff. After they retired, it largely fell by the wayside, especially due to its relative lack of meaningful activity prior besides article highlights and announcements. IO is still looking to staff the Facebook.
The Instagram was largely mirroring the Facebook's posts for much of its lifetime. As of recently, a new staff member took up the Instagram as an individual platform, and they are responsible for the platform's revitalization. We are still seeking new users to staff the platform to prevent burnout.
The Twitter and the Bluesky mirror each other's posts. The Twitter has been posting just as frequently as the Bluesky.
The Reddit has thankfully avoided burnout by being a moderation position rather than content creation position.
The TikTok has suffered from several major issues that has prevented its revitalization, namely: 1. its content creators being removed from staff due to external factors, 2. difficulty in consistently producing shortform video content, and 3. conflicts between personal monetization and staff accounts being unmonetized. IO has continuously attempted to fix these issues, but there are many other problems that we have to address first.
We will continue to recruit personnel and work on solving the issues that prevent consistency. We apologize for this turbulent period.

Hi!, I feel like the community outreach team could probably be a bit more consistent with posting in other platforms such as tiktok or Instagram because while the posts there are good, they are quite rare, with weeks long pauses between posts, which I believe could be improved

You're absolutely correct in that regard; please see our comment above for further details.

A few years ago, the subreddit did a "No Nut November" event where discussion of articles above +500 was banned. Can something similar be done again, either on the subreddit or on the main site?

We will forward this suggestion to the Reddit Subteam as a potential event (or something similar) to do in the future!

Data Analysis

I wish staff would take the feedback they get from town halls as seriously as they take the feedback they get on their writing. It's genuinely disheartening to see basically nothing suggested in town halls actually get implemented or discussed further, with basically every response in the last three years being just a gigantic shrug. I'm not sure if staff's just out of touch, or if they genuinely do not care about the state of the site at this point.

Town Halls are a time when the community is better able to raise potential concerns or suggestions about how to better the wiki. While staff wants to provide this space, we focus on solutions that are appropriate for the wiki, based on countless factors and coordination between teams. While it may seem like staff doesn't do anything with these comments, we actively discuss them, and try to find solutions that work for all users.

Just wondering why this doesn't have a "Where can we follow up" entry like it did in previous years.

This was done to protect the identity of anonymous submitters; while 'where can we follow up' allowed for further communication, it also negated the concept of the submission being anonymous. To help users feel safe in giving anonymous feedback, that was removed for this year.

Critique Team

It isn't very easy to post your first article; you may not get greenlights right away, and may have to reach out to reviewers.

This is the system as intended. Greenlights are never guaranteed, and as our reviewers are all volunteers we do expect authors to contact them directly if they want feedback. You need to be ready to put in effort if you want your work to be successful! We will always have far, far more authors than there are reviewers, and you're not likely to make friends or see success if you see contacting them as an obstacle instead of an opportunity. Success lies in collaboration, it's how a community grows.

I don't think, as a rule, Crit Staff on 19cord (especially in writing-general) should be referencing their own works as "examples" when providing writing advice. It's not a good look, and there are hundreds of other articles that would work for just about any writing question.

Users tend to link the first article that comes to mind when offering examples, and it isn’t unusual for users to recall their own work before that of others. Likewise it's easier for an author to speak for authorial intent on their own work versus another, which often makes it easier to use as an example. They're able to speak with confidence as to why they made the writing decisions they did. Please remember that all users are encouraged to provide whatever examples they feel are relevant during writing discussions.

Curation

Would be cool to have additional page links at the bottom of certain SCPs that would lead to related tales, art, and MTF's. For example a link at the bottom of SCP-008 leading to Operation "Camp Granada".

While we support linking connected tales, art, and more, the body of an article is considered under the creative control of the original author — we absolutely encourage that connected stories crosslink to relevant pages, we do not have any current plans to make larger edits of that kind.

Disciplinary

There should be more transparency in regard to 05command. In particular, the Disciplinary Team is somewhat opaque, and has received criticism in the past for their handling of certain issues (such as when Metaphysician was banned), which I personally feel have not been adequately addressed.

We are constantly striving towards better transparency on the Disciplinary team, while also balancing what information we share. This is important, not only to protect users, but so that we can continue to operate effectively in keeping the wiki safe. In the past months, we have also prioritized better explaining aspects of our decisions publicly, and will continue to work towards better transparency in the future.

Deletions

I feel it was a mistake for staff to honor Kalinin's requests for deletion of his pre-2015 works. He was a toxic user for well over a decade, but his works had merit, and seeing them nuked from the site at the request of someone who should have been permanently banned for low-effort and hostile critique feels wrong.

Our previous rules required us to enable the deletion of the pages, which we largely agree was an unfavorable outcome. However, as was discussed and voted on between Jan-Feb of 2025 in the following threads:

- https://05command.wikidot.com/forum/t-17018475/discussion-on-the-preservation-of-important-works
- https://05command.wikidot.com/forum/t-17024639/discussion-preservation-of-important-works-pt-2
- https://05command.wikidot.com/forum/t-17029186/voting-deletion-self-responsibility-slug-reservation
Staff will no longer honor deletion requests on behalf of authors.

We will unlock pages that are locked to facilitate this if requested, but staff will no longer be honoring deletion requests; I.E.: if an author deletes their account and returns, staff will not be deleting the works they published under their old account(s) for them, but we will unlock new ones made on their current account (assuming they had to be locked for whatever reason) at the author's request. We will additionally not be stopping authors from deleting any of their own pages, should they choose to do so.

In short, staff-facilitated deletions are no longer an option moving forward outside of regular deletion procedures.

Tagging

I know it's not the site's fault, but like the tags have disappeared when I click on them, and the cache is fucked up per usual. Otherwise, everything is fine.-

Fairly regularly tags are changed by members of the team as new ones are introduced or incorrect or invalid tags are removed from articles. Are tags disappearing on articles, or within the tag navigation cloud you're brought to when clicking on a valid tag?

Navigation

A lot of questions regarding the front page were presented. They can be seen by opening the collapsible below:

The Front Page has been updated to expand on discoverability and further expound on important navigation landmarks. It is expected to be further iterated upon with further feedback and streamlining.

It would be nice if with the spotlighted pages there were links to the highest rated article in the last month, or the most recently posted article, or some kind of "highest rated in proportion to author's overall rating". This would help solve the problem of not getting eyes on lesser known works.
These are all things a reader could figure out for themselves, but having them readily accessible drives more attention that way.

These links are present on the front page, which also leads to dedicated pages such as Shortest Pages and Top Rated in the last Month.
"highest rated in proportion to author's overall rating" is currently not feasible or difficult to implement with regards to sitewide servicing.

Readers will always have a bias towards reading the new works of established popular authors first, but I think we can combat this by changing the Reader's Spotlight on the front page to prioritize first-time nominees. As in, smaller authors who haven't had a spotlight before. That way, we can give them 15 minutes of fame while also highlighting a hidden gem.
Also, the "Featured SCP" has often been one that was chosen by the same user that wrote that article. Perhaps that shouldn't be allowed?

The Reviewers' Spotlight is meant to be a reward for reviewers, not a chore, so I am hesitant to add strict requirements to what spotlighted reviewers are permitted to feature. I can recommend that reviewers prioritize spotlighting works by newer authors; ideally this would be accompanied by some resources to help reviewers efficiently find quality works by smaller-name writers.

I have no intention of disallowing self-features, especially in the cases of front-page features granted as prizes for winning contests and features granted for participation in the Critique Team mentorship flights.

Presently, the sidebar's UI design encourages users to start reading with Series I, which does not reflect the community's current culture or editorial standards. I think this probably contributes to the number of new users who post 2008-style articles, believing they are still in vogue.
I propose changing the "SCP by Series" module to descending order, with the latest series at the top and Series I at the bottom. This would provide some subtle encouragement for users to start with more modern articles. Additionally, if staff adds a sidebar link to the 001 Proposal landing page, it could improve visibility for those articles.

I'm not sure if I'm supposed to reply to posts on here, but I want to heartily second with the notion that the UI design encourages new users to look at Series I SCP's. As a newer author on the site, I was quickly discouraged by the amount of criticism I received that my ideas and writing were too "series I", because earlier series (1-3) is most of what I read before trying my hand at creating SCP's. I legitimately thought, as mentioned above, that I was supposed to start with series 1 by the site design.
I would also lightly recommend that canon hubs be pushed higher, as it is an effective form of tight-knit community building and could pull people into specific niches of the community faster.

This is partly addressed with the Front Page directly linking to the newest Series.
Your suggestion will be further discussed in tandem with future plans, as we approach and surpass Series 10.

I would love to see the sidebar re-worked.
As it is, the sidebar sits in an awkward area of not being comprehensive, but having too much stuff for a non-comprehensive resource.
It also has a lot of options that are not intuitive to people who do not have previous experience with the site, which makes things even worse.
I think the categories should be dropdown menus, so people aren't overwhelmed by the number of links. Each menu could also have a link along the lines of "what is a series?" or "what are non-article pages?"
Or if dropdowns aren't desired, then the headers could just link to other pages which provide the links and explain what they are.
Additionally, the sidebar is where people are going to check first for different things. If they don't find it on the sidebar, they might never check the drop down menus at the top right.
I am speaking from experience here, since I didn't realize there was a direct link to the guide hub until today.
Either the sidebar should be more clearly labeled as being just about discovering new articles, or more should be added to the sidebar, such as links to guides and other out of character pages.
Thank you for your time!

The sidebar is designed around being a quick navigation menu that's accessible everywhere, thus it contains most pertinent links in that regards.
Collapsible has previously been examined, but being collapsed lead to the risk of it being overlooked completely, especially at a glance.
With consideration to the site as a whole, the onboarding process for familiarizing links is being moved to the front page.

"Either the sidebar should be more clearly labeled as being just about discovering new articles, or more should be added to the sidebar, such as links to guides and other out of character pages."

This previously resulted in massive bloat, so we usually seek alternative layout solutions.

Does everyone else have a ton of bookmarks in a folder called 'scp' in their browser too? I wish there was a system to save/favorite pages, and a way to list pages you've rated already. Is there some alternative here I'm missing? I dont want to keep fighting to keep bookmarks organized ×o×

This feature is currently available with crom

a different complaint, minor one at that. i kinda wished the scp title shows up with the number. i felt like we are approaching to 5 digits very quickly. i think alot of users often mix up the numbers and imo it might be a little helpful for the title to show up? idk how much this helps and i wouldnt mind if this doesnt happen. just a minor suggestion ig

While technically possible, this would be highly impractical, as this would require staff to go and manually change the titles of over 9000 individual articles.

Adding onto this, I'd actually love if the SCP titles showed up in the Newest/Top Rated/Shortest feeds. I don't know how difficult it'd be to do, but I feel like seeing the title for the SCP you're going to read makes it easier to stick with you. Plus, some titles are really eye catching.

Without the implementation of the previous suggestion, this would likely slow down listpages significantly.

Tech

The wiki's behaving weirdly as far as HTTPS is concerned - I often get a "this site doesn't support HTTPS" page from Firefox when I open the wiki (as well as SCP-INT), but not all the time. It's been like that for years at this point.

It is possible you're using links with scp-wiki.net, which for technical reasons, is not https by itself, but redirect to scp-wiki.wikidot.com. Otherwise, https requests can sometimes be dropped/downgraded for unknown reasons, which a reload usually fixes.

This is only regarding the English site, as SCP-INT and some branches do not support https at time of writing.

Not sure if this is the case for anyone else, but the "click to scroll to footnotes" thing on footnotes has never worked for me, on PC, Mac or Android mobile. Is that a known bug?

As far as can be ascertained, Wikidot uses a jQuery version of scrollTo (as opposed to browser-native scrollTo API), which is long outdated and no longer works on Chrome and other browsers (but still works on Firefox, surprisingly.)

Reference: https://github.com/flesler/jquery.scrollTo/issues/164

Accesibility stuff for articles could be cool. Options for colorblind people, options for people who would prefer a dark page, or options for people who wants to read an article using the standard theme.
Could be a site-wide thing, could be components.
But specially accesibility stuff can be really cool to have here

Can we get a dark mode? Most of the time I'm here is when insomnia has struck, and opening the site is blinding.

Any sitewide functions and/or accessibility options are technically difficult to implement currently.

On the whole, Tech is working on improving overall accessibility for the site as part of our audit process.

Before I start I want to thank the staff for maintaining the wiki. Y’all are awesome
I’m curious about a specific technical thing.
When pages on the wiki are loaded they appear to load in several time. As in if hit my hotkey for the previous site I was on it will send me to one identical to my current one.
I have included a video demonstrating what I am talking about.
I’m curious about the technical reason for this occurring as it does not occur on the sandbox wiki, O5 Command, or The Backrooms wiki (which is also hosted on wiki dot).
Edit: Apologies if this is not the right place for this. I didn't see the other threads when I made this.

When browsing the wiki through the Safari browser on mobile, every page creates several “duplicates” in my history that results in having to press the back button far more times than should be required.

Staff has looked into this issue, and is narrowing down how it occurs on Safari. Investigation is ongoing at the moment.

Please stop approving new themes without the guarantee they're going to be widely used. Most of the themes on the site look ugly and reduce accessibility.

If any pages on the site are hard to read or otherwise possess accessibility issues, do report it to Technical Team to be addressed when possible.

"Ugly" is a subjective judgment and is beyond Technical Team purview.

"Hi, aspiring SCP author here (just waiting to turn 18 to participate). As cool as ACS and the new and unique page formats are, the device I read on can't process the graphics, so I am unable to enjoy most of the newer SCP articles (from about 4500 on, actually). Imo there should be a way to access the content without the graphical code and flashy formatting. I don't always have access to a computer, and I really would like to read more recent articles more often, to see what kind of writing style the community is looking for. Thanks!

More information is needed per your device's specification and browser version.

Most components and formatting on site are standard HTML and CSS, which should be performant on every relatively modern device and browsers.
In a pinch, your browser may have a reader mode that can be turned on, as there is no other available easy method for blocking a page's CSS.

Wikijump

I've looked at the Wikijump site, and there has been no update for a while… is the project dead?

So is Project Foundation just dead?

We are still actively contributing to Wikijump development. However due to circumstances we haven't been keeping up on putting out update blog posts - usually we only post when there are significant updates that we really wanted to talk about. But rest assured that features and improvements are still being made, just not posted on.

If Wikijump ever happens, please consider accessibility options such as changes in text size, being able to fully hide the sidebar and top bar on any theme, and high-contrast mode. A large portion of our userbase relies on content farms that do not represent the work of this site in order to 'read' what's on the wiki because of its lack of accessibility features, on top of other technical issues.

Yes, the overall improvement of the user experience is one of the important aspects we strive for in the Wikijump project. But the core functionality always comes before polishing, and in this stage of development we focus on having a basic site that is capable of importing data from Wikidot sites and displaying them correctly. We will work on the user experience improvements when we think the underlying features are ready.

Bright Works Project

Cancel this town hall until you're done dealing with Bright's bulslhit. Stop kicking the fucking can down the road.

The Bright Works Project is an asynchronous collaborative effort within staff that is unaffected by other ongoing staff efforts. Town Halls was not a factor in impacting progress within the Bright Works effort.

If you aren't going to do anything about Bright's works after literal years of discourse and months of public thumb-twiddling, just change the site's tagline to "Sexual Creeps and Pedophiles" because your failure to make any meaningful moves regarding his work is a tacit endorsement of them. Also unban Siddhartha.

Staff is actively continuing to work on the project, and is focused on ensuring that any solution is a permanent one, rather than a quick solution.

Article Discoverability

The Wiki overall does an awesome job at promoting a wide variety of works on the site, but there needs to be more done to promote the works of lesser-known authors.
Throughout my almost year on the Wiki, I have noticed that there tends to be a focus on promoting works by well-known authors. This makes sense, as well-known authors have a reputation for releasing high-quality work and have also gained the trust of readers over time as a result. Thus, when it comes to selecting promotion via things like front page features, their names and works are more likely to come up, and consequently be promoted in those spaces.
But I think this has had the unintended consequence of making it much harder for lesser-known authors to have their works seen, as the majority of promotion is taken up by works that have already been seen by a large chunk of users. Further still, it creates the false illusion of an ‘in club’ so to speak that tends to promote works from certain people. I want to say I don’t think such a thing exists, but consistently seeing the same names and works in the spotlight can certainly give that appearance to new users.
Before I continue, I want to say that not every work on the Wiki can or should be given something like a front page feature. There are thousands upon thousands of works on the Wiki, and promoting each one equally is impossible. Further, not every work by a lesser-known author is a hidden gem. Any promotion of a work should be done solely based on its quality, not because the author is newer or not as well-known or the opposite.
I also acknowledge that lesser-known authors do get promotion. I’ve seen many fantastic works be promoted via features or recommendations by other users that are from lesser-known authors or new authors. Promotion for any article is possible and happens frequently.
However, more could be done, and taking action on this issue would be of significant benefit to Wiki. Promoting a wider variety of works from a wider variety of authors exposes readers to works they might've otherwise missed. Further, it'll help to bring to light canons, GOIs, etc that might've not seen a contribution to them or a work using them for some time. That in turn could see them have more works contributed to or involving them.
While I have mentioned front page features frequently here, they aren't and shouldn't be the only method of promoting lesser-known authors. Curated lists, for example, could be a fantastic way for users to find a wide variety of works from a mixture of well-known and lesser-known authors. Another method is to promote the use of the random page feature. Currently, it's very hidden away, which is a shame because I think encouraging its usage and potentially having it become more prominent is an excellent way to have works seen.
Another option is via community outreach. The Wiki has a presence on sites like Reddit, Twitter and Facebook. It would be great to see more articles posted by the outreach team in these spaces. It will bring new/returning users to the site and help get some more eyes on a variety of works.
In sum, I'd like to see more promotion for lesser-known authors, as it's an area that I think needs improvement and that can only benefit Wiki in both the short and long term.

i'll second the suggestion about curated lists - having a list like "Plague Thinks These Articles Are Funny!" or "Queerious' Tale Den", would do a number for encouraging new users to both see and think about articles that the wiki in general thinks is good. it might be difficult to get people to attach their names to a list like that, but it could be worth a shot.

The long and short of it is that front page features are selected in one of three of the following ways, each one less common than the last; Crit flight selection, contest winner selection, and staff selection.

I'll explain each of them.

Crit flight selection is, as stated, the most common. For these we allow people who have completed a crit flight to promote whatever they want, which most of the time, ends up being an already popular article or something they or a friend wrote. In some instances, the leading moth/butterfly may select something as well, particularly if one pair already chose an scp to spotlight and their mentee already chose something.

The second method is contest winner selection. This only happens when there's contests and front page features are usually the reward for these. Again, people either show off their own work or a friend's work.

The last and least common is staff selection, which only happens twice a year if I recall correctly. This is when someone (usually zyn) selects all three spotlight articles because there was no contest and no crit flight.

So this only comes down to one controllable vector: the staff selects.

I would be lying if I said zyn has no bias because we are all human and all have biases but I think she strikes a good balance of new and old, unknown vs known, etc.

Plus its only (at least that I can recall) only twice a year that it happens

Miscellaneous

I think we should retain the design that makes it as difficult for people to become authors as possible. The continued health of the wiki is dependent on maintaining a large, active readerbase. More resources should be allocated to reader navigation, and aid in becoming an author should be downsized and authorship disincentivized.

It's not a zero-sum game. We want to make it easier to become an author and make navigation easier for readers. Suggestions for both goals are always welcome.

I would love for there to be a comprehensive Rules document for all the different rules (forums, discord, posting, self-promotion, etc.) and at least one staff member with the job of keeping the rules document up-to-date. It's so incredibly hard to integrate into this community when there are all these unwritten rules about when and where and how often you can do things

Staff has been working on adding a comprehensive set of links to the main site rules page to address the issue of rule discovery. (Attempts to create a single comprehensive mega-document haven't gone well, so we're trying a different approach.) If you have suggestions for additional pages that should be linked, or if you believe that certain de facto rules aren't adequately documented anywhere, please leave a comment in the discussion page for the Site Rules or chat with staff in #site17 on SkipIRC or #observer-discussion on Staffcord.

Semi-related, but the current "tags" system also contributes to the "in club" illusion, as the requirement for making a new tag about an SCP('s title) (eg "hard-to-destroy-reptile") include "must be referenced by multiple articles" & "must be referenced by multiple unique authors". This inherently favors older &/or more popular articles getting tags about them (further increasing their visibility), while newer articles have to hope that they use the right tags to hopefully attract a reader that can increase their visibility.

Tags are descriptive, not prescriptive - its purpose is to serve as a navigational tool to assist in categorization and underpinning discoverability, not as a "reward" or some such.

As Wikidot does not have a robust tagging system like AO3's, Tech's requirements exist to prevent bloat, and establish that a tag has, or will have varied uses in the future that can't be easily grouped otherwise (as seen with many character tags, both old and new.)

While there may exist perceptions of tags as an achievement (a la Goodhart's law), this is primarily a sociological component that Technical Team has no control over.

Introduction

Communication is a fundamental element of any organisation, including the SCP Wiki. Failures in communication, such as those during the Bright Works Project and November 2025 incident, have resulted in a dissatisfied user base, increased staff workload, and a loss in trust resulting in users and staff leaving the Wiki.

These events have demonstrated a need for a staff team dedicated to handling complex, public-facing communication in all its forms. A Public Relations Team, or PR Team for short, is the answer. The PR Team would work to prevent further damage and begin closing the gap between staff and users, helping to create a more unified SCP Wiki. It would also help refine critical communication from staff, aiming to prevent situations like those mentioned above.

Team Duties

Given the nature of a Public Relations Team, and the increased workload that comes with this kind of work, the team must only be brought in to handle specific tasks. It cannot be treated as a one-stop solution for every form of communication from staff.

It is not possible to list every duty the PR Team may undertake. However, before the team is called in, one question must be asked:

Will this staff action (or inaction) result in noticeable community dissatisfaction?

If the answer is yes, the PR Team will be called in to assist.

Examples Of Public Relations Team Duties Include:

• Acting as a final review for Disciplinary and Anti-Harassment Team threads before they are posted. Importantly, the Team would only have access to documentation intended to be made public.
• Assisting with user complaints to ensure both the user or users and staff feel heard, with the aim of reaching a satisfactory resolution for both parties.
• Acting as front-line communicators during critical situations where members of the community are dissatisfied.
• Drafting of critical policy or statements before they are presented to users. Critical policies or statements are defined as being:

1. Are related to something that would be a major change or event on the site (such as structural changes).
2. Needs to be urgently created, implemented or released.
3. The community, staff or both are heavily invested in its outcome. There may also be segments of the community that are concerned or highly critical of the policy or statement.

Examples Of What The Public Relations Team Will Not Handle:

• Answering basic questions from users that can be handled by the relevant team.
• Assisting with inter-team communication.
• Reviewing Disciplinary and Anti-Harassment Team materials that are not intended to be posted publicly.
• Drafting of non-critical policy or statements such as event announcements. Non-critical policies or statements are defined as being:

1. Aren't related to something that would be a major change or event on the site (such as structural changes).
2. Don't need to be urgently created, implemented or released.
3. The community, staff or both may or may not be heavily invested in its outcome. There are no segments of the community that are concerned or highly critical of the policy or statement.

These examples are not an exhaustive list of what the PR Team will or will not handle. In every situation, discretion should be used by members of the team when deciding whether they should become involved.

Structure & Reasoning

The structure of the Public Relations Team would be nearly identical to that of existing staff teams. It would fall under Community Outreach, with Sub Team Captains leading the team and a group of staff members making up the bulk of its membership.

The Team will often be handling time sensitive situations, or multiple situations simultaneously. A singular captain could find themselves quickly overwhelmed, leading to a constant stream of new captains which would make it difficult for the team to operate effectively. There is also the risk of a lone captain being unavailable at a critical time due to other commitments, leaving the team without leadership when they need it the most. Having multiple captains helps to prevent these issue from occurring.

Discussion will go on for one week.

Currently, the Bright Works Project Team are attempting to fully complete Ring 2, which involves examining the contributions Bright made to the works of other authors.

What’s the Problem?
The remaining works within Ring 2 are largely multi-contributor works. This means that multiple authors have helped write the work, often building off of each other’s contributions. This puts the team in a difficult position, as Bright’s contributions are often responded to, or referenced by, other authors.As a result of this, removing or rewriting Bright’s contributions is difficult because if their contributions are removed, the works are left in an uncertain state. They would rely on Bright’s now missing contributions, making them feel incomplete to readers, and still leaving Bright’s influence partially intact.

How can this be Rectified?
In order to fully remove Bright’s influence, and to ensure all works still left within Ring 2 remain complete and true to the author’s vision, the Bright Works Project team want the ability to make small changes to the contributions of non-Bright authors.

Policy Specifics
This policy would allow the Bright Works Project team to make minor changes to works within Ring 2 to the contributions of non-Bright authors. This would allow them to:
- Remove or rewrite mentions of Bright by others characters.
- Remove or rewrite elements related to Bright such as 963.

Importantly, these removals or rewrites must only take place when deemed absolutely essential. Further, they should only extend as far as necessary to ensure that the work is not left in the worst state after the removal or rewriting of Bright’s contributions.

Any works that the Bright Work Project team believe need to be changed under this policy must follow the these steps:

1. The proposed changes are to be drafted and sent to the author(s) of the work. This message should be also contain details about why these changes are being made and that the author(s) has a right to request the changes not be made, or to fully or partially revert them.
2. The author(s) will be given 2 weeks to respond. If they don’t respond within that time frame, the Bright Works Project team can move forward with implementation of the proposed changes.
3. The proposed changes will be presented to at least one member of the admin team.
4. Once approved by the admin team, the changes will be implemented. A note about the changes will be left in the work’s discussion per Ring 2 guidelines.

It’s important to stress that this policy is not a license for the Bright Works Project team to make wide sweeping changes to the contributions of non-Bright authors, nor should the team make any changes that go against the author’s intent.

Example
Here is an example taken from a work currently under Ring 2. It showcases how this policy, if passed, would allow the Bright Works Project to effectively remove Bright’s contributions while the works are minimally affected and authorial intent maintained.

Before Bright’s Contribution is Rewritten

After Bright’s Contribution is Rewritten Under the Current Fiat

How Bright’s Contribution Would be Rewritten Under this Policy

Discussion will go on for a week.

Overview

This is a proposal to introduce a visible component/on-screen widget that denotes an article is available for rewrite.

Aim and Scope

The goal of this component is to increase the awareness of rewriteable articles. Our current system of denoting this is using the rewriteable tag. While this does work, it can sometimes be overlooked by people who do not check tags, leading to someone only noticing an article is available for rewrite when they are already browsing the rewriteable tag.

This component has been pre-approved by head of rewrite Uncle Nicolini

The Component

When logged out, the component does not appear. With some user feedback I decided that the concept of an article being available for rewrite is irrelevant to anyone who isn't a member of the wiki, so hiding the notice from them will avoid uninterested/offsite readers from being put off by the notice.

Link to source: https://scp-sandbox-3.wikidot.com/component:rewrite
Link to example page: https://scp-sandbox-3.wikidot.com/wackdog1

Usage

The component will be a staff-only component and will be added to the top of articles manually by the rewrite team when they tag articles with "rewriteable". For retroactive application I am happy to personally go back and add the component to any articles currently open for rewrite.

Discussion will run for 7 days:

Overview

This is a proposal to introduce a new Advanced Random Search feature to the wiki and replace the current "random" section on the sidebar.

Optimised Page Randomiser

This will utilise an optimised page randomiser created by Danjon56. Using a live embed on its own page, this generator queries the Crom API to select a random page with a corresponding format tag ("scp", "tale", "goi-format", and "artwork", respectively). This solves the known issue of the /random: pages onsite not updating for several minutes. It also provides additional information for the user, such as the author, title, rating, and tags. This allows users to better select pages that align with their tastes.

Feature list:

• Sandwich menu in top right: Custom Random Search [Page type (any, scp, tale, goi, artwork), Author, Tags, Include/Exclude Sensitive Content (_adult)]
• "Quick Select" buttons (red ones in middle of screen): What it says on the tin
• Click tags in result to search random (previous query) with tag (tag selected)
• Full result preview: page type at top, followed by title (hyperlink to page), rating, authors, tags (see above), alternative titles
• Rate limit to avoid scraping and overuse of the Crom API
• Localized into French (?lang=fr), Polish (pl), Vietnamese (vn), English (en)

Proof-of-Concept:

Wikidot Page with Embed/Live example: https://scp-sandbox-3.wikidot.com/danjon56-better-randomizer

Backend Links:

Randomizer Page: https://scpwiki.github.io/wikidot-better-randomizer/?lang=en
Repository: https://github.com/scpwiki/wikidot-better-randomizer

Side Bar

With the implementation of the Randomiser page, we can remove the old random buttons from the side bar.

Proposed changes:

• Remove random category
  • Remove random SCP button
  • Remove random Tale button
  • Remove random GOI button
  • Remove random Art button
  • Remove Random Page button

• Add a link to the randomiser page in the Discovery category as seen below:

This discussion will run for 7 days:

Overview

It’s been 20 years since you joined the foundation. There are 300 slots left until the database has 10,000 total entries. Just as you’re navigating back to home to check on the countdown timer, you see something that wasn’t there before.

A link in the sidebar of the database flashes at you.

“Lost SCP Files Found.”

You click it, and before you know it, you’re looking at a whole new series of database entries with a strange new name.

You have just discovered The Lost SCP Series.

This is a proposal to introduce a new type of companion mainlist article to the standard series of SCP articles which we have been writing and curating for almost 19 years now.

What Is This?

The Lost Series will be a limited and unique affair, beginning with a thousand slots ranging from 000 to 999. There may be potential for future slots beyond that but nothing is guaranteed in the cracks between database certainty.

Thematics

The Lost SCP Series will be thematically introduced to the site as SCP database entries which have been “lost.” Entries which have vanished from the mainlist, slipped between the cracks of the digital and analog archives, fallen between filing cabinets, corrupted, degraded, or destroyed.

Experiment, find ways to tell stories through the medium in strange and unexpected ways. Take inspiration from formats that have been lost to the endless march of time, or come up with new approaches never before seen by the wiki. There are no restrictions on article themes or styles. There is only boundless potential, and the power you have in your hands to turn that potential into reality.

Why do we need this?

The reality is that Series X currently has a little more than 350 articles left open for filling. Due to the intensive nature of K-cons and the burden they place on staff, contests, discord staff, and critique staff and the current event schedule this year, holding a 10k within the next 3 months would be untenable for staff to manage especially with the rapid increase in posting rate.

Additionally, staff need time and space to address the shift in the way the authorbase and readers are engaging with the site. The reality is that, our critique systems are overwhelmed, posting rates are at an all time high, and reader burnout and overall readership is worse than it has ever been. Staff need time and energy to implement a dramatic shift in policy to address changes to the way the userbase engages with posting, quality standards, elevation of and learning of critique skills, and encouraging long term retention of readers and integration of new and old authors into official community spaces where teaching can occur.

It would be disingenuous to say the Lost Series isn’t a stopgap, because it is. It is designed to buy staff and the userbase time to organize the next K-con and make it incredibly special and ensure we don’t run headlong into endless acceleration.

But that doesn’t mean we just have to rest on our laurels and make it just another thousand slots to fill. This is where the unique and limited nature of these slots, their unique thematic elements, and storytelling opportunities will come into play.

And if this sort of ‘side series’ is succesful, then I can forsee us returning to side-series like this in the future. Who knows, maybe even a second Lost Series at the next major milestone K-con.

What are the terms and conditions

Naming Scheme

In terms of how these slots will be named there are several options.

Option 1A:

Each slot is formatted as SCPL-XXX.

Option 1B:

Each slot is formatted as SCP-L-XXX.

Option 1C:

Each slot is formatted as SCP-LXXX.

Option 1D:

Each slot is formatted as SCP-XXX-L. This option has the potential to cause confusion in the userbase setting the expectation that like -EX's or -J's, anyone can make a -L article out of range. This is not the intent of this proposal, as the Lost Series are all mainlist articles and the rules regarding out of range posts will apply.

Option 1E:

Each slot is formatted as SCP-0000 on the series hub page. The URLs would be lost-series-000 through lost-series-999.

Option 1F:

Each slot is formatted as SCP-0XXX. This approach may cause some confusion, and there are already some existing SCP-0XXX articles that are currently tales.

Option 1G:

Each slot is formatted as SCP-X###.

Option 1H:

Each slot is formatted with a three letter combination where the first letter is either A or B. This would give us an uneven 1352 slots.

Option 1K:

Each slot is formatted in some other way. Please offer suggestions below and we might reach a consensus there.

Slot Mobility

Due to the limited nature of the Lost Series, slot trading would not be allowed. Once you post in The Lost Series, you cannot move your article out of it. It is in the liminal spaces of the database, stuck and cannot be returned to the mainlist.

Opening

In terms of opening The Lost Series we would have three distinct options.

Option 2A: We open the slots as soon as Series X is filled up. This will give staff 3-4 months to iron out specifics, draft a hub, make a front-page banner, draft social media posts, and prepare advertising.

Option 2B: We open the slots for posting as soon as a staff vote has concluded. This will give staff a much shorter time to iron out specifics and prepare materials, but it will also stop people from pre-drafting lots of Lost Series Entries.

Option 2C: We open the slots for posting following Pridefest. When I originally wrote the proposal, I hadn't quite clocked how close the timing would be to Pridefest, which I hadn't forgotten about. My sense of time is just terrible. This would give staff a month to produce all the needed materials and time to iron out more specifics that aren't necessarily covered in the initial proposal.

Series Page

There are several options we can take when it comes to the actual Series Page.

Option 3A: A standard series page with no additional immersive elements.

Option 3B: A series page resembling the other Series, but with immersive in-universe text indicating the lost/recovered nature of the database entries.

Option 3C: A unique series page with its own CSS theme, styling, and slot formatting for each hyperlink reflecting the unique nature of these lost files and the glitchiness of the archive attempting to present them to the reader.

001 slot

Option 4A:

The Lost Series 001 slot will link directly to the SCP-001 slot.

Option 4B:

The Lost Series 001 slot will be a standard article within the series and have no special properties.

Option 4C:

The Lost Series 001 slot will become a proposal slot representing 001 proposals which were rejected or lost. It's often implied in works that proposals are put forward, but a good chunk are declined and never see the light of day. This could be a nice worldbuilding opportunity for the community to figure out what these proposals might look like. (Credit to White boy for this idea).

Navigation

The Lost SCP Series will receive its own link on the side bar formatted to indicate its status as a unique part of the mainlist.

Tagging

Lost SCP Series entries will be tagged as SCPs with all the attributes that come with that, and also a unique series-specific tag.

This discussion is open to all Staff and will last for a period of one week.

Overview

This is a proposal to introduce a secondary curation standard for mainlist SCP articles.

Why is this an issue?

There have been ongoing discussions about the increasing rate at which mainlist SCP articles are being posted. This rate has grown significantly over time and has been further accelerated in the latest series by community contests that encourage high-volume posting.

One of the clearest trends in the more recent mainlist series is the growing concentration of articles in the low-range rather than at the high end. In other words, recent slot growth is being driven less by articles with especially strong long-term reception and more by a large cluster of entries that settle around the +10-20 range. That does not mean those articles are without merit, but it does suggest that the mainlist is becoming increasingly crowded by middling-performing works, which strengthens the case for a secondary curation standard if the goal is to preserve slots and maintain a higher average standard of retention. This data can be seen below:

This creates pressure on one of the wiki’s most popular recurring events: KCons. If slots continue to fill at the current increasing pace, we may reach a point where there is less than a year between each KCon. This would likely be unsustainable for the contest team, who need time to plan and organize these events, as well as for the wider community and participating authors, who may experience burnout.

There is also a risk that 10KCon may need to be moved forward from its originally intended date. With only around 400 slots remaining in the current series, this could negatively affect the planning, reception, and turnout of what is likely to be one of the site’s largest milestones. While there are solutions in the works that might give us the wiggle room for 10kcon, we will still only be delaying a larger issue rather than resolving it.

Solution

To address this, I am proposing a secondary threshold for mainlist articles after they have been posted for one year.

All options below will utilise full automation by the tech team to pick out articles that fall under the threshold automatically.

Each option has two sub-options:

• Unlisting Instead: Unlist the articles instead of deleting them.
• Unlist then Delete: Unlisting the article for an extra brief period (perhaps one month) after the initial one year period for any potential rewrites, and then deleting them after a short period.

Option A: Under +20 After One Year

Mainlist articles would be expected to reach +20 within one year of posting.

After discussing with community members, I believe this is a realistic and achievable benchmark for new articles and new authors alike.

Articles that fall below +20 after the one year would still prompt the deletions timer.

With information from data analysis, this method would free up 333 slots immediately.¹

Option A2: Option A with unlisting instead of deletion.

Option A3: Option A but with a short unlisting period prior to deletion.

Option B: Under +10 After One Year

This option would function the same way as Option A, but with a more lenient threshold.

Mainlist articles would be expected to reach at least +10 within one year of posting.

Articles that fall below +10 after the one year would still prompt the deletions timer.

With information from data analysis, this method would free up 71 slots immediately.

Option B2: Option B with unlisting instead of deletion.

Option B3: Option B but with a short unlisting period prior to deletion.

Benefits/Concerns

Implementing one of these options would immediately free up a large number of mainlist slots, reducing the pressure on currently planned events. It would also provide a more sustainable long-term framework for curating the mainlist, preserving slots for higher quality content, and reducing pressure on both the contest team and participating authors.

First Discussion will run for 7 days²:

Given some recent revelations regarding the speed at which we're filling up the current available series, I think we need to have a formal discussion with how to handle the availability of open slots prior to the start of the 10kcon, which is not scheduled until summer of next year.

There's roughly 400 slots in Series 10, with roughly 50 in Series 9. Over half of the available slots have been filled since 9K in October, meaining we are certainly going to run out of space long before the contest team is prepared to begin 10k.

Of course, we could always force through an early 10kcon, but that would be an undue burden on contest staff and seriously throw a spanner in the works with regards to current event scheduling. The team, I imagine, is beleagured as it is, and I think this would not be an ideal solution.

I would like to propose what I feel is a simple fix: allowing for SCPs to be posted outside the standard range, using the title in place of the URL, and creating a tag to denote these until such time as 10k concludes, contest winners given their chosen slots, and the new series opens.

I'd like to discuss the feasibility/acceptability of this as an option. Purely mechanical, it does not upset or reconfigure site operations or standards beyond a temporary url change. 10K opens, the winner and runner ups are allowed their chosen slots, then Outside-Range scps can be moved into mainlist urls.

It should be on the author to move their own work once 10k opens to the public, but barring that, a new tag "outside-range' could be applied to these for ease of finding. Once a certain time period has passed, staff can move these SCPs if the author is absent.

To give a concrete example, once slots are filled, an author would post their SCP, "The Murder Hat" thusly:

https://scp-wiki.wikidot.com/scp-murder-hat

Within the confines of the file, it is up to the author to determine how they'll refer to their subject¹, but functionally, they'd occupy a url outside the mainlist in the same way tales do. Beyond changing to actual numbers post 10kcon, there's no additonal work needed. (Well, a listpage could be made for readers to browse these works, perhaps ordered alphabetically, but that's it.)

Do note this is not an open discussion of site standards. It is not a discussion regarding deletions caps. It is not a discussion for the removal of any works. Please stay on-topic.

This is the second discussion for this proposal. The first discussion generated a lot of feedback in the last 24 hours or so, so I took some time to make the suggested revisions. In particular, we'll be retaining deletion timers for score-based deletions.

Motivation

Over the years, I've noticed a few pain points and headaches with respect to deletions. I've attempted to remedy those with new versions of the mainsite and 05 Deletions Guides, which include some policy and procedure changes.

Proposed new guides and policies

Mainsite Deletions Guide draft
05 Deletions Guide draft

Current guides, for reference

Mainsite Deletions Guide
05 Deletions Guide

Notable changes

• JS may witness deletions with the prior approval of the Captain of the MAST Deletions subteam. This enlarges the pool of available witnesses while also allowing JS to gain experience with the deletions process.
• Explicitly allow deletion for any page that a user was not allowed to create in the first place. This replaces the rather nebulous "gaming site procedures" reason and allows for more specificity. (E.g. "witnessing for deletion as a page created by a user evading their ban.")
• The concept of summary deletion has been removed. Deletions are deletions; there are slightly different procedures depending on deletion reason, but the division of deletions into regular and summary added unnecessary complexity.
  • Related to the above, any page eligible for deletion for any reason will be tagged in-deletion. This replaces the prior system where pages eligible for deletion due to score were tagged deletion-range but no tag was available for pages eligible for deletion for any other reason.
• Streamline AI/trolling deletions by counting votes to ban a user for a page's content as votes to delete those pages. The underlying thought here is that if a member of staff says that a page is AI-generated for purposes of determining whether its author should be banned, they shouldn't then need to say it again for purposes of determining whether the page should be deleted.
• Users are encouraged to delete their own failing articles.
• Greater clarity for procedures around score-based deletions.

Please don't hesitate to make suggestions related to both the policies being introduced and the wording of the guides.

Discussion will continue for one week.

Change log

• Added limits on ex post facto application of the "user is not allowed to post" deletion reason
• Explicitly list cases where deletions timers are used

Put simply, in its current state, the sandbox site sucks. It appears to be designed less for usability and more to prevent headaches for staff. This is not fair to Wiki members that use or want to use our official sandbox site. As such, I am proposing some changes that I believe would make our sandbox usable. Suggestions, thoughts, and/or concerns are welcome.

For the current sandbox site: https://scp-sandbox-3.wikidot.com/
For a mockup of what this would look like: https://sandbox3mockup.wikidot.com/

Top Bar

Currently, the top bar has a link to the SCP wiki front page and the sandbox front page.

I think we should use the top bar as a place to put quick links to resources rather than using it for two links, both of which can be found in other places.

Proposed changes:

• Remove the link to the front page of the sandbox site
  • We already have this in the sidebar.
• Rephrase "SCP Foundation Main Page" to "SCP Wiki"
  • "SCP Foundation Main Page" is too long on the topbar and looks ugly.
• Add a topbar category for "Writing Resources" or something of the like (rephrase, maybe).
  • Under the category, add links to:
  • Guide for newcomers (Phrase as "Basic Guides")
    • The title "Guide for Newcomers" may turn people away from reading it, so it might be good to phrase it as "Basic Guides."
  • How to write an SCP
  • Guide hub (Phrase as "Other Guides")
  • Essays and Resources
• Add a topbar category for "Style Resources" (or something of the like).
  • Wiki Syntax
  • Style Resource
  • Components Hub
  • Every Single Theme
  • Sigma-10 Themes
  • Black Highlighter Themes
• Add a topbar category for "Critique Resources" (or something of the like).
  • About Critique
    • Guide for Writing's critique section.
  • SCP Wiki Discord server
  • IRC chat
  • Idea Critique Forum
  • Draft Critique Forum

Edit: removed links to idea forum info and draft forum info to reduce clutter as per suggestion.

Side Bar

The top bit of the sidebar has the SCP social media links, which I have no qualms with. The main block of the sidebar has a link to the front page; a wall of text about crit that ultimately links to the greenlighting policy, the idea critique forum, the Discord, the IRC chat guide, and the draft critique forum; a link to join the sandbox site and a chunk of text on sandbox page authorship, accompanied by a link to the sandbox collab page section of Zyn's co-authoring typs; and a link to the SCP Wiki front page, How to Write an SCP, and the Guide Hub. It also has the Admin panel, which I have no qualms about.

Changes to the sidebar here would focus on usability and appearance.

Proposed changes:

• Add a page creation box to either the top of the main sidebar section or as a section above the main sidebar section.
  • This is perhaps the most important change out of everything listed here. It greatly increases usability of a sandbox site in my experience.
  • I think the reason it's not there already is related to the reduction of page spam. Originally, users were only allowed one sandbox page. We have since moved past that time, and while page spam is frustrating, I think that we should aim for usability. The benefits to users will almost certainly outweigh the cost to staff.
    • We are in the process of reworking Sandbox team's operational procedures, and once we are done with this, page spam will mainly be a non-issue.
• SCP Sandbox section
  • Move above the "Resources" section so it can be by the page creation box.
  • Remove the "SCP Sandbox" label for aesthetic purposes.
  • Add the main page link here.
  • Keep the "Join the site!" link.
  • Remove (moved) link to the collab page section in Zyn's co-authoring tips.
  • Remove the chunk of text.
• Remove the "Main SCP Wiki" section since this would now be covered in the above "Resources" section.
• In the section titled "Authors' Resources":
  • Rename the section to "Resources" or something.
  • Remove the wall of text.
  • Add some quick links, not as in-depth as the top bar but generally covering the same categories. Keep this relatively short.
    • SCP Wiki
    • How to Write an SCP
    • Guide Hub
    • Wiki Syntax
    • Add link to the collab page section in Zyn's co-authoring tips.
    • About Critique
      • Guide for writing's critique section.

Main Page

The main page was revised sometime within the past few years, and as a result, it is mostly fine.

Proposed changes:

• Remove "so you can have multiple drafts" from the tabs instructions.
  • This is a remnant of the age when users were only allowed one sandbox page.
• Above the instructions for tabs, add instructions for a listpages module that shows the sandbox pages you've created.
  • To help if users lose track of sandbox pages.
• Update "Useful Guides" section
  • Add a bit more info
  • How to Write an SCP
  • Doing the Safety Dance - writing reasonable and interesting containment procedures
  • Technical Writing - For authors, not scientists.
  • What Hides Beneath: the Black and White of Blackboxing - how to use Redaction.
  • Crosslinks Guide - how best to use links to other articles.

Edit: added updates to "Useful Guides" section as per suggestion.

This discussion will run for 7 days.

Motivation

Over the years, I've noticed a few pain points and headaches with respect to deletions. I've attempted to remedy those with new versions of the mainsite and 05 Deletions Guides, which include some policy and procedure changes.

Proposed new guides and policies

Mainsite Deletions Guide draft
05 Deletions Guide draft

Current guides, for reference

Mainsite Deletions Guide
05 Deletions Guide

Notable changes

• No more timers. Deletions due to score will now be carried out more promptly. We've found that timers are counterproductive in that they encourage desperate last-minute attempts to "save" a failing article, leaving authors disappointed when those attempts fail. We want to encourage authors to take the time necessary to receive critique and revise failing articles instead of racing the clock. (They also inconvenience the Deletions Subteam.)
• JS may witness deletions with the prior approval of the Captain of the MAST Deletions subteam. This enlarges the pool of available witnesses while also allowing JS to gain experience with the deletions process.
• Explicitly allow deletion for any page that a user was not allowed to create in the first place. This replaces the rather nebulous "gaming site procedures" reason and allows for more specificity. (E.g. "witnessing for deletion as a page created by a user evading their ban.")
• The concept of summary deletion has been removed. Deletions are deletions; there are slightly different procedures depending on deletion reason, but the division of deletions into regular and summary added unnecessary complexity.
  • Related to the above, any page eligible for deletion for any reason will be tagged in-deletion. This replaces the prior system where pages eligible for deletion due to score were tagged deletion-range but no tag was available for pages eligible for deletion for any other reason.
• Streamline AI/trolling deletions by counting votes to ban a user for a page's content as votes to delete those pages. The underlying thought here is that if a member of staff says that a page is AI-generated for purposes of determining whether its author should be banned, they shouldn't then need to say it again for purposes of determining whether the page should be deleted.
• Users are encouraged to delete their own failing articles.

Please don't hesitate to make suggestions related to both the policies being introduced and the wording of the guides.

Discussion will continue for one week.

Edit: Changed JS witnessing criteria based on feedback.

The Internet Outreach¹ team has over recent months recieved multiple requests from users for us to stop operating the official SCP Wiki Twitter/X Account. These requests cite the increase in hate speech on the platform, an increase in bot accounts, and allowing AI to be used to actively harm others².

For these reasons, and other raised within user requests and reported in the media, IO has decided to begin a review into whether or not we should cease operating the official SCP Wiki Twitter account. To be clear, under no circumstances would the account be fully deleted, but instead the Twitter will cease posting. Our followers on Twitter would then be directed to alternate platforms on which we have a presence such as Instagram and Bluesky.

The review will be in three parts:

1. Allow users and staff to provide feedback on and ask questions about the official Twitter via O4 and O5 threads. These threads will be monitored by the IO team.

2. Begin to better promote the Wiki’s official Bluesky account to inform users of its existence and give them an alternate way to view the off-site communication from the Wiki. These steps will include adding the Bluesky to the Wiki’s sidebar and promoting it on the Wiki’s Twitter and other social media accounts.

3. Once all feedback has been collected and reviewed, make a decision regarding closing the Wiki’s Twitter account.

This thread was created both to inform users and staff of this review and to assess user and staff sentiment around keeping open or shuttering the Wiki's Twitter Account per step 1 of this review.

IO will consider all feedback from the O4 and O5 threads before any further action takes place. Feedback will be gathered over the course of one week and is open to all staff.

What is this?

Following the vote, Remove and Counter Bright's Influence was selected as the plan to resolve the Bright works issue.

While there are many aspects that will not change, there are a number of items with alternative resolutions and potential adjustments that we need to discuss. Those items have been isolated below, into a list of decisions — this thread is to discuss the alternative options, and come to a consensus on how to act.

If there is a consensus in how to handle each issue, we will resolve them at the conclusion of this discussion — otherwise, we will have a week of voting to determine the specifics.

Discussion Points/Issues

Specific Resolutions for Bright's Pages

The Remove and Counter proposal provides suggested resolutions for each page by Bright, but staff has the ability to adjust the resolutions for a given page if we feel that it was improperly placed, or does not need to be retained etc.

The following section is broken down into two broad categories: the deleted and recycled pages, and special resolution pages.

Slot Releasing

The proposal does not specify the specific method of slot release for SCPs or tales marked for Deletion and Recycling — based on previous experience, we suggest the following:

• For any tales, once there is consensus, these pages will be deleted immediately, with the slots left empty.
• For the SCPs, following consensus, these pages will not be deleted immediately — this is to avoid causing further issues, so that harm is minimized. Instead, slots will be released randomly by staff, as was seen with the Kalinin deletion.
  • Victims are able to reach out to the Bright working group and request a slot, such that they may write a replacement piece. We highly encourage those who feel comfortable to reach out. Currently, SCP-590 is earmarked for a replacement piece.
  • All other slots will be released in random intervals, without prior announcement. These page deletions will be witnessed by Wiki Admins — as such, wiki administrators are restricted from posting in these slots.

This methodology will allow for finite control, giving victims the chance to reclaim their voice, while reducing the chance for additional harm.

If you feel as though the slots should be handled differently, please comment as such below.

Response Pieces

There are a number of items to discuss regarding response pieces, primarily if we feel as though they are needed. Currently, the list of pages opened to response pieces consists of all special resolution pages excluding SCP-902 and the SCP-2000 Contest Hub, totaling 7 pages.

Additionally, for response pieces, we need to determine as staff if we (A) allow response pieces to be added by any wiki member, with problematic or incorrectly added pages removed by staff, or (B) require that all response pages are reviewed and approved by staff, who add them to each page.

Option A allows for further authorial autonomy, and empowers the community to respond without staff intervention, while potentially resulting in improperly added pages or trolling. Option A is similar to the current process regulating collab logs on the wiki.

Option B requires that staff be involved in this process, and would place the onus on a set group of individuals to determine if a work is a 'valid' response piece. This restricts community responses to what staff approves, which is not inherently problematic, but could be an issue down the road.

The team suggests that Option A is chosen for the 7 pages. Should a given page be subject to repeat vandalism, or should the process pose further complications, we are always able to implement Option B.

Regardless of how the responses are curated, pieces will only be added as responses by the request of the original author.

If you believe that the response pages should be maintained via Option B, or have any other issues regarding the response pieces, please comment as such below.

List of Issues:

For convenience, below is a list of each potential item of discussion, each of which is included in further detail above.

1. Should any of the deleted and recycled pages be handled differently? If there are no objections, the current list will remain.
2. Should any of the special resolution pages be handled differently? If there are no objections, these pages will be handled via their currently outlined resolution.
3. Should we release the slots in a different manner? If there are no objections, the slots will be released randomly, as seen with the Kalinin deletion.
4. Should response pieces be curated after posting, or approved in advance? If there are no objections, the current plan is that pages will be opened in full to response pieces, with staff maintaining them.

This discussion will run for one week. If there are no objections to the planned solutions listed above, then at the conclusion of the week, we will consider those items to have consensus, and they will be resolved as written. If there is not consensus, voting will begin.

What is this?

This is a discussion thread serving as the culmination of the Bright Works Project. The aim of this thread is to finalize staff's approach in handling Bright's remaining works. Several proposals are presented.

The process of creating each of these proposals has been very thorough, with the goal of providing an exact model for handling comparable situations in the future. As a result, the proposals cover a wide range of options, not all of which are ideal solutions. This was done to show for future reference that staff thoroughly considered all relevant options, and allowing these proposals to be applied to any similar issues without the need to repeat discussion

Why is this an issue?

In short, a former administrator and long-time author on the SCP Wiki (who will be referred to as "Bright" throughout) received an AHT ban in 2022 for the following:

For further details, please see the Bright List Deletion Message.

Bright's conduct was enabled by their position as a high-ranking member of staff and the relative popularity of their works. Since their AHT ban, many of Bright's works — all of which are harmful — have remained on the site. The Bright Works Project was started to provide a final, permanent resolution to this issue with a primary goal of harm reduction. This has been long-delayed — to an unacceptable degree — but it is now ready to be finished so that we can put this matter to rest once and for all.

Solution(s):

Now that the proposals have been fully prepared, they are ready for discussion and then voting. To begin, there will be a week of discussion on 05command for staff and a mainsite mirror open for discussion by SCP Wiki site members. On the final day of discussion, we will post a comment asking staff to reply if they feel that a second week of discussion is necessary; if there is sufficient consensus for additional discussion, then we will hold another week of discussion. This process will continue until no further discussion is needed.¹

Additionally, simultaneous with this discussion being launched, there is a 3-day vote on provisional content blanking. This permits staff to authorize certain Bright articles for being blanked / hidden from public view until the discussion and voting on these proposals has been finalized.

Once discussions have finished, we will move on to ranked choice voting between the 5 proposals. This will be a semi-standard O5 vote (meaning that only staff cast votes), to determine which of the five proposals we are choosing. However, due to the nature of the topic, voting is opened to all staff, including Junior Staff. After a week, if a vote passes with a majority, then that plan is chosen. If there is a lack of consensus on the specifics of the chosen proposal, a secondary vote — also running for a week — will be held to decide the contested specifics of the proposal.

Once the voting period is finished, the chosen proposal will be implemented in accordance with the timelines outlined in the proposals themselves.

By the end of the timeline, we will have handled the current phase of the Bright Works project, and dealt with the most important issue (works authored by Bright). After this, the Bright Works project will continue to address the remaining harm and impact left by Bright, next addressing Bright's contributions and edits to other pages on the SCP Wiki, where the goal will be removal. Following that, we will be contacting individual authors and series runners, asking them to adjust their content, if needed.

We will continue to do everything that we can to address the failings of the past, and to prioritize the reduction of harm as much as possible — our hope is that we will finally be able to resolve this long-standing problem as soon as possible.

The Proposals:

Remove and Counter Bright's Influence

• This proposal recommends the deletion of the vast majority of Bright's works, while paying special attention to the handful of remaining works which need particular handling due to the potential for future harm caused by their prominence. This proposal focuses on allowing the community to recontextualize Bright's narrative on the SCP Wiki, counteracting and replacing Bright's influence.
• » Draft here «

Near-Total Removal

• This proposal focuses on the removal of almost every aspect of the works Bright created on the wiki. Specifically, this proposal would remove all of their pages, with the most overtly harmful works being left empty, instead redirecting to an updated version of the Bright List deletion note.
• » Draft here «

Single Source of Truth

• This proposal focuses on the reduction of future harm by having a disclaimer added to each work by Bright on the SCP Wiki, explaining the circumstances of their AHT ban to the extent that such is possible, and warning users against pursuing interaction with the author. This disclaimer would be applied to all pages, and their content hidden behind a collapsible.
• » Draft here «

Adapted Deletions Threshold

• This proposal would place all power into the hands of the community at-large to cast their votes on each individual Bright piece by creating new rating modules to set aside the existing upvote totals on Bright works. Pieces that reach the adapted deletion threshold will be removed at the end of a set voting period.
• » Draft here «

Minimal Staff Intervention

• This proposal would remove only the most overtly harmful works from the wiki.
• » Draft here «

This discussion will run for one week, after which voting will begin.

Edited to add a link to AHT, with permission from Queerious.

What is This:

An update to the current rules on what you can and cannot name yourself as a user of the wiki.

Why?

We have lately witnessed several instances of users applying to join the wiki with names that some members of moderation find objectionable. We want to make these rules more clear. Specifically, we have seen users apply to the site with self-deprecating or self-demeaning usernames. We are concerned that these usernames will not allow users to participate on the site without incident, or that they will make Rule 0 violations a murkier area in a way that we would prefer to avoid. For instance, someone with the username "the worst writer" would only be able to be referred to with that insulting title, and Disciplinary wishes to avoid having to litigate a potential Rule 0 violation that would stem from comments that the username is accurate.

Solution

Following is the current (as of 24/1/2026) rules on usernames for the wiki:

Username Policy

The SCP Wiki maintains a policy that dictates what constitutes usernames that are permissible for membership. The policy is as follows:

• No names with profanity, slurs, offensive content or connotations. The final decision on what constitutes offensive content is made at the discretion of Site Staff.
• No names implying official staff positions. (e.g. Staff, Operational Staff, Moderator, Admin, Administrator, etc.)
• No names implying specific, unique positions/affiliations in the Foundation or other fictional groups on our website. In addition, no names that are based on pre-established Foundation characters, from works found on the wiki.
  • For example, names containing SCP, Director, D-XXXX, O5-Queen, MTF Captain XXXX or named characters like Clef, Gears, or Kondraki would not be permissible. For a summary of existing characters or entities, please refer to the character tab of the Tech Hub Tag List. (Note: Authors who are responsible for the creation of said tagged characters are exempt.)
• No names that impersonate or reference notable public figures. For example, "DrJoeBiden" is not allowed while "DrJoe" is.

The username policy is enforceable both for prospective members, and existing SCP Wiki members; enforcement for existing members is implemented on a case-by-case basis, at such a time when an existing user with a non-permissible username posts a page, or comments on a discussion thread.

Following is the proposed changes to the rules, with proposed additions in blue.

Username Policy

The SCP Wiki maintains a policy that dictates what constitutes usernames that are permissible for membership. The policy is as follows:

• No names with profanity, slurs, offensive content or connotations. The final decision on what constitutes offensive content is made at the discretion of Site Staff.
• No self-degrading names. (e.g., iamastupididiot, Shitty Writer, dumb_moron, etc.)
• No names implying official staff positions. (e.g. Staff, Operational Staff, Moderator, Admin, Administrator, etc.)
  • Note that this applies to all users, including all current and former SCP Wiki staff. This policy will be enforced retroactively and without regards to staff tenure. The only exception to this rule is The Administrator , due to the fact that it is an approved sockpuppet which served its purpose, and that if Fritz wanted to (re)join staff he couldn't use it for staff work.
• No names implying specific, unique positions/affiliations in the Foundation or other fictional groups on our website. In addition, no names that are based on pre-established Foundation characters, from works found on the wiki.
  • For example, names containing SCP, Director, D-XXXX, O5-Queen, MTF Captain XXXX or named characters like Clef, Gears, or Kondraki would not be permissible. For a summary of existing characters or entities, please refer to the character tab of the Tech Hub Tag List. (Note: This does not apply to characters which are named after an established user, for that user).
  • Usernames that reference fictional characters not associated with the SCP universe are allowed, so long as you do not intend to roleplay as that character (see our rule against roleplaying).
  • To clarify: you may name yourself things such as Agent Anders, Lieutenant Columbo, God King Skovald, etc., but you may NOT name yourself things such as MTF Alpha-9 Member, DrGearsFan, or SCP-173Enjoyer.
• No names that impersonate or reference notable modern public figures. For example, "DrJoeBiden" is not allowed while "DrJoe" is.
  • Keep in mind that this rule extends to notable community members. For example, you may not name yourself Doctor Gears and have the same profile picture as Dr Gears You may, however, name yourself Dr Clockwork and have a picture of a random scientist as your profile picture.
• If you are unsure of whether or not your username would be in violation of any of our rules, please ask us before making your account on our official Discord or IRC.

The username policy is enforceable both for prospective members, and existing SCP Wiki members; enforcement for existing members is implemented on a case-by-case basis, at such a time when an existing user with a non-permissible username posts a page, or comments on a discussion thread.

Benefits/Concerns

This will help reduce general confusion by new members when asked to rename themselves, and will allow staff to have a concrete body of rules to point to when faced with pushback.

Discussion will go on for one week (7 days).

What is This:

An update to the current accessibility guidelines on the Wiki.

Why is this an issue?

The current accessibility outline is tucked into the CSS policy, and is quite undetailed. This has led to inconsistent enforcement and application. Many existing themes have a large variety of accessibility issues.

Solution

To address this issue, I have created a new policy/guide, to clearly outline accessibility requirements for the site. The guide also has explanations on each specific policy, and information on how to apply them in their components, themes and general pages.

The draft of this new policy can be found here: https://scp-sandbox-3.wikidot.com/accessibility

There will also be an audit of all existing site themes and components to bring them up to this standard.

Benefits/Concerns

This will help make the site and its content available to everyone, regardless of their accessibility requirements. It will also strengthen the approvals process for themes and components.

A concern that has been raised is that certain accessibility requirements would impede on artistic intent and style choices. To help address this we are allowing "accessibility mode" versions of individual pages using an offset as a method of meeting policy guidelines.

Discussion will run for 7 days:

Ultimately, it doesn't change how the wiki operates all too much, so all bikeshedding are welcome.

SCP Series on the Side Bar

As of writing, there are the ten extant series are laid out sequentially at the top. When Series 11 rolls around, there's a few options to consider:

A. Change nothing, just add a new line with Series XI

To be quite honest, this option is lame and doesn't consider future potential for link bloat, rather,, it just kicks that can down the road.

B. Put Series 1-10 in a collapsible, call it Era/Epoch/Collection 1

C. Link only 10 series at a time, shift them to the SCP Hub

SCP Hub will be retrofitted (and possibly the individual hubs) to have a link tree to all the Series.

D. Other

1. Reverse the series order, newest first

2. Change Roman numerals to normal numbers

This was fine when there was only a few series, but not sustainable, I feel.

3. Groupings of 10 Series

I still think regardless of layout, we should still call it some names. Suggestions wecome.

The discussion will last for 14 days.

Mainsite Mirror: https://scp-wiki.wikidot.com/forum/t-17494127/

Mockup A: https://scp-wiki.wikidot.com/workbench:estrellayoshte
Mockup B: https://scp-wiki.wikidot.com/taylor-s-workbench

Changes

• Updated visuals to reduce header weight.
• Turn each block into an clickable tile.
• Remove username links, as they didn't seem to be very useful, and created syntactic hiccups.
• Simplified art block, and added sliding animation.
• Moved footer links into the dropdown.
• Removed "In the event Flights are not available due to scheduling or other issues, staff will select Features for that month.", as it wasn't pertinent upfront information.

The discussion will last for 7 days, after which changes will be implemented unless serious concerns are raised. In the event of negative or split opinions on a proposed item, it will not be implemented.

Mainsite Mirror: https://scp-wiki.wikidot.com/forum/t-17437649

Purpose:

In October 2025, syuzhet, a staff member, was found guilty of being in violation of the Donations Policy after bribing another staff member to abuse their power as a moderator of the SCP Foundation Official Discord Server (19cord). In the days and weeks following this incident, a number of mistakes were made by the Disciplinary Team and staff at large in their collective handing of the incident, leading to unintended consequences for multiple individuals involved, but primarily for syuzhet herself. This thread serves as a space to discuss the lapses in judgement which led to this, and to discuss measures which can be taken to avoid similar incidents in the future.

Timeline:

The Inciting Incident

On October 6, following the initial offense, syuzhet was reprimanded by her captain. In the days after, she would continue to joke about the situation, unaware that it carried any weight or punishment greater than had already been dealt.

Disciplinary Proceedings

On October 20, members of the Disciplinary Team determined that the case warranted further action and began proceedings against syuzhet. After some deliberation, it was determined that syuzhet's staff powers would be revoked. The team was then informed that in order to revoke a staff member's powers, a Disciplinary Review would need to be held on a forum available to all operational staff and administrators. However, many of syuzhet's permissions and powers had already been pre-emptively removed, so for the purposes of the review, it was said that her powers were being "held in abeyance".

Disciplinary Review

On October 22, the Disciplinary Review thread was posted on 05command. Shortly after, syuzhet's employer informed her that they had received notice of her disciplinary action - however, she was informed by her employer that she was not in trouble, and as of the writing of this thread has not received further consequences therein. Upon realizing their mistake, the user responsible for informing syuzhet's employer confessed, and the situation was sufficiently handled by the Anti-Harassment Staff Team.

Certain community and staff members (including syuzhet herself) objected to the presentation of the Disciplinary Review, believing that it characterized her actions as more malicious than they actually were or left out key mitigating factors. Various edits had already been made to the Disciplinary Review thread prior to posting for this reason, and various edits would continue to be made at later dates, but they had evidently been insufficient to address all possible concerns.

Private Harassment

On October 25, syuzhet received a pseudonymous private message from an individual claiming to be a longtime 19cord user, harassing her for her supposed behavior and misconstruing the nature of the offense so as to paint her behavior as malicious and self-interested. One member of the Disciplinary Team would also receive a PM from the same user when they made a comment on the Disciplinary Review pointing out the thread's poor construction, in which the user objected to their claim as such and argued that syuzhet was "being held accountable for being a corrupt and ableist person".

Discussion:

This incident has spiraled out into a situation which is unacceptable in its impact on all users involved. Its handling by the Disciplinary Team has left much to be desired, and is something to be prevented from reoccurring in the future. In order to do so, we must discuss the issue in two parts. First, it should be addressed exactly how this situation was handled poorly while it unfolded. Any faults in the process which was followed should be laid bare, and if any crucial events or details were missed in the timeline as listed above, they should be pointed out. Second, potential solutions and methods of preventing similar incidents from occurring should be suggested where possible. After we have found the problems, we need to find ways to fix them. This thread should NOT be used as a space to discuss the nature or punishment of the offense in question, only the mismanagement of its handling and prevention of further mismanagement in future cases.

This discussion will be open for seven days and is open to all staff and users.