Wikipedia:Village pump (proposals)

Survey (mover protection)

Currently there is no in-between between sysop and XC move protection, meaning that in the case of controversial topics (e.g. my earlier close of President Donald J. Trump International Airport) us page movers have to go through RM/TR, despite the fact that the right signifies that the community (presumably) trust us enough to enact these moves ourself. So my proposal is that a new move protection level, which allows only users with the extendedmove user right to move, be added, and add this user right to the sysop and extendedmover user groups. I can make the patch if there is consensus.

(Pinging @Skarmory, who proposed the idea on Discord.) msk 00:59, 25 September 2026 (UTC)

My personal most recent run with this was Talk:Economy of the Haudenosaunee#Requested move 11 July 2026. I see no convincing reason why this should've had to go through an admin.

A comparable user right and protection level would be template editor and template protection. Circumstances are a bit different, but there is precedent for user rights related to specific actions being able to edit past protection of those actions. Skarmory (talk • contribs) 03:03, 25 September 2026 (UTC)

This all seems very sensible to me. Thryduulf (talk) 08:20, 25 September 2026 (UTC)

I would support this. Most move-protected pages are from page-move vandalism or page move warring (source: just a guess), and I think by granting someone page mover the community trusts them not to perform page move vandalism. Axolitl (talk | contribs) 22:39, 25 September 2026 (UTC) edited 22:40, 25 September 2026 (UTC)

I also was discussing this on Discord too at a different time, though in an unrelated context. I would support this, especially since it means that admins would have a reliable middle ground to not need to default to full move protection when extended-confirmed protection is insufficient, except in the most extreme of cases. Any page mover who can't be trusted to, well, move pages responsibly and in accordance with policy, probably should not be a page mover. I think we should probably at least informally expect that admins do not use this new protection level for edit protection, only move protection, similarly to how template editor protection isn't (usually?) used on articles, since it's inconsistent with why the right was created. EggRoll97 ^(talk) 01:58, 26 September 2026 (UTC)

IIRC I can implement it to be an option for move-protect only. msk 02:06, 26 September 2026 (UTC)

Er, are you sure? The array in wgRestrictionLevels (which controls the protection options) is 'enwiki' => [ '', 'autoconfirmed', 'extendedconfirmed', 'templateeditor', 'sysop' ], so unless you have another location for more fine-grained tuning in mind, I don't think it can be technically restricted from being used as an edit protection level (nor do I think we really need to, I think we can just trust that admins wouldn't use it for something it's not designed for). EggRoll97 ^(talk) 05:40, 26 September 2026 (UTC)

Nope, you're right. Sorry about that. msk 14:13, 26 September 2026 (UTC)

Support. Page movers can be trusted to move the mine run of move-protected pages (in mainspace at least), so I'd be on board with downgrading a large number of protections if this is successful. Expectations like "don't use for edit protection" can be documented in a new section at Wikipedia:Protection policy. Extraordinary Writ (talk) 05:56, 26 September 2026 (UTC)

I accept that this proposal wouldn't save time on net, but I still think it's important just as a matter of principle to apply the least restrictive level of protection necessary and only take things away from non-admins as a last resort. That's probably an unorthodox position, though. Extraordinary Writ (talk) 01:44, 21 October 2026 (UTC)

@Extraordinary Writ: Adding a new protection level above extended confirmed is likely to make page moves more restricted for the broader community, not less. The typical long-term editor's most advanced group is extended confirmed. The better solution is to reduce the frequency of full move protection. Daniel Quinlan (talk) 01:59, 21 October 2026 (UTC)

Adding a new protection level above extended confirmed is likely to make page moves more restricted for the broader community, not less.
So your argument is that, if we add mover-protection, admins applying move protection would disregard our policies and use mover-protection even where, at most, only ECP move protection would be allowed? FaviFake (talk) 15:55, 21 October 2026 (UTC)

ECP move protection is non-standard; see Wugapodes' comment. msk 16:27, 21 October 2026 (UTC)

Then IAR applies. If an article can't remain confirmed-move-protected but doesn't need to be admin protected, use ECP. For example, the current TWAFI has been EC-move-protected for a week due to the relatively minor potential for disruption. FaviFake (talk) 18:21, 21 October 2026 (UTC)

No, I just think it's inevitable. How it happens will likely be reflected in policies and guidelines. Daniel Quinlan (talk) 16:56, 21 October 2026 (UTC)

If I understand correctly, the argument is something like this: Right now there is only ECP and the far more drastic admin-only move protection. There is some number of pages where maybe ECP isn't quite doing the trick but the currently available next level feels too extreme. Some, many, perhaps the vast majority of these remain at ECP. If we introduce this intermediate protection level, it will be more palatable to increase the protection on more and more pages without having to go all the way to admin-only move protection. Over time, the total number of pages that have a move protection level higher than EC will be potentially much greater than it is today. A downstream effect will be that requests to increase or decrease between the different levels will increase. —Myceteae‍🍄‍🟫 (talk) 18:21, 21 October 2026 (UTC)

Why would it be more palatable to increase the protection on more and more pages? To whom would it be more palatable? If a non-admin thinks ECP is not enough, they'll go to RfPP regardless of whether there is another available intermediary protection type.

If an admin lands on an article and they think ECP is not enough, they'll simply apply mover-protection and move on. I don't see the issue here. FaviFake (talk) 18:25, 21 October 2026 (UTC)

I'm not making this argument but my understanding is that admins sometimes encounter pages where ECP might be too loose but admin-only might be too restrictive. Some portion of these, perhaps the majority, remain at ECP. If they had another intermediate option available, they would use it. I'm not an admin and rarely have requested or participated in discussions about page protection. I don't have any sense of what the potential impact would be. —Myceteae‍🍄‍🟫 (talk) 18:52, 21 October 2026 (UTC)

I think it was said elsewhere in this discussion that ECP is not applied for moving without it being applied for the whole article, even though it can technically be done, because there's no guidance as to when it would be allowed. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 18:56, 21 October 2026 (UTC)

Ah, maybe that was more the issue. —Myceteae‍🍄‍🟫 (talk) 19:00, 21 October 2026 (UTC)

At the very minimum, at least one of ECP or page mover should be a valid move protection level. Skarmory (talk • contribs) 19:05, 21 October 2026 (UTC)

Note: Wikipedia talk:Page mover has been notified of this discussion. Axolitl (talk | contribs) 05:20, 27 September 2026 (UTC)

Support I think this could provide a good middle ground allowing for a smoother process. For pages where just EXCON is barely not enough to protect them from bad moves there's not really a reason to directly limit it to sysop and if a page mover abuses their rights to move such a page, imo they should and would loose their right immediately... squawk7700 (talk) 10:05, 27 September 2026 (UTC)

Oppose Looking back through Wikipedia:Requested moves/Technical requests#Administrator needed during 2026, I see only 49 requests. Some of these wouldn't be helped by this new protection level, for example this one that needed an admin to delete a conflicting redirect. This doesn't seem like it's enough of a problem to require a whole new protection level. Anomie⚔ 13:08, 27 September 2026 (UTC)

I would expect if this would implement we would be somewhat more free with protecting things at this level, so the current rate of requests is a lower bound but the upper bound is much higher. My personal opinion is that we should generally be much more free with move protections on potentially contentious or high-visibility topics, since unlike edits those should very rarely be done without consensus anyway. Rusalkii (talk) 23:54, 27 September 2026 (UTC)

I'm not sure that more protection would really happen, or that if it did that it would be a good thing. Meanwhile, that "lower bound" is very low. Anomie⚔ 00:48, 28 September 2026 (UTC)

Why not? We have an absurd number of bureaucrats, even though they mostly do nothing with those powers. Cheers, _{In solidarity}User:Wikipedian12512(alt) (Talking is fine | contribs) 14:57, 28 September 2026 (UTC)

It clutters the configuration and the protection interface. The comparison with the number 'crats is not a good one, since more or fewer people in that list doesn't affect anything else. Anomie⚔ 23:11, 28 September 2026 (UTC)

Support, per my comment above. I participated in at least one of the discord discussions on this topic, but I saw this RfC through CENT and expect I would have ended up here regardless. — Preceding unsigned comment added by Rusalkii (talk • contribs) 16:57, 27 September 2026 (UTC)

Just a note that this isn't an RfC, although one may come in the future. Axolitl (talk | contribs) 03:29, 28 September 2026 (UTC)

Support – Page movers are usually trusted. This is the same as fully protecting templates before the template-protection level was created (just at a smaller but still significant scale). FaviFake (talk) 00:03, 28 September 2026 (UTC)

Support have thought similar before, especially with how long such TRs can sit unattended to, ie 24-48 hours unnecessarily. Sometimes it feels like RM closes are undergoing an admin review rather than the move request itself (or that's how it's felt personally), so the additional delays aren't appreciated from a closing perspective either, especially when it only needs brief oversight from another page mover. Per above if page movers can't be trusted to move pages that are extendedmove protected then they should have rights revoked. CNC^{in solidarity} (talk) 06:10, 28 September 2026 (UTC)

Support – Page movers should be able to move pages. Being trusted to do so responsibly is the whole point of the user right.

I have on multiple occasions expressed my frustration both on- and off-wiki (although not actually in the discussion that led to this RfC, which I was pleasantly surprised to see in WP:CENTRAL) about being a page mover yet being unable to move pages. It is a regular source of additional work and annoyance (especially for more complicated closes) for page movers closing RMs and the admins who have to stand-in to carry out the moves. On multiple occasions I've had to spend time explaining to editors asking me why the pages haven't been moved that yes, the closing template has a field that explicitly states that a non-admin page mover performed the close, but no, that page mover cannot move the page. Yes, it is relatively rare, but the additional work adds up and there is no good reason for it to be happening at all.

We are trusted with the ability to override the title blacklist, create and edit page edit notices and redlink almost anything by moving without leaving a redirect (and some other stuff), but somehow not trusted to do normal moves for pages that some other editors have been improperly moving. If someone cannot be trusted to deal with the ability to move pages that are move protected they should not be trusted to do any of these other things. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 16:33, 28 September 2026 (UTC)

Just going to note that many (but not all) of the arguments along the lines of there being no need do not really argue why it would be a negative, and that the concerns about it being too much work are ignoring that msk offered to do it (and for the record, they are more than capable of doing so) which makes it a very low cost for the community-at-large (unless we want to insist msk would otherwise be obligated to spend that time working elsewhere on the wiki). –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 08:50, 23 October 2026 (UTC)

Personally, I'm seeing the opposite: a lot of the support votes focus on "page movers can be trusted to move pages" without considering whether there's enough of a need to balance the increases in complexity in interfaces and processes that result from adding another protection level. Anomie⚔ 11:54, 23 October 2026 (UTC)

There isn't much to say about that. If we want pages to be protected more precisely, then we need to add a new level, which should be used and requested if needed. The benefits of adding one more option in the drop-down are greater than leaving pages with an undue move-protection level. FaviFake (talk) 11:59, 23 October 2026 (UTC)

Most of the discussion here doesn't seem to be about protecting pages "more precisely" in the first place. It's about page movers being unable to handle the RM in the relatively rare cases where a fully-move-protected page needs moving, but without evidence this is leading to any sort of a backlog or unreasonable delay. Anomie⚔ 12:06, 23 October 2026 (UTC)

That's just a direct consequence of the fact that admins are currently forced to use full move protection in cases where ECP is not sufficient. FaviFake (talk) 12:11, 23 October 2026 (UTC)

What is? That most of the discussion isn't about what you claim, or that there's no backlog? Either way, I don't see how it supports your point. Anomie⚔ 22:49, 23 October 2026 (UTC)

Not sure if I've said this elsewhere in the discussion, but I do definitely think there are benefits to having this level around; I would think it would be a better level to use for cases of page move vandalism or move warring than full move protection when ECP isn't sufficient. Skarmory (talk • contribs) 13:50, 23 October 2026 (UTC)

• Oppose. Just let page movers move all pages. If they can't be trusted with such power, they shouldn't have it. Jessintime (talk) 16:35, 28 September 2026 (UTC)

  This is a different proposal than the once considered here. If, hypothetically, your suggestion couldn't be implemented and you were left with only two choices, would you prefer to keep the status quo or create a new protection level?​ FaviFake (talk) 16:40, 28 September 2026 (UTC)

  Taken literally that is an incredibly bad idea. Letting page movers move any page would give them the ability to "edit" (replace the contents) of any page, including interface pages, the local global js/css files, etc, pages that even regular administrators can't edit. If a page mover were then to be compromised they could then engage in significantly more disruption. msk 17:27, 28 September 2026 (UTC)

  Yeah pages that have higher-level protections should require corresponding permissions to move. Some widely-used templates also break if you move them due to accompanying css modules. We recently had an incident where an RM led to some list templates were moved, such as Template:Hlist to Template:Horizontal list, and that caused a large part of the wiki to break, including the main page, although it was fortunately swiftly fixed. That move also queued so much work for the backend jobrunners that it put enough of a strain on the backend for a WMF employee to take notice and ask that further moves be held off to let the queue be cleared.

  Knowledge of this is not something page movers are expected to have, and the potential for disruption is on the level of "you can break the website doing this". Brings to mind that video of a chimpanzee being handed an AK-47. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 18:02, 28 September 2026 (UTC)

  MSK (Monkey Shooting a Kalashnikova) msk 18:04, 28 September 2026 (UTC)

  To be honest, that should be a separate proposal. (Not to mention that allowing PMVs blanket access to the move tool might not be a good idea for the reasons mentioned by other users above.) Accessedgrant (Epicgenius mobile alt) (talk) 16:42, 6 October 2026 (UTC)

Comment how frequently do pages get fully move-protected because XC move-protection isn't sufficient, where the reason isn't a move war (for which full protection should continue to be used should this protection level be created) and why? Snowmanonahoe (talk · contribs · typos) 18:41, 28 September 2026 (UTC)

I had a similar question. I'm a fairly new page mover and I've actually not encountered this barrier yet although I am aware of the issue. My understanding is that the practical effect of this change would be primrarily to allow page movers to carry out RM closures for pages that fall under the first two bullets at WP:MOVEP (pages prone to vandalism and frequent page-move disputes). The purpose of page protection in these cases is to force a formal RM discussion, and page movers are entrusted to close and carry out complex and contentions RMs. I would think that the third MOVEP bullet (high visibility pages like WP:AN and Today's featured article) could maintain a higher, admin-only protection level. The discussion above highlights another category, templates and other complex pages where moving may break other parts of the site (although it's not clear if the templates discussed above were move-protected at the time or if the protection level was sufficient). —Myceteae‍🍄‍🟫 (talk) 18:53, 28 September 2026 (UTC)

Just to provide some context, the current list of fully-move-protected pages is at , and while I don't have a hard number for you, there is page after page of this. Anything from arbitration enforcement, to vandalism, to sockpuppetry, you name it for the reasons. As for where the reason isn't a move war, I would actually say page-mover-protection should be the default for move wars if created, as the main idea of the page mover group is that it is experienced and trusted users who regularly move pages and demonstrate familiarity with Wikipedia's policies and guidelines regarding page moving and naming, which is a quote directly from the page mover policy. EggRoll97 ^(talk) 04:35, 29 September 2026 (UTC)

Weak oppose I like the idea, but I'm convinced by Anomie and BilledMammal that the demand isn't really there. Especially if it does in fact require a patch to MediaWiki core, which we seem to be unclear on(...?)

This RfC looks like it's going to pass, so one thing I will say is that this action should be treated with a certain gravitas like we do with redirect suppression and template editor. The protection policy should say that a page mover should in most circumstances only move a move-protected page when implementing their close of an RM. Snowmanonahoe (talk · contribs · typos) 05:47, 29 September 2026 (UTC)

Agreed that moving through move protection should not be done lightly and should mostly be used for implementing results of consensus discussions. Skarmory (talk • contribs) 02:07, 30 September 2026 (UTC)

I mean yeah, I fully expect of all page movers to understand that move protection is generally a very clear indicator that a move will be controversial and thus require an RM. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 02:49, 30 September 2026 (UTC)

Support convinced by Extraordinary Writ's second comment above. Snowmanonahoe (talk · contribs · typos) 01:50, 21 October 2026 (UTC)

Hey @Sohom Datta, is there a reason you made this an RfC? AFAIK, the template shouldn't be added retroactively. It makes the old !votes a bit more confusing in context. Axolitl (talk | contribs) 00:52, 29 September 2026 (UTC)

It was on WP:CENT, and we were already !voting in the RFC style, so I assumed this was intended to be a RFC and the RFC tag just hadn't been applied. (No concerns from my end if there is consensus to not make this a RFC) Sohom (talk) 03:31, 29 September 2026 (UTC)

That's fine, though should we rephrase the opening statement, so it stays neutral? Axolitl (talk | contribs) 04:07, 29 September 2026 (UTC)

Pinging @MSK for their thoughts on this, as they were the one who started this discussion. - BlueEleephant (talk · contribs) 02:02, 30 September 2026 (UTC)

I did rephrase it as Should a new move protection level be created, which only allows page movers and administrators to move it? I tried to keep the intent of the original, while maintaining neutrality. Axolitl (talk | contribs) 02:11, 30 September 2026 (UTC)

Note that the "it" should have probably been "the page", but it's kind of too late now. Axolitl (talk | contribs) 02:11, 30 September 2026 (UTC)

I think the intended meaning is clear in this discussion. —Myceteae‍🍄‍🟫 (talk) 16:16, 30 September 2026 (UTC)

• Support the idea, but this could end up blocked on the technical side. I think it will require a patch to MediaWiki core, and I am not sure this idea is wiki-agnostic enough to justify adding complexity to MediaWiki core. I've made a phab comment at phab:T439172#12372365. –Novem Linguae (talk) 02:45, 29 September 2026 (UTC)

  I've rephrased the issue because of that; this will be enwiki specific. msk 02:47, 29 September 2026 (UTC)

  The technical obstacles are not as severe as I thought. It looks like this can be done in config files, without making changes to MediaWiki core, except for some translation messages to be added to mw:Extension:WikimediaMessages. –Novem Linguae (talk) 21:30, 29 September 2026 (UTC)

  Thinking about this more, could we perhaps just encourage making most move protection extendedconfirmed rather than sysop? Or is there some evidence that there are lots of cases where extendedconfirmed folks are not trustworthy enough but page movers are? –Novem Linguae (talk) 05:38, 30 September 2026 (UTC)

  Good questions. It's also been suggested here that (page mover) move protection might be applied more often if this proposal goes through. —Myceteae‍🍄‍🟫 (talk) 15:11, 30 September 2026 (UTC)

  Most of the page protections that I have seen would have been fine as extendedconfirmed protection. For example, the move vandalism at Epstein files. BilledMammal (talk) 23:45, 20 October 2026 (UTC)

  I think some could be reduced, but that is absolutely not the example I would have picked. That general topic area is more disrupted than almost every topic area, and that specific article has been move vandalized.

  We could consider mass reducing the move protection level (to extended confirmed) all main space articles that are extended confirmed edit protected with full move protection if the article has never been moved (including moves at prior locations). It would be fairly easy to write a one-time script to do this. I suggest "never been moved" rather than "never been move vandalized or subject to a move dispute" because the latter would require a massive and complex manual review and the simple approach would yield most of the benefit. This proposal would need an RFC and we would want to review the full list of articles that would be affected first, obviously. Daniel Quinlan (talk) 00:22, 21 October 2026 (UTC)

  The move vandalism there was by an editor who was not extendedconfirmed. It was also by only a single editor; blocking that editor and not apply any protection would probably have been sufficient, but if it wasn't applying extendedconfirmed move protection would have been. BilledMammal (talk) 01:52, 21 October 2026 (UTC)

  Back in 2021 when Xeno and I were working through old move protections, the concern with using ECP for move protection was that it's never really been used outside of contentious topics, and neither WP:MOVEP nor WP:ECPGUIDE say that ECP move-only protection is allowed. They still don't. It's been a decade, and we still haven't documented all the corner cases of ECP. You can see the old AN discussion on the protection reviews for some old opinions on the idea. I'm not sure we ever finished reviewing all the old protections. It was like 9000 articles, but most of them could simply be unprotected. I did about 50, Xeno did nearly 500. It's why we added the unprotection reasons to the list of drop down options in the protection interface. This is to say, I'd be fine with allowing ECP for move protection, and would also encourage people to unprotect some stuff listed at User:Wugapodes/moveprotectreview. — Wug·a·po·des 00:30, 21 October 2026 (UTC)

  If this proposal fails, there should definitely be a discussion about ECP move protection, because not having anything between autoconfirmed and full protection for moving pages enshrined anywhere seems wrong, especially if ECP is in actual use. Skarmory (talk • contribs) 18:25, 21 October 2026 (UTC)

  EC move protection is already covered in the protection policy. Move protection of any duration may be applied to pages being repeatedly moved in violation of policy using the lowest protection level sufficient to stop the disruption (extended-confirmed or full). ~ Jenson (SilverLocust 💬) 23:35, 21 October 2026 (UTC)

• Support. This is good idea. It would allow admins more freedom to move-protect pages and let trusted pagemovers handle more controversial moves. Protection limited to people experienced with pagemoves is fairly similar to template protection for people experienced with templates, which I think is widely recognized as a useful tool. On procedure, I don't see how the presence or absence of an RfC tag has any impact on the validity of the consensus produced here, whatever that may turn out to be. The main point of the tag is to attract people watching the RfC categories to prevent local consensus issues, but VPPROP and CENT are sufficiently high profile to do the same. Toadspike [Talk] 11:11, 29 September 2026 (UTC)
• Support. Page movers are generally not stupid, and similar to when we established template editors, only the highest of the high-risk needs to be kept behind the sysop gate. Please ignore my brazen conflict of interest here, and perhaps consider me an exception to the first clause of my previous sentence. With love from Maryland, charlotte ^👸♥ 09:06, 1 October 2026 (UTC)
• Oppose. An additional move protection level will almost certainly lead to more protection requests and actions to adjust protection levels, and these requests will outnumber the move requests this would potentially avoid (which is only when a page happens to be at this level and a page mover happens to handle the request). I believe the real issue is that extended confirmed is a poor proxy for trust when it comes to page moves. We should address that issue instead. I also agree with Anomie that this would clutter the configuration and protection interface, and as someone who has handled many page protections, I believe adding another level would make each protection decision more complex and slower. Daniel Quinlan (talk) 20:11, 1 October 2026 (UTC)

  extended confirmed is a poor proxy for trust when it comes to page moves. We should address that issue instead.
  This is an attempt to solve this exact issue. How do you think the 30/500 protection could be limited to more users? I don't understand; if we make extended-move-protected pages require, say, 1000 edits instead of 500, that's no longer "extended-move-protection". FaviFake (talk) 20:14, 1 October 2026 (UTC)

  I didn't propose specific changes to extended confirmed, but I'm ready to join a discussion about other approaches at WP:VPI. I oppose this proposal because it likely adds more work than it saves. An acceptable approach would reduce reliance on sysops for page moves without adding more sysop workload than it saves. Daniel Quinlan (talk) 20:47, 1 October 2026 (UTC)

  Sure, I was just confused about how it could be possible to address this issue by modifying the 30/500 move protection in a way that wouldn't completely change the protection level itself. FaviFake (talk) 20:52, 1 October 2026 (UTC)

  OT/FYI: there have been discussions at WP:PP regarding a new protection level, something between ECP and Full stil get's my support. The fact there is nothing between a busy one month editor and admin protection is baffling, aside from imposing PBAN/TBAN/CBAN. Personally I prefer the high bar like 5K/6M or 10K/1Y as "Advanced protection", then just yank privileges when needed, something we never do for experienced editors as 500/30 as is only a month break by comparison, so bans become necessary. A 6M/1Y defacto ban from editing pages with advanced protection makes a lot more sense overall, if that is the issue with certain users. In absence of that, I support this idea. CNC^{in solidarity} (talk) 09:27, 3 October 2026 (UTC)

  I don't really see why it needs to lead to more frequent requests for move protection, other than perhaps as a result of admins being more willing to use it, and discussions about changing the move protection level would be exceedingly rare – the only situation where you would realistically use full move protection would be on highly-visible templates.

  For article space, I expect things to function pretty much just like they do now but with page movers able to move pages, and potentially with admins being more willing to use move protection on pages (which I don't see as workload as much as more tools to work with). –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 22:04, 1 October 2026 (UTC)

  An increase in protection levels is not just "more tools" and it's definitely not a free lunch. Every new protection level creates two new boundaries, and we regularly field requests to increase or lower protections (both on RFPP and on sysop talk pages), and many of those are rejected due to insufficient disruption or excessive risk. Adding a new protection level because a small number of requests take a day or two to resolve is using an expensive sledgehammer to swat a fly. Daniel Quinlan (talk) 23:49, 1 October 2026 (UTC)

  I know you field plenty of protection requests for the different kinds of protection we currently have in place, but that doesn't mean that this one will be the same, and there is good reason to believe that it would not be for the reasons I already mentioned. The way I see it the current move protection can be split in half with a pretty clear boundary between the two levels. The only editors that would even be affected by a change between full move protection and the lesser move protection is page movers, and I cannot imagine that page movers are going to be consistently requesting changes to the protection level of high-visibility template pages. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 01:29, 2 October 2026 (UTC)

• Support This seems like a good idea. Page Movers are on some level going to be inherently more trustworthy than extended confirmed users in these situations because they have more to lose if they abuse it. --Ahecht (TALK
  PAGE) 17:20, 9 October 2026 (UTC)
• Support as there are less page movers (467) than admins (808) and that PMs can be trusted not to move protected articles unless absolutely necessary (usually after an RM). I have the PM right also JuniperChill (talk) 11:55, 10 October 2026 (UTC)
• Oppose per BilledMammal below - the amount of effort spent dealing with this ultimately exceeds the value. * Pppery * _{it has begun...} 20:32, 10 October 2026 (UTC)
• Support per above, mostly on the idea that those with the extended mover right have been trusted with those tools. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:11, 12 October 2026 (UTC)
• Oppose a user group existing doesn't mean a protection level should also exist. The work saved needs to outweigh the work created. For work saved, it would save us one or two requests per week based on the comments from Anomie and Billed Mammal. Meanwhile, the work created is quite steep. New protection levels mean new protection policies for those levels that need to be maintained and argued about---it took 6 months and 2 RfCs to settle on the current ECP policy back in 2016. Editors will place more requests at RFPP to change protection levels, not all of good quality, that require more admin time to decide than the weekly technical request and distract from more pressing protection requests. The non-standard changes to the server-side code needs to be written and maintained even when the original writer stops caring. The trade-offs seem terrible. Page movers who can be trusted with sysop-protected pages should apply for the existing sysop permission rather than creating a new protection level and all the work that comes with it. — Wug·a·po·des 20:27, 12 October 2026 (UTC)

• I'm not in this group so maybe I'm out of line here but I stumbled upon this and it sounds like a no-harm addition useful to at least a small extent with a person willing to implement it. Blippy1998 (talk) 08:06, 19 October 2026 (UTC)

  You're not out of line. No one with advanced permissions of any kind inherently has any sort of authority over others as to how this website should be run. Snowmanonahoe (talk · contribs · typos) 18:44, 20 October 2026 (UTC)

  It sounds that way, but it's unfortunately a false economy. This approach will almost certainly generate far more work at WP:RFPP than it will save at WP:RM/TR. It would be better to find a different solution that doesn't have that downside. Daniel Quinlan (talk) 18:58, 20 October 2026 (UTC)

• Oppose per Daniel Quinlan and Wugapodes. The benefits don't seem to outweigh the potential problems/time spend. mdm.bla 17:58, 20 October 2026 (UTC)
• Oppose per Daniel Quinlan. Wikipedia doesn't need more and more and more levels of every option just for the sake of adding them. This applies to protection levels.Katzrockso (talk) 00:33, 21 October 2026 (UTC)
• Oppose - As I said ten years ago in a slightly different context: There is no need. Requests of this nature can be easily handled by an administrator ... as the current rate of occurrence is low. Anomie demonstrates above that this sentiment still rings true for the matter at hand now. There is also a reasonable argument to be made that a move-protection level between EC & Full is overarchingly undesirable, but I will refrain from making it until a need is demonstrated. — Godsy ^(TALK_CONT) 02:51, 23 October 2026 (UTC)

Discussion (mover protection)

Survey

Strong support for ECR (creation of articles) and confirmed (any edit at all). Disclaimer: I am here to canvass as a friend of Chompy. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 03:12, 20 October 2026 (UTC)

My original proposal is C, but after considering how many users game their edit count, I guess I'm going to support Option B. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 07:49, 20 October 2026 (UTC)

Support the use of ECR for Indian cinema (option B), presumably this would be through a WP:GS designation by the community. I wasn't aware of the social role that Indian cinema has until I started seeing the disruption (and LLM junk) here on enwiki, and I have not really watched any Indian movies to any real extent (saw one or two years ago but I can't remember which movies right now). I have no stake in this other than as an enwiki editor. ‑‑gurkubondinn 07:13, 20 October 2026 (UTC)

Support 500/30 rule for Indian cinema topic area - What do Indian cinema and Indian military history have in common? Both are intrinsically linked to caste, which has been THE primary motivator of problems with regards to the India topic area. The standard set is irrelevant as Indian cinema already falls under WP:CT/SA and thus it can be assumed discretionary sanctions are already on the table. The problem is more dealing with blatant mercenary editors and the caste/nationalist warriors that come out of the woodwork in defence of a film that supports their caste or weltanschauung. —Jéské Couriano v^_^v ^{Thriller Night!} 06:22, 20 October 2026 (UTC)

Option B. Autoconfirmed restriction is pointless. —Jéské Couriano v^_^v ^{Thriller Night!} 07:36, 20 October 2026 (UTC)

Option C as first choice, Option B, as second choice. I don't think autoconfirmed is pointless here. While registered editors can certainly game autoconfirmed, TAs are a sizable chunk of the problem, and they can't be autoconfirmed at all. It's not uncommon to have to tangle with a TA editor on a slop article four or five times in a day as they rapidly jump TAs and IP ranges. CoffeeCrumbs (talk) 09:56, 20 October 2026 (UTC)

For the benefit of the closer interpreting these multi-choice options, while I like C a tiny bit more than B, ultimately, my preference is for whatever helps create a working consensus for C or B. CoffeeCrumbs (talk) 04:09, 24 October 2026 (UTC)

Support Option C then Option B - Option C would restrict many of the SPI throwaway accounts who operate heavily in that space. However, it would could be a nightmare to enforce and cause more issues than we alrady have. Option B would be my second choice. --CNMall41 (talk) 20:44, 20 October 2026 (UTC)

Support 500/30 requirement with Option B per Jéské Couriano. --ABx11 (she/they) 00:35, 23 October 2026 (UTC)

Option B as proposer. This is a hugely problematic topic area rife with UPE, promotional editing, and identitarian conflicts as described in the discussion section. ECR is an appropriate remedy and will make sure those editing in the topic are are serious. Autoconfirmed would be an insufficient remedy due to the ease with which autoconfirmed can be gamed; the problematic editors in this topic area are more than passionate enough to game AC in order to edit here. Athanelar (talk) 10:57, 23 October 2026 (UTC)

As I said in the discussion, I support option D. I've trawled through the new users log quite a bit in the last two weeks and one of the things that comes up there frequently is that promotional edits are most often for companies based in India. Now, I do not know what proportion of Wikipedia editors are based in India, but if memory serves me correctly then there is only one promotional company that explicitly declared their location that wasn't based in India compared to 4 or 5 that were based in India. Placing the topic under autoconfirmed would both stop TAs from creating overly promotional drafts and discourage at least some of the promotional sludge that we see rear its ugly head a few times a day. In terms of South Asian Cinema, pages that are related to castes should already be covered by CT/CASTE (I am by no means an expert on South Asian cinema so I could be wrong here), so I don't see the need for anything extra. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 12:55, 23 October 2026 (UTC)

In terms of South Asian Cinema, pages that are related to castes should already be covered by CT/CASTE It's not that simple, and this is why it's hard for people not in the know to understand how deep the problems run here.

In Telugu cinema (Tollywood) for example, a lot of the major actors are either of the Kapu caste (Chiranjeevi, Ram Charan, Pawan Kalyan) or of the Kamma caste (Nagarjuna, Mahesh Babu, N.T. Rama Rao). Not only that, but there are major film dynasties too; the three people I mentioned from the Kapu caste are not just related by caste, but also familially, and their family has major control over the whole production environment in Tollywood. There's an incredible amount of intersectionality and identity politics here which goes way beyond anything in Hollywood, and a lot of unseen factors that can influence disruptive editing (e.g., if I'm a person of a caste which is related to the Kapus, then I might have an identitarian interest in downplaying the success of films whose major actors are Kamma, or conversely in lavishing praise on people and projects related to the Kapus). I'm not as knowledgeable about Tamil films or Malayali films, but I have no doubt the same things exist there. Then there's also a whole separate dimension of Hindu vs Muslim politics in movies like Dhurandar and Ustaad Bhagat Singh.

The reason why ECR is appropriate here is because otherwise antivandal editors in this topic area need a veritable degree on regional history and sociopolitics to understand half of the shit causing the disruption. Athanelar (talk) 16:32, 23 October 2026 (UTC)

That explains why I keep getting accused of supporting some other person I've never heard of when I block inappropriate additions. Wait til they hear I'm a white girl who's never left the states. ChompyTheGogoat [ Bleat | Munched ] 21:15, 23 October 2026 (UTC)

Thanks, that was really informative to me. ‑‑gurkubondinn 22:09, 23 October 2026 (UTC)

Support D then C - While I agree this area is problematic, ECR is a very high bar to meet (it takes the average editor over 1 year). It's already overused in my opinion, we shouldn't be expanding it's use. Let's see if a lower restriction could work, it can be changed later if truly needed. InfernoHues (talk) 14:52, 23 October 2026 (UTC)

Option B. I'm not sure if anyone has brought this up yet, but G5 would be difficult and confusing to apply under option C. If a non-extended-confirmed account creates an article violating ECR, then a different non-extended-confirmed account could make significant edits to it, rendering the article ineligible for G5. I would imagine this scenario to happen often enough—either as a concerted effort or just naturally—to render option C significantly weaker than it would seem. Kisseran (talk) 18:55, 23 October 2026 (UTC)

G5 says no substantial edits by others not subject to a block, ban, or sanction. Based on that I believe the criterion would only be nullified if there are substantial edits by someone who is EC. Or are you saying that because the subsequent edits aren't article creations themselves, they could be construed as overriding the inappropriate creation? I can see how that might get messy based on interpretation. My original suggestion had included allowing non-EC users to submit drafts through AfC and only prohibiting direct creations in mainspace, but I think that would just increase the workload for reviewers even more, and full ECR is a cleaner approach. ChompyTheGogoat [ Bleat | Munched ] 04:23, 24 October 2026 (UTC)

Support Option B followed by Option C. I proposed the autoconfirmed restriction initially, but since then I've seen increased disruption from confirmed accounts and indeed even by EC editors who have reached that status purely through inappropriate edits to this subject area that have gone unreported. There's a huge mess that editors who haven't spent time patrolling these articles aren't aware of, and it's going to take us a long time to clean things up. I no longer believe option C is sufficient and I think we'd just end up back here debating increased restrictions after continuing to chase down more bad edits by autoconfirmed accounts. ChompyTheGogoat [ Bleat | Munched ] 21:22, 23 October 2026 (UTC)

Discussion

I previously raised this at Wikipedia:Village_pump_(proposals)/Archive_228#Indian_cinema_CCTOP? but it came up again at WP:ANI#Jailer 2 and given the lack of traction in the first discussion I thought I'd raise it again.

As I said in the first discussion, and as @ChompyTheGogoat has now summarised; no one else seems to care that [Indian cinema] is rife with UPE and unsourced content, We have a whole corner of Wikipedia that's chock full of WP:PROMO.

Non-Indians have a tendency to underestimate the social role which cinema plays in India, and the degree to which nationalism, casteism, regional pride etc intersect with cinema. One needs only look at the mass reception to releases like Dhurandhar: The Revenge and the political discussion surrounding them to see that. I would go as far as to say that cinema can be just as controversial to an Indian audience as caste topics are (and they're often linked!) so it's no wonder that we see so much tendentious editing in this topic area.

I still insist that it would be sensible to place some degree of restriction on the Indian cinema topic area to maintain article quality, minimise disruption, and reduce the effort required for cleanup (although the extent to which anyone is trying to clean it up right now, I have no idea.)

Just to throw another example which came to mind, I remember the effort I had to go to in order to clean up Udit Narayan, an article about a playback singer which looked like this before I edited it in December. In January a sockpuppet again edited it back into a promotiomal mess. This was reverted and has since been stable, but it goes to show how a seemingly innocuous article can turn into a complete mess just becausr of the subject's relation to Indian cinema. Athanelar (talk) 10:48, 19 October 2026 (UTC)

Thanks for opening this. I stumbled into the subject mostly by accident and I've been doing what I can, but I'm only one person, and I've mostly been focusing on reverting and protecting - I'm not the right person to attempt to clean up the existing issues in articles. There is a existing task force, but from what I've seen most of the people involved appear to be fans or people who otherwise have a vested interest but also uphold WP principles and do their best to follow protocols with their editing. Unfortunately many of them aren't very experienced, especially with editing in any other areas. What we really need are more experienced editors who have no personal interest in the subject (like me) and can maintain NPOV. I've discussed it with others and was waiting on @IrisChronomia to write up a proposal, as they're more experienced, but I'm sure they have other priorities. The main idea we came up with was to require AfC for all new articles on the subject by editors who aren't EC (or autopatrolled, if there are any who aren't also EC). Anything else can be automatically draftified without attempting to determine notability, sourcing, or whether the creator is a UPE sock.

That only covers part of the issue, however - there's also a huge amount of problematic editing on existing articles. Personally I'd love to see semi protection applied by default, but I know that's a tall order. I'm open to other suggestions that would have a similar effect on minimizing disruptive editing by all the low edit count TAs/SPAs/UPEs/likely socks. Semi protection has solved most of the problems on most of the articles where I've requested it - only one had to be taken up to ECP. Most of them won't bother edit gaming and only reach autoconfirmed via edits to their target articles (if at all).

In terms of the overall project it would really help to have a few unbiased volunteers with experienced working AV. Even if they're like me and don't want to spend too much time trying to fix existing issues it would make a big difference if we could crack down on all the problematic editors so things don't continue to snowball - then we could chip away at improving existing content. Maybe someone could build a tracker for the project so that people can easily flag for COI, LLM, unsourced, etc. and editors who are involved can work their way through the list.

One other specific problem that's taken up an inordinate amount of my time (and is the most common reason for protection) is box office figures. This is (apparently) a very hot button issue that has a lot of bearing on how successful a film is considered, and there have been scandals involving gaming of reports. I know it's been discussed on wiki before (maybe someone else can find the links), and as far as I can recall the overall consensus was that it's relatively trivial to anyone not involved with the topic - and certainly doesn't need to be updated every five minutes! - but given how obsessed people are it's easier for us to allow them to be posted from reliable sources and focus on inappropriate insertions rather than trying to shut it down entirely. The issue is defining reliability. There are no official reporting sources in India, and BO trackers don't disclose their proprietary protocols, so we can only take their word on accuracy, and there can be a significant discrepancy. Current consensus within the project is to follow WP:ICTFSOURCES. Unfortunately, one of the most prominent sources - Sacnilk - was determined to be unreliable, and many otherwise reliable media sources quote their figures and must therefore be excluded as WP:FRUIT. I dug into things further and found that the actual discussions (such as they are) leading to reliability determinations for the handful of sources with independent internal tracking (including Sacnilk) were mostly based on vibes, not any particular proof that the figures or methodology are accurate. We've attempted to initiate re-evaluations at Wikipedia talk:WikiProject Film/Indian cinema task force#Reassessment of Sacnilk.com, Wikipedia:Reliable sources/Noticeboard/Archive 525#Reliability of Indian cinema box-office trackers, and Wikipedia talk:WikiProject Film#Reliability of Indian cinema box-office trackers, with no success. I don't personally care one way or another but I'd like to see standards applied consistently.

We aren't going to be able to make any progress on this unless editors are willing to step up and at the very least participate in discussions so we can establish said standards for others to enforce. People have to care, or it's only going to get worse. AI has made it far too easy for anyone to churn out a PROMO article in five minutes and get paid. ChompyTheGogoat [ Bleat | Munched ] 18:49, 19 October 2026 (UTC)

I'll also submit that if no one cares enough to argue against it, a few of us involved with AV/SPI can constitute a consensus to implement CTOP requirements. ChompyTheGogoat [ Bleat | Munched ] 19:04, 19 October 2026 (UTC)

Thanks for chiming in. I fully agree with the restrictions you've proposed, including both the AfC requirement as well as semiprotection. Athanelar (talk) 19:45, 19 October 2026 (UTC)

My suggestion of semi-protection across the board may turn out to be inadequate - I've just submitted two more for ECP. Not all articles are subject to the same level of disruption though, and I think we could at least trial it with semi and a low bar for ECP upgrades at WP:RPP. Maybe the disruptive editors will start to get the hint. Hey, a girl can dream, right? ChompyTheGogoat [ Bleat | Munched ] 03:22, 20 October 2026 (UTC)

@gurkubondinn since you asked to be notified. ChompyTheGogoat [ Bleat | Munched ] 19:43, 19 October 2026 (UTC)

Oop, I meant to tag him, thanks for that! Athanelar (talk) 19:45, 19 October 2026 (UTC)

Support the use of ECR for Indian cinema, presumably this would be through a WP:GS designation by the community. I wasn't aware of the social role that Indian cinema has until I started seeing the disruption (and LLM junk) here on enwiki, and I have not really watched any Indian movies to any real extent (saw one or two years ago but I can't remember which movies right now). I have no stake in this other than as an enwiki editor. ‑‑gurkubondinn 07:13, 20 October 2026 (UTC)

I would absolutely be in favor of an additional restriction on South Asian cinema. It's an absurdly deep source of UPE, sourcing issues, junk AFCs clogging things up. The Indian cinema task force has done a really good job at WP:ICTFSOURCES, but simply put, the people that want to write articles and force in content about every third-tier actor who appeared in a fourth-tier movie, and everybody who worked on or was even tangentially related don't follow that guidance. It's a real timesink on the community and noticeboards and LLMs have made this area even worse. CoffeeCrumbs (talk) 22:04, 19 October 2026 (UTC)

Strong support for ECR (creation of articles) and confirmed (any edit at all).

Disclaimer: I am here to canvass as a friend of Chompy. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 03:12, 20 October 2026 (UTC)

Is there anything else I'm forgetting from our previous discussions? I'm slightly afraid to attempt to dig back through all the threads. ChompyTheGogoat [ Bleat | Munched ] 03:16, 20 October 2026 (UTC)

Indian cinema already falls under WP:CT/SA. One of the existing example sub-CT topic bans is "Indian entertainment, generally or in a specific language", and another is "Indian political, ethnic, religious, and caste topics", which as mentioned films can tie heavily into. Given this, for those with deep experience in the topic, what existing potential remedies (WP:STANDARDSET) are not being used that would be helpful? Are existing potential actions being rejected, and if so, for what reasons? From reading above, it sounds like the issue may be a lack of people and understanding ("it would really help to have a few unbiased volunteers with experienced working AV"), in which case it would perhaps be a good idea to create some sort of information page at WP:ICTF that editors (including admins) can look at to get acquainted with the topic's challenges. CMD (talk) 04:21, 20 October 2026 (UTC)

I think we would need explicit consensus that current ECRs apply to cinema, as opposed to the subjective "tie into" - or designate it an additional subtopic per resolution 6b. By my reading military and castes are the only subtopics currently subject to said restrictions; anything more general is only covered by the default CTOP protocols. I would be more than happy with an admin action extending ECR. That would mean any article within the subject area should receive automatic ECP approval, correct? ChompyTheGogoat [ Bleat | Munched ] 04:35, 20 October 2026 (UTC)

The specific proposal here is to make sure ECR or similar applies. The standard set isn't really helpful if the number of people doing cleanup is slim to none compared to the people making the mess. It's an impractical amount of workload for the people doing the cleanup to individually report editors and articles for standard arbitration remedies. SA cinema needs to be under preemptive restrictions to reduce the quantity of bad edits coming in. Athanelar (talk) 05:16, 20 October 2026 (UTC)

And when I first realized the scope of the issue I did review the above arb case, and my interpretation was that the restrictions as currently worded don't apply in this area. I'm happy to be corrected in that regard. It's not the first time I've seen someone imply that ECR applies to a wider subgroup, but I think that may have something to do with the various amendments over time. If we implement ECP across the board I expect the disruption would drop to virtually nothing, and while there would be significantly less overall editing we could do more cleanup of the existing problems and less policing of new ones. SPAs often wouldn't even break autoconfirmed without being able to edit film articles, let alone EC. ChompyTheGogoat [ Bleat | Munched ] 05:23, 20 October 2026 (UTC)

Or when a large part of the people making the mess are using LLMs to make the mess, the asymmetry of effort becomes enormous. ‑‑gurkubondinn 07:42, 20 October 2026 (UTC)

Remember, the scope of WP:CT/SA was changed earlier this year to make the ECR restriction limited to South Asian castes and Indian military history (broadly construed). I don't think this is a case where additional documentation would be helpful; it's nearly impossible to get these participants to acknowledge sourcing in these areas, and it nearly inevitably ends up with blocks or restrictions at ANI. The problem isn't that there aren't enough knowledgeable editors in this area, but that there already a lot of knowledgeable editors in this area, pushing back at a tsunami. CoffeeCrumbs (talk) 09:52, 20 October 2026 (UTC)

Support 500/30 rule for Indian cinema topic area - What do Indian cinema and Indian military history have in common? Both are intrinsically linked to caste, which has been THE primary motivator of problems with regards to the India topic area. The standard set is irrelevant as Indian cinema already falls under WP:CT/SA and thus it can be assumed discretionary sanctions are already on the table. The problem is more dealing with blatant mercenary editors and the caste/nationalist warriors that come out of the woodwork in defence of a film that supports their caste or weltanschauung. —Jéské Couriano v^_^v ^{Thriller Night!} 06:22, 20 October 2026 (UTC)

This is such a great argument. Thank you. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 07:48, 20 October 2026 (UTC)

FYI for those participating in the discussion: I think the best way to go about this is that after a couple more days of discussion, if there is consensus (and there does seem to be) to designate a CTOP here and impose ECR on that topic, then I'll open a subsection here for an RfC on that question so that more people can be notified and we can get a robust consensus. If anyone disagrees with that approach, please do say so.

Based on what's been said so far, these are my proposed RfC prompts;

A. Status quo: South Asian cinema remains under the broader WP:CT/SA but is not subject to specific subtopic restrictions

B. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA and placed under the extended-confirmed restriction.

C. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA. Article creation is restricted to editors with extended-confirmed permissions. The topic area as a whole is placed under autoconfirmed restriction. (not sure if autoconfirmed restriction has precedent?)

Please give feedback/workshop these however you think necessary.

N.B., "South Asian cinema, broadly construed" includes films as well as all associated cast and crew including musical directors, musicians and playback singers primarily working in film, and is specifically inclusive of India, Pakistan, Bangladesh and Sri Lanka. Athanelar (talk) 06:46, 20 October 2026 (UTC)

Option B. Autoconfirmed restriction is pointless. —Jéské Couriano v^_^v ^{Thriller Night!} 07:36, 20 October 2026 (UTC)

Please note the above is not supposed to be the survey itself, just workshopping the questions. I'll transclude this response when I do open the RfC if you want, though. Athanelar (talk) 07:39, 20 October 2026 (UTC)

My original proposal is C, but after considering how many users game their edit count, I guess I'm going to support Option B. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 07:49, 20 October 2026 (UTC)

Option C as first choice, Option B, as second choice. I don't think autoconfirmed is pointless here. While registered editors can certainly game autoconfirmed, TAs are a sizable chunk of the problem, and they can't be autoconfirmed at all. It's not uncommon to have to tangle with a TA editor on a slop article four or five times in a day as they rapidly jump TAs and IP ranges. CoffeeCrumbs (talk) 09:56, 20 October 2026 (UTC)

Not pointless, but possibly insufficient. I suggested an autoconfirmed restriction initially both to be conservative and because I expected ECR would get tossed out as WP:SNOW. Just since that earlier comment multiple articles have been subject to ongoing disruption by a gaggle of editors barely over the confirmed line. There are some low count editors who make valid improvements, but I'm not sure the scale of their contributions is enough to offset the scale of disruption. My suggestion to one good faith editor who was stopped by ECP was to work on other subject areas and reach EC if they're that interested in continuing to contribute to film articles, which seems perfectly reasonably for any others in the same boat. More experience will help them do better work. (They were only inserting box office figures from accepted sources anyway, and getting increasingly frustrated by the limitations, so...) ChompyTheGogoat [ Bleat | Munched ] 14:51, 20 October 2026 (UTC)

I'd concur with this view leaning towards option C, noting that we can always revisit this if it turns out that this just turns the TA disruption into autoconfirmed account disruption. In my experience it's much easier to weed out and halt autoconfirmed accounts than it is to address IP-hopping TAs, so I think it's worth giving it a shot. _signed, Rosguill ^talk 14:59, 20 October 2026 (UTC)

You might want to check my latest RPPs. We'd have to go around dropping an awful lot of blocks. ChompyTheGogoat [ Bleat | Munched ] 15:04, 20 October 2026 (UTC)

I would add on to Rosguill's reply that one also has to consider achieving consensus. My feel for the community -- which may of course be wrong -- would be that going too far, too fast, here would undermine consensus building, even if that ends up what we have to eventually do. LLMs are a much larger problem than cinema of South Asia, but I don't think we'd have as quick success getting the policies closer to where they needed to be without the incremental steps first taken.

If autoconfirmed turns out to not be sufficient to manage this situation -- and I think this is one of the probable outcomes -- with there already being a restriction established and in place, it's not as much of a leap to go to ECR. I think as a principle, you want to try community solutions first; I believe that ethically, we have a responsibility to try to solve these issues as a community ourselves and only escalate it when we have to. That may make resolutions slower, and a bit messier, but I tend to think that the community can be too quick to make things admin/ArbCom headaches when they should be our headaches initially. This is one of the reasons I'm so active at explaining blocks to admins; admins have a toolset to do specific things, it shouldn't necessarily be their responsibility to have to also go into a billion dreary discussions explaining why sources are need or why legal threats are bad and why you can't just start a new account when you're blocked. I don't mean any of this as a dig at you, just explaining why I feel this way. CoffeeCrumbs (talk) 17:35, 20 October 2026 (UTC)

I think having admins designate it under the 6b resolution would be more expedient than running it through RfC, given that there is obviously long term extensive disruption. On the off chance they fail to reach consensus we could fall back on community designation.

And thank you again for initiating this! My mental health appreciates it. ChompyTheGogoat [ Bleat | Munched ] 14:29, 20 October 2026 (UTC)

The 6b provision says Such extensions must be of a limited duration, not to exceed one year. There's no reason to believe this will get any better in one year, so we'd be better off doing it indefinitely by community consensus. Athanelar (talk) 15:41, 20 October 2026 (UTC)

Oops, I missed that part. I think I'd still like to see that enacted for now - I can easily foresee hordes of canvassed SPAs flocking to an RfC and dragging things out for god knows how long. If admins shut down their editing in the area to allow us to start to get a handle on things maybe they'll give up and find better hobbies, so we can tie up the community side to make it permanent. ChompyTheGogoat [ Bleat | Munched ] 15:59, 20 October 2026 (UTC)

RfCs aren't headcounts, they're debates. It doesn't matter how many SPAs participate if their arguments are spurious, the side that wins is supposed to be the side with the better policy-reasoned argument. Athanelar (talk) 16:08, 20 October 2026 (UTC)

I realize that, but they could still drag things out indefinitely. We've seen socking on AfDs in the subject area that can get out of hand. ChompyTheGogoat [ Bleat | Munched ] 16:12, 20 October 2026 (UTC)

I would suggest a fourth option be added here, that being Option C but applied to CT/SA as a whole and not just the topic of Indian cinema. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 06:29, 22 October 2026 (UTC)

For the record, I would support this option. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 06:30, 22 October 2026 (UTC)

FYI - I posted a note at WT:WikiProject Film/Indian cinema task force about this proposal. S0091 (talk) 20:19, 20 October 2026 (UTC)

Support Option C then Option B - Option C would restrict many of the SPI throwaway accounts who operate heavily in that space. However, it would could be a nightmare to enforce and cause more issues than we alrady have. Option B would be my second choice. --CNMall41 (talk) 20:44, 20 October 2026 (UTC)

What part would be hard to enforce? We can slap protection on most articles instead of needing to wait for disruption first and chasing dozens of editors to noticeboards. ChompyTheGogoat [ Bleat | Munched ] 21:11, 20 October 2026 (UTC)

This definitely needs an RFC. The lack of experienced South Asian editors commenting here is a concern as are the derogatory comments about the ICTF from a ten month editor. There should be no rushing into action before a properly run RFC in my view Atlantic306 (talk) 23:27, 20 October 2026 (UTC)

Nobody is rushing into anything. I fully intend to hold an RfC on this once it's had a day or two more for any points of discussion to be raised, for any feedback to be given about the proposed RfC questions and so on. Athanelar (talk) 03:28, 21 October 2026 (UTC)

@Athanelar I am assuming this meant is to include actors, directors, etc. I suggest changing the wording to "The topic of South Asian cinema...." which aligns with the wording for Indian military history. I also suggest an option for AC restriction for the topic area, which would include new articles (like B but for AC). With that option, effectively TAs would not be able to submit drafts and as others have noted, a lot of the disruption is by TAs. Even if it is unlikely to pass, I think it is better to have the option on the table.. S0091 (talk) 15:09, 21 October 2026 (UTC)

It is, yes; N.B., "South Asian cinema, broadly construed" includes films as well as all associated cast and crew including musical directors, musicians and playback singers primarily working in film, and is specifically inclusive of India, Pakistan, Bangladesh and Sri Lanka. I've only specifically named musical staff because they play a much larger role in the culture surrounding Indian cinema than equivalent people do in Western cinema (name a famous movie musical director in the west except Hans Zimmer) and I want to make sure it's explicitly clear that this topic area categorises those people too.

I suggest changing the wording to "The topic of South Asian cinema...." which aligns with the wording for Indian military history. That's what the final wording on the CT page itself would be, but I can make that clearer in the RfC. I'll add an AC option too just to cover bases. Athanelar (talk) 16:21, 21 October 2026 (UTC)

"We can slap protection on most articles instead of needing to wait for disruption first", I like the idea, but "we" cannot. Protection needs applied by an admin and I am unsure how many would be willing to add to the already overwhelming workload. The disruptors will create disambiguations to avoid protection as well which adds to even more SPI work. --CNMall41 (talk) 15:55, 21 October 2026 (UTC)

Another thing to note is UPE socks game WP:AFC/Redirects, usually as a TA, where they request a redirect, an editor approves/creates it, then the socks turn it into an article, sometimes one with an account. That has significantly subsided as editors caught on to what they were doing but if restrictions pass, I expect it will become a problem again. The tricky part is because the redirect is created by an editor in good standing, some admins will not delete them (i.e. G5 which also applies to pages created in violation of restrictions). S0091 (talk) 16:22, 21 October 2026 (UTC)

Well, the regular AfC blocks editors from submitting drafts in an ECR CTOP when they're not EC, so surely AFC/R also rejects redirect requests relating to an ECR CTOP if the requesting editor isn't EC? If not, surely they should? Athanelar (talk) 16:26, 21 October 2026 (UTC)

Not all reviewers will know or they forget. That happens with drafts as as well. I was not aware of AfC had the ability to block an editor from creating/submitting a draft that violates ECR. When was that was implemented? S0091 (talk) 16:40, 21 October 2026 (UTC)

One of the "deny" reasons is because the editor is trying to submit a draft in an ECR CTOP they don't have permission for. If they again try to resubmit it will be rejected for tendentious resubmission. That's the "blockage" I mean. Poor word choice, I suppose, I didn't mean to imply WP:BLOCK. Athanelar (talk) 18:58, 21 October 2026 (UTC)

Thanks Athanelar. I thought that might be what you meant but also thought had AfC developed the ability to prevent editors from violating ECR, that would be something to perhaps leverage. :) Speaking from my own experience as an AfC reviewer, a topic being ECR is not my top thought when reviewing and I am aware of ECR topics. Things will slip by on occasion. S0091 (talk) 19:32, 21 October 2026 (UTC)

Sure, we can't be 100%. That said, if AFC/R is suddenly inundated by a lot of bad requests because of these new restrictions, it'll probably become easier to detect because reviewers will be on the lookout for it. And, after all, if even 1/10 slip through the cracks and result in an article being created, that's still better than the status quo which is anybody with an autoconfirmed account publishing straight to mainspace and everybody else packing the AfC queue full. A bonus to these restrictions I hadn't considered before is we'll probably be able to quick-deny a whole lot of SA cinema articles at AfC, too. Athanelar (talk) 19:42, 21 October 2026 (UTC)

It happens, but many reviewers focus on specific subject areas, so those most likely to review Indian cinema drafts would hopefully be more aware than others, just like they're more aware of active LTAs on the subject. ChompyTheGogoat [ Bleat | Munched ] 19:33, 21 October 2026 (UTC)

And sometimes LLM or sock target pages get through too, then we delete them and politely remind the reviewer to keep an eye out for them. Mistakes happen. That's not a reason to avoid applying preventative restrictions.

Having a good faith editor being the creator of record on request of a sock sounds like a technicality. The situation should just be noted in the G5 so the reviewing admin understands. ChompyTheGogoat [ Bleat | Munched ] 19:22, 21 October 2026 (UTC)

Sometimes? I think both of us can attribute our experience at SPI that "sometimes" actually means "bludgeoning a page to death including creation multiple drafts and pages under disambiguation titles like playing hide the coconut as experienced editors move back to draft and wasting countless hours of enjoyment editing and instead spent it playing whack a mole at SPI and AfD discussions." I get your contention, but "difficult to enforce" is still my contention. It will be difficult to enforce. --CNMall41 (talk) 23:38, 21 October 2026 (UTC)

No harder than it is without CTOP restrictions. If we apply this we can immediately draftify anything that does get through from non-EC accounts without stopping to worry about whether they're socks, and if they try to move it back they can be blocked as an enforcement action without waiting on CU. The area needs more patrolling regardless, but I'm not able to wrap my head around the idea that more protections and easier blocks will somehow make things worse than they are now. I'm very confused by it.

FWIW "sometimes" was specifically referring to AfC reviewers accidentally letting them pass when the socks try to run things through there. I'm not really sure what's up with the recent pattern of trying that first before a unilateral mainspace creation - maybe they think it's less likely to get deleted? Who knows; I don't understand a lot of what they do. ChompyTheGogoat [ Bleat | Munched ] 01:39, 22 October 2026 (UTC)

I not suggesting at all this a reason to not apply restrictions. I am simply noting situations I have encountered so others are aware. G5, at least with Twinkle, does have a way to add an explanation, outside of a sock master or applicable restriction.. If it were a redirect I created via AFC/R, I have done both G5 and G7 to cover both but if another editor created it, G7 is not applicable and those are the ones that might be declined by an admin. This is not something I think it a major issue but something to be aware of. S0091 (talk) 19:51, 21 October 2026 (UTC)

Then shouldn't the reviewers be informed? Katzrockso (talk) 06:59, 22 October 2026 (UTC)

I really wish they'd add a way to include an explanation for all CSDs. I frequently have to submit it as custom so I can explain the situation. ChompyTheGogoat [ Bleat | Munched ] 20:27, 21 October 2026 (UTC)

Well, it's the same as any CTOP. Admins don't need to go through and apply protection to every single cinema article, but they'd be able to way faster and easier if the topic is under ECR/ACR (since at the first sign of trouble on any relevant article an admin can slap the protection on and call it a day) Athanelar (talk) 16:23, 21 October 2026 (UTC)

Sure, they already do that for salted titles, but I'm taking about existing articles that pass notability. It shouldn't be an issue to batch nominate - admins would only need to spend approximately two seconds verifying the articles fall within the subject area. For new pages that pass AfC the request can be applied at move to mainspace. This would be far less work overall than chasing down all the bad edits that will continue to be made against the restriction and having to keep justifying that the disruption is in fact disruptive. The whole proposal would basically amount to nothing because we'd still be applying the same remedies for the same problems. Most of these editors don't care about our rules and will just keep on as long as they're capable of editing the articles. And a lot of them don't leave enough of a trail to track at SPI either. ChompyTheGogoat [ Bleat | Munched ] 19:18, 21 October 2026 (UTC)

Support having an RFC I think any sort of restriction here would be a welcome change. QuicoleJR (talk|edits) 19:22, 21 October 2026 (UTC)

Support having an RFC long overdue given the disruption we have experienced and appreciate Athanelar for starting the discussion. S0091 (talk) 20:17, 21 October 2026 (UTC)

Support RfC Better to have this formalised. —Jéské Couriano v^_^v ^{Thriller Night!} 20:22, 21 October 2026 (UTC)

Agree with others that there should be a formal RfC on this topic. mdm.bla 00:19, 22 October 2026 (UTC)

Could we add to the RfC a specific protocol for handling box office updates? The pushers are getting increasingly desperate on talk pages of articles I've had protected despite our big red notice that no one ever reads. It's unfortunate that the most popular sources are currently not accepted as reliable, which is why I supported the as-yet unsuccessful attempts to re-evaluate all of them without bias. Regardless, to the rest of the world updating the income every five minutes is not high priority. I'd suggest something along the lines of "box office requests must be submitted through a proper edit request with a supporting citation from an acceptable source at WP:ICTFSOURCES or they will be summarily deleted". I guess that might just be seen as updated phrasing of the current notice, and I don't know how we can force anyone to read it. Maybe I'm being too lenient with continuing to try to explain sourcing requirements to people who don't care. ChompyTheGogoat [ Bleat | Munched ] 04:33, 22 October 2026 (UTC)

I would not combine an RfC question about administrative procedures with an RfC question about content. For content questions, I would suggest adding something at WP:ICTFMOS (not the best shortcut as current advice goes beyond MOS) first. If needed, that provides text an RfC can affirm rather than starting from scratch. CMD (talk) 04:56, 22 October 2026 (UTC)

Aside from the sourcing issue (which I'm not sure what else we can do about, if no one has any input) my concern is mostly about how to handle enforcement, because when they can't push their preferred changes the talk pages immediately get bogged down with requests and subsequent arguments. I guess maybe just revisiting it at the task force would be the best first step. ChompyTheGogoat [ Bleat | Munched ] 05:11, 22 October 2026 (UTC)

Note that big red boxes at the top of the page are likely to be absent on mobile browsers. It's why I've put FAQs in the talk page proper for several India related topics (most notably Sushant Singh Rajput and Shivaji). —Jéské Couriano v^_^v ^{Thriller Night!} 15:51, 22 October 2026 (UTC)

I'm not convinced they'd slow down to read those either. Most of them bulldoze past all the other open threads with the same requests. ChompyTheGogoat [ Bleat | Munched ] 17:33, 22 October 2026 (UTC)

Enough would. The goal is more to mitigate, not eliminate. —Jéské Couriano v^_^v ^{Thriller Night!} 17:35, 22 October 2026 (UTC)

I'll try it on a current target page and see if it makes any difference.ChompyTheGogoat [ Bleat | Munched ] 17:43, 22 October 2026 (UTC)

The template does display on mobile for me as long as it's below a section header. Minerva just doesn't like anything above the table of contents. We can certainly make that standard practice if it has any effect. ChompyTheGogoat [ Bleat | Munched ] 17:59, 22 October 2026 (UTC)

Question on the technical side - we can't protect pages that don't exist yet, but could we utilize a maintenance category that would flag page creations by non-EC editors that are placed in relevant categories? Maybe even a bot that could automatically draftify and drop a corresponding ECR notice. Considering the scale of things I think the more we can automate and reduce the workload on enforcers (especially admins), the better. Minimizing new disruption will also leave good faith editors with more time to work on cleaning up existing content. ChompyTheGogoat [ Bleat | Munched ] 07:39, 22 October 2026 (UTC)

Nonexistent pages can absolutely be protected, and routinely are; see WP:SALT. We try to avoid it, though, because editors will often just create the page anyway with a slightly different title. Omphalographer (talk) 20:19, 22 October 2026 (UTC)

I mean ones we aren't aware of yet - brand new creations (as well as title gamed versions). This could potentially flag any creation within the relevant categories, under any title. ChompyTheGogoat [ Bleat | Munched ] 20:23, 22 October 2026 (UTC)

It seems technically possible, assuming WikiProject tags or categories are added to the article a bot could track. I'm not aware of a precedent however. CMD (talk) 22:26, 22 October 2026 (UTC)

I'd be happy to help work out the details with someone more savvy once the RfC clears. We're definitely going to need a structured approach to try to get a handle on things. ChompyTheGogoat [ Bleat | Munched ] 00:43, 23 October 2026 (UTC)

Support 500/30 requirement with Option B per Jéské Couriano. --ABx11 (she/they) 00:35, 23 October 2026 (UTC)