Meta:Administrators' noticeboard

Grant Local IP Block Exemption

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * ✅ of Bukkit. In this case, DarkMatterMan4500's Spidey sense seems to have been correct. Dmehus (talk) 04:01, 17 February 2022 (UTC)

I averagely access the internet through TOR, as it is a great privacy protector. 29TB (talk) 17:38, 29 January 2022 (UTC)


 * You seem to know about the Local IP Block Exemption, which makes me wonder if you have actually been on this wiki with a prior account, given that your account is 8 days old at the moment. DarkMatterMan4500 (talk) (contribs) 21:24, 29 January 2022 (UTC)
 * Just because I know of that user group, does not mean I have a prior account. I merely looked at the RfCs. 29TB (talk) 22:01, 29 January 2022 (UTC)
 * Not relevant, DMM. --Raidarr (talk) 22:05, 29 January 2022 (UTC)
 * Fair point. I suppose I can just trash my own question as unrelated. DarkMatterMan4500 (talk) (contribs) 22:08, 29 January 2022 (UTC)
 * Per IRC, This is ❌. Blocks of proxies are done to prevent abuse and being allowed to bypass blocks should only be done where this is a legitimate need. I want to use TOR is not valid and Miraheze do not use any third party tracking on site that using TOR would prevent. Any client side tracking can be disabled client side and is unlikely to be helped. If there becomes a legitimate need, this can be re-evaluated. I will note that they are a wide range of reasons that would be acceptable and they can probably be met without a huge barrier. ~ RhinosF1 - (chat)· acc· c -  22:19, 29 January 2022 (UTC)


 * The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section

Community portal in Sidebar
Any system administrator or any other users who have sufficient privileges to edit the MediaWiki namespace? I propose to link the page Community portal to Noticeboards in MediaWiki:Sidebar.

For example, like this:


 * Noticeboards
 * Community noticeboard|Community noticeboard
 * Stewards' noticeboard|Stewards' noticeboard
 * Meta:Administrators' noticeboard|Meta Administrators' noticeboard
 * Meta:Community portal|Meta Community portal

I don't see great despair in putting the link, but because this page is newly created and many users are not aware of it. That said, I think this would help a lot. --YellowFrogger ( talk ) ( ✔ ) 00:36, 8 February 2022 (UTC)


 * For continuity I think it would make sense. At the same time I'd strongly encourage a look at renaming the RfA process to get that out once and for all. --Raidarr (talk) 01:26, 8 February 2022 (UTC)
 * Makes sense and will be useful for quick navigation. --Magogre (talk) 03:00, 8 February 2022 (UTC)
 * This would be quite beneficial for navigation. — Arcversin (talk) 01:19, 9 February 2022 (UTC)
 * I 100% support this action. I mean, it makes sense doing so. DarkMatterMan4500 (talk) (contribs) 02:08, 9 February 2022 (UTC)
 * Well this here a while ago and it looks like 4 unique editors (5 with me) agree with this. Even so, what will be done? --YellowFrogger ( talk ) ( ✔ ) 21:19, 12 February 2022 (UTC)
 * This has been ✅. The concern I have, though, is that the similarly named Community portal may be confusing with community noticeboard and actually increase the workload for Meta patrollers moving threads to the correct community noticeboard, but it's a reasonable request, and, I think, placing it at the bottom of the noticeboard lists should help to minimize this. We can monitor this and course correct accordingly. As an administrative note to a portion of the unaddress preamble to this request, it wouldn't be appropriate for a system administrator to make this edit to the MediaWiki:Sidebar. Administrators' noticeboard is indeed the best venue, and Meta administrators the best functionary to action this request. Dmehus (talk) 18:22, 13 February 2022 (UTC)
 * Thanks. But the only thing that intrigues me is the lowercase "Meta community portal" (C). --YellowFrogger ( talk ) ( ✔ ) 22:12, 13 February 2022 (UTC)
 * That was, in part, intentional and by design. Since Community noticeboard is capitalized, the lowercase "c" in Meta community portal may help to distinguish between the two similarly named portals. As well, grammatically speaking, it is more consistent with the practice of not capitalizing the name of the noticeboard. Dmehus (talk) 22:26, 13 February 2022 (UTC)

Deletion request(s)
Hello. Please delete the following pages:

These are all the unused/abandoned translation units. Thanks. --Magogre (talk) 08:29, 15 February 2022 (UTC)
 * ✅ Reception123 (talk) ( C ) 09:52, 15 February 2022 (UTC)
 * Thank you Reception123. --Magogre (talk) 11:09, 15 February 2022 (UTC)

Block for YellowFrogger
YellowFrogger is currently engaged in an edit war at User talk:Agent Isai. Multiple users have reverted their edits yet they continously reinstate and make more. Agent Isai is within their right to revert per w:WP:OWNTALK but YellowFrogger continuously edits and is well over the three-revert rule. Naleksuh (talk) 01:00, 16 February 2022 (UTC)


 * I have taken emergency action in light of the edit war and YellowFrogger's significantly declined behavior as well as delays in local sysop action. It is likely an unprecedented move and I apologize if it was an overstep. It is either way subject to proper local administrator review. Disruption should be ceased; any sockpuppet action to circumvent the block as retribution will be noted as well as actioned by global lock as abuse of multiple accounts. --Raidarr (talk) 01:06, 16 February 2022 (UTC)
 * If it's not too much, YellowFrogger has been too disruptive beyond any comprehensibility for quite some time now. If yesterday's incident regarding Ninox's similar behavior like voting again with a sock wasn't bad enough, wait until you see the disruption they added to my talk page, which I have reverted the moment it was set there. I am EXTREMELY disappointed in this user's behavior. I would probably ask YellowFrogger to seek some help and take a load off by taking a break from Miraheze for a while until he realizes what he has done wrong, and how he can come to terms of his recent wrongdoings. What I am essentially saying from this reply is for him to do something else for a while, and take a clean start and start all over again (that is, if he could get permission to have a fresh start). I do hope he comes back with maturity and competency. DarkMatterMan4500 (talk) (contribs) 01:22, 16 February 2022 (UTC)
 * User:Raidarr, global sysop actions are not supposed to be indefinite. It is supposed to be for a short time period, during which a local sysop can choose to extend it. Naleksuh (talk) 01:42, 16 February 2022 (UTC)
 * My impression was that this block was meant to be reviewed by a Meta sysop and the block reason would probably be amended either way so I guess this is fine for now but indeed, I would advise Raidarr to perhaps not indefinite block users on other wikis that are not Meta. Agent Isai  Talk to me! 01:48, 16 February 2022 (UTC)
 * The intention is for it to be reviewed and replaced, in which the time period is deliberately unspecified; noted for future cases however, as one of likely multiple advisories given the nature of the action. If it is not addressed when I return tomorrow I can look at a shorter time, perhaps the week duration that was issued on login wiki by Doug. --Raidarr (talk) 01:51, 16 February 2022 (UTC)
 * @Raidarr I have reviewed the block, and I approve of it, and have reblocked showing as such and have denied their unblock request. Zppix (Meta &#124; talk to me) 04:16, 16 February 2022 (UTC)
 * Support an indefinite block. I was surprised that they weren't (b)locked in the first place. Totally unacceptable behaviour. --Magogre (talk) 02:09, 16 February 2022 (UTC)
 * First off, don't use bullet points, this is a request, not a vote or public forum. Second, the user has already been blocked indefinitely but by a global sysop. I personally wouldn't have placed an indefinite block at all but it's outside of the global sysops policy to do so-it would make sense for a meta sysop to either set an expiration date or leave the parameters as is. Naleksuh (talk) 02:12, 16 February 2022 (UTC)
 * I agree with Naleksuh above that bolded bullet points aren't appropriate for requests for assistance from a Meta administrator. The community can advise Meta administrators on courses of action, and, occasionally, in the past, Meta administrators have delegated decision-making to the community on the best outcome for users, but in such cases, the authority to make that delegation to the community rests with Meta administrators and Stewards (depending on the type of conduct and outcome). I have reviewed YellowFrogger's recent conduct with Agent Isai. First of all, Agent Isai should have been clearer in his edit summaries, and ideally provided a warning on why YellowFrogger's edits were being reverted. Indicating "transparency" (one word) in an edit summary is not that helpful to someone whose native language is not English. A better option would've been to message him here, advising him how to properly edit his own comments where replies have already occurred (see also: this English Wikipedia editing guideline on the matter) by striking through his comments and adding his amended comments. Nevertheless, YellowFrogger's continuing to edit war was also highly problematic. Raidarr's action as a Global Sysop seems fine to me, and the appropriate venue to review the action is indeed Administrators' noticeboard. I do think a block on Meta Wiki is needed, but, at the same time, YellowFrogger is currently subject to an indefinite Steward-imposed global user restriction restricting him to creating any alternate accounts he requires logged in and, ideally, on Meta Wiki. Additionally, he is also subject to a Meta administrator-imposed editing restriction limiting him to using only his YellowFrogger account on Meta Wiki. Thus, an indefinite sitewide block would be at cross purposes with the aforementioned user restrictions. I am leaning towards either (a) an indefinite partial block from one or more namespaces (this is where the community's input would be helpful in helping to define the namespaces), with the option to appeal not sooner than three (3) months from the date of imposition or (b) a three (3) month partial block one or more namespaces ( namespace certainly, but likely   and   namespaces as well) Dmehus (talk) 03:43, 17 February 2022 (UTC)
 * I would support (a) where he is blocked on all namespaces indefinitely (but not sitewide blocked which would hinder him from creating user accounts, in accordance with the globally imposed restriction) and can appeal in 3 months. I think YellowFrogger should take some time off Meta to reflect on his actions, cool off, and once he's ready to appeal in 3 or more months, he can come back and will be gladly received by the community. Agent Isai  Talk to me! 05:24, 17 February 2022 (UTC)
 * If the partial block is for all namespaces simply to allow the creation of alt accounts publicly on Meta, that would be fine with me. Reception123 (talk) ( C ) 06:57, 17 February 2022 (UTC)
 * Except that wouldn't work, because a partial block on all namespaces vs. a sitewide block doesn't change anything here. Instead it's in the "block account creation" option. Naleksuh (talk) 07:00, 17 February 2022 (UTC)
 * We could block indefinitely from all namespaces, unchecking the "account creation" box. Though I agree there's not really a significant need for him to create alternate user accounts, this may invite further abuse or breaching of that restriction. I agree that it's best for YellowFrogger to not be able to edit on Meta Wiki, but since Meta Wiki is where wikis are requested, for mainly technical and transparency reasons, and because it's where certain other special page functions occur (i.e., global renames, logging in to Phabricator, modifying OAuth consumers, etc.), there is a need for him to have access to those functions, but no ability to edit on Meta Wiki, indefinitely, with the opportunity to appeal after at least three months. Dmehus (talk) 07:05, 17 February 2022 (UTC)
 * Would it be in consideration to block the bot and alternate account to avoid socking? SoyokoAnis  18:29, 17 February 2022 (UTC)
 * They are not blocked just for being other accounts unless they were created after the block or are being used to evade etc. Otherwise, there is no evidence that the block was necessary to prevent damage. Naleksuh (talk) 18:32, 17 February 2022 (UTC)

Block for Andyyeung7
As seen by their recent contributions I believe this user needs a block imposed on their account due to their disruptive behavior and editing. Hypercane (  talk ) 02:12, 16 February 2022 (UTC)


 * Hypercane, the user seems to have stopped the behaviour. In any case, given that the problems seem to have just been (repeated?) out of scope page creations, what the user needed was a clearer warning, which I've now ✅. Thanks. Dmehus (talk) 03:57, 17 February 2022 (UTC)
 * Ah okay, well that works out too. Thank you Dmehus. Hypercane  (  talk ) 12:07, 17 February 2022 (UTC)

Resignation of rights
Please remove my patroller and translationadmin flags. Thanks. --Magogre (talk) 04:19, 18 February 2022 (UTC)


 * Magogre, as with your similar request at stewards' noticeboard, ✅, with regrets and thanks for your service. I have left you with, as there should be no need to patrol your edits, but this can be removed also, if you request it. Dmehus (talk) 04:28, 18 February 2022 (UTC)

Moderation extension
I've enabled the Moderation extension.


 * Should autopatrolled or autoconfirmed users, or both, be auto-moderated?


 * Who should have the ability to moderate edits? Administrators, or administrators and patrollers? Dmehus (talk) 20:12, 20 February 2022 (UTC)


 * I think autoconfirmed users should be auto-moderated unless sleeper socks begin to spam Meta in which case autopatrolled would be better. As for who should be able to moderate, I think patrollers are trustworthy enough to help moderate edits. Agent Isai  Talk to me! 20:15, 20 February 2022 (UTC)
 * . Please do not add extensions as a Steward on Meta without the consent of a bureaucrat. John (talk) 20:19, 20 February 2022 (UTC)
 * I agree, this should not have been enabled. Both because we do not need a repeat of the report extension business and because stuff like this should have community consensus or at least a Meta crat. Naleksuh (talk) 21:05, 20 February 2022 (UTC)
 * Wow, ESPECIALLY not as this extension makes a very dramatic major change to the way the entire premise of wikis operates. This would need a massive consensus to be enabled, not just enabled by a bureaucrat and definitely not by a non-bureaucrat steward. Naleksuh (talk) 21:06, 20 February 2022 (UTC)
 * We've rate limited IP edits for now and we're working on some less impacting mitigations using what's available to us. ~ RhinosF1 - (chat)· acc· c -  21:07, 20 February 2022 (UTC)
 * More changes from another non-bureaucrat! Naleksuh (talk) 21:08, 20 February 2022 (UTC)
 * That has been far from clear, given the role Meta Wiki plays as the central coordination wiki, and the historical practices in which Meta Wiki has operated. Indeed, we have even had SRE performing ManageWiki changes in the past, though I agree with Agent Isai that an RFC is not necessarily needed. It can be either an RFC, or a community discussion at Administrators' noticeboard or Community portal. Dmehus (talk) 21:17, 20 February 2022 (UTC)
 * Agreed, this is the sort of thing that needs an RfC to be enabled. — Arcversin (talk) 21:08, 20 February 2022 (UTC)
 * Perhaps not a full blown RfC but definitely an AN discussion. Agent Isai  Talk to me! 21:09, 20 February 2022 (UTC)
 * No, definitely an RFC. This extension seeks to change the entire way the wiki operates. Naleksuh (talk) 21:10, 20 February 2022 (UTC)
 * The extension's primary use is generally only for temporary site protection, not permanent protection. Agent Isai  Talk to me! 21:11, 20 February 2022 (UTC)
 * Even if so, there would need to be an RFC to establish the conditions for use, what group skips moderation, what group can moderate, etc. Also, turning on moderation is kinda like giving in to the vandals. — Arcversin (talk) 21:22, 20 February 2022 (UTC)
 * Who remember this?--MrJaroslavik (talk) 21:48, 20 February 2022 (UTC)
 * For the record, a Meta bureaucrat did authorize that extension to be enabled. Subsequent discussions informed the decision to revert the change. I don't see a direct comparison there. Dmehus (talk) 21:50, 20 February 2022 (UTC)
 * For the record... There was not consensus for adding that extension... As like in this case...--MrJaroslavik (talk) 21:53, 20 February 2022 (UTC)
 * Well, no. The discussion you linked to was the subsequent discussion. In the previous discussion, several participants, including myself and Reception123, all agreed with enabling the extension, and the Meta bureaucrat viewed that as either (a) sufficient consensus to enable or (b) non-controversial enough so as to not require a fuller discussion. Subsequent to that, a couple users dissented, so a fuller discussion was had. Southparkfan's close was complicated, but essentially said consensus tended to be trending toward enabling, but was not yet there in terms of some of the logistical items. In any case, the extension was subsequently removed pending a third, fuller discussion, but since then, due to the extension's limited feature set, there's been no desire to re-propose enabling it. Dmehus (talk) 22:04, 20 February 2022 (UTC)
 * Lol, I see no change in your behavior has occurred... In that discussion/request was only Redmin, you and Reception, it really is not consensus and i will be quiet about your favourite "non-controversial"... Extension was enabled about 30 hours after request...--MrJaroslavik (talk) 22:14, 20 February 2022 (UTC)
 * I completely agree with MrJaroslavik. That report thing was awful and thank god it is removed. We do not need a repeat of that. Naleksuh (talk) 00:38, 21 February 2022 (UTC)
 * Let's be smart about this and not try to cancel Doug over something as trivial as enabling the moderation extension (which he definitely shouldn't have enabled to begin with), or over something that occurred about a year or so ago. I may disagree with Doug on certain things, but having this weird obsession about his past actions is just absolutely not needed here, and is practically an unhealthy habit. DarkMatterMan4500 (talk) (contribs) 00:46, 21 February 2022 (UTC)
 * I am not "cancelling Doug". Simply saying that someone should not have did something is not cancelling, it is simply holding someone accountable for their actions. The only way to avoid that is to do nothing. There is no "cancelling", this isn't 4chan. Naleksuh (talk) 05:55, 21 February 2022 (UTC)
 * If someone repeats their mistakes and continues his arrogant behavior (on-wiki), should we remain quiet? Please stop defending him at all costs...--MrJaroslavik (talk) 06:09, 21 February 2022 (UTC)
 * Please stop defending him at all costs There are two ways to interpret this. Are you saying that they were defending at all costs and need to stop, or that they should stop at all costs? Naleksuh (talk) 06:13, 21 February 2022 (UTC)
 * DMM don't want see issues and defending Doug always, so i guess it's first option.--MrJaroslavik (talk) 06:38, 21 February 2022 (UTC)
 * I think it is a shame that this topic must once again be repeated after the last time which caused a lot of issues and argument. First of all I think that some people here have been overreacting and have turned this 'scandal' a bit more personal than it should be. I think that the main issues here is that there is no written policy about this and that invites for confusion and for people not to know: 1) when a Steward can enable an extension (if ever) 2) when a Bureaucrat can request to enable an extension without prior community consensus 3) when Community consensus is required to enable an extension. In my opinion in this case I do not think it was necessary to enable this extension as Steward however in an emergency it may have made sense for a Bureaucrat to authorise it without prior community consensus. This is however just an opinion which demonstrates that it may be unclear to people when extensions can be enabled which is why a policy would be best. If people agree I would be willing to attempt to write one for this. To conclude however I do not believe that Stewards should be enabling extensions in the vast majority of cases as there is no justification for it generally. --DeeM28 (talk) 06:17, 21 February 2022 (UTC)
 * Hmm, there is no policy... It was discussed year (?) ago and he know about it. Issue is not on my/our side, issue is on his side, he is repeating same mistakes as like before (desysop, de-steward requests and others discussions)....--MrJaroslavik (talk) 06:38, 21 February 2022 (UTC)
 * DeeM28, I agree with your thoughtfully considered points. Meta Wiki is a special wiki for a couple reasons. For one thing, it is the primary public facing website for Miraheze. For another, Meta Wiki is used for global administration of wikis, global blocks, global account administration, and wiki administration and creation. As such, Meta bureaucrats, a locally elected role, cannot have ManageWiki access. Part of the confusion here stems from the unclear historical practices. Indeed, in the past, it was somewhat common for Site Reliability Engineering team members, a non-elected technical role, to perform certain actions, particularly when Stewards were not active at the time or because it was unclear. My understanding was that I should normally obtain a Meta bureaucrat's authorization to enable an extension, notwithstanding cases of crosswiki abuse where the IP hopping was persistent, sustained, and blocks were ineffective. So that's why I enabled the extension, temporarily, and started this discussion to see whether the community agreed with that and to define how it should operate. In any case, the extension configuration would have taken too long to configure, so was just about to revert the addition when I saw John had reverted it for me. I hadn't realized he was even available, otherwise I would have asked him (Reception123 had already gone to bed) for his thoughts or if he thought there was a better approach. Going forward, though, I'll ensure that a Meta bureaucrat authorizes any extension changes or asks that it go to a community discussion first, even cases of counter-vandalism mitigation prevention reasons. Dmehus (talk) 06:40, 21 February 2022 (UTC)
 * I think it's definitely fair to ensure from now on that a Meta bureaucrat authorises any extension changes and that would be a satisfactory resolution to this dispute/thread. A Meta bureaucrat would then decide whether the extension should can be authorised by them alone or whether a discussion is needed, and if they feel like the latter is needed, then they would let the Steward know that they don't authorise the change. Reception123 (talk) ( C ) 06:57, 21 February 2022 (UTC)
 * I think ^ from Reception is a reasonable take, although in my opinion there are only two valid scenarios that would entail a Steward's managewki intervention.
 * One is an emergency. Immediate action to stop an unprecedented extreme issue. I believe any Steward should be able to take action as soon as they can. The scenario of this thread was not an action I believe justifies that.It meant well, but it needs to set a higher bar.
 * The second is non-emergency, at which point surely the given Steward can afford to wait. If they can wait, they can discuss first and act later, attaining consensus in the normal manner or if it is still urgent, still by making the inquiry in a public venue. Anything from 'somewhat important' to say, a Meta RfC where a steward should be requested to enact a ManageWiki change result.
 * I don't think there's really room where a Steward should request a bureaucrat/bc-steward for input that doesn't also entail community discussion and the first case should be absolutely temporary until a community discussion removes it/ratifies something longer term. I do agree in a wider principle that a) stewards should discuss with each other where available and b) if a meta bureaucrat, especially a meta bureaucrat + steward is available, they should be consulted if there is evidence they are just about immediately available even in an emergency which did seem to be the case here and would have avoided the current fuss. I don't think this was handled optimally, but if we can draw a clear line here and Doug follows it, the issue needs to go any further than that. But it's clear that as a community we have various different opinions where to draw the line for action, so right now I'd find it hard to come out with a concrete advisory if I were treating all statements here as equal. --Raidarr (talk) 14:34, 21 February 2022 (UTC)

I think this sounds a bit fair. And regarding what Naleksuh and MrJaroslavik said above: No, I wasn't trying to defend what Doug did about a year or so ago or the fact that he questionably enabled that extension (which really shouldn't have happened to begin with), nor was I attempting to silence you guys from having an opinion (I mean, anyone is welcomed to vent out their frustrations, and/or voice out other concerns for that matter). If I may also add that you and Naleksuh had every right to point out what he was doing wrong, but perhaps try to keep an open mind (which I know for a fact that you and Naleksuh are indeed open to any potential ideas that might work), but it does annoy me that I have to repeat what I said from a year ago, and seeing the latter has been more aggressive than usual, which really left me baffled. All in all, you might want to consider looking at the reply I left here a bit more carefully, rather than jump to conclusions saying that I'm defending his actions. The recent action he did make really did baffle me, and I had absolutely no idea what his thought process was in enabling that said extension. DarkMatterMan4500 (talk) (contribs) 14:43, 21 February 2022 (UTC)

Interface administrator for Arcversin
I'm pleased to be able to submit this request for Meta interface administrator for Arcversin, as it's a role tailor made for him given his extensive CSS and JavaScript knowledge. His primary focus will be on maintaining, de-Wikipedifying, and customizing existing (including, but not limited to, Twinkle) and new gadgets. He understands that changes to MediaWiki:Common.css and MediaWiki:Common.js have widespread impacts to everyone, so should have at least a brief discussion at Administrators' noticeboard, typically one in which a Meta administrator would have participated, and that Meta administrators are those locally elected functionaries which will add local sitenotices to discussions, though they may delegate this function to non-elected interface administrators in their discretion. I will let Arcversin add to his rationale for requesting the permission, confirm that he has a strong password for his account, and then let any bureaucrat grant the permission. Dmehus (talk) 17:46, 21 February 2022 (UTC)
 * I can confirm that my account has a strong password (and 2FA). In the immediate future, I plan on preparing a version of MoreMenu for use on Miraheze. — Arcversin (talk) 17:58, 21 February 2022 (UTC)
 * I think this would be reasonable, especially to gather the grassroots support for becoming a full administrator. The primary issue of trust I don't think is a problem here, and I support it as a method towards deeper and more prolific involvement. --Raidarr (talk) 18:00, 21 February 2022 (UTC)
 * This seems like a reasonable request with a sensible use case and made by a trusted user who has JS and CSS knowledge. ✅. Reception123 (talk) ( C ) 19:54, 21 February 2022 (UTC).
 * Twinkle has already been de-Wikipediaified, there's nothing more to do there. Although I am the primary person responsible for it there is certainly no reason why any other interface-admin cannot edit the associated pages. But there's not any de-Wikipediaifying or maintenance to do right now, so I'm not sure why that was brought up as an example. Arcversin, if there is something not working with Twinkle, any reason why it has not been brought up to me or somewhere else in a public forum I could have seen it in beforehand? Naleksuh (talk) 02:07, 23 February 2022 (UTC)
 * Twinkle is working just fine, I believe Doug was just using that as an example since it's pretty well known. — Arcversin (talk) 03:13, 23 February 2022 (UTC)

Creating pages on Terrible TV Shows Wiki.
I want permission to create pages on Terrible TV Shows Wiki. SonicFTW (talk) 06:54, 27 February 2022 (UTC)