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)

I think that is actually a principled stance to have though. We strive to be an encyclopedia that anybody can edit, and we only put limits on that when it would be infeasible/unreasonable to not do so, not just for the sake of convenience, and we try our best to limit it only to the extent required to prevent disruption. Being supportive of a proposal to let editors one views as trusted to make certain edits be able to make those edits is in line with that. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 13:20, 25 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)

  I concur with @Daniel Quinlan here. I have seen and experienced a rise in vandalism, especially move-related vandalism, from anons as well as newly created and autoconfirmed accounts. I have found that ECP is usually sufficient in countering and preventing such abuse, though often when I do request that for moves or editing in general, it is not implemented in favor of a subpar protection unless there have been multiple egregious offenses. — Trailblazer¹⁰¹🔥 ^{(discuss · contribs)} 04:25, 25 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)

@Daniel Quinlan and Wugapodes: You both hit the nail on the head. Re-reading your comments above made me realize something—this proposal would really just result in a quasi-unbundling of the sysop toolset. However, the framing avoids the traditional ire drawn from true technical unbundling proposals! Convolution should always be avoided; if page movers are so trusted in actuality, then they should be granted the ability to move fully-protected pages. It certainly should not be done in this manner which suffers from all the cruxes which you both so aptly point out. — Godsy ^(TALK_CONT) 04:01, 25 October 2026 (UTC)

Very good point. While I still support the proposal in absence of an alternative, a better direction would be similar to the intended purpose of NPR and PMR. In the same vein that NPR was "unbundled" from the admin tool set, and we now have more non-admin reviewers than admins with full permissions to review pages, PMR should realistically also include permissions for move-protected pages, based on the assessed trust of those who have page mover permissions. In response to Wugapodes however, Page movers who can be trusted with sysop-protected pages should apply for the existing sysop permission [...], I strongly disagree. Most page movers appear to have no interest or demonstrated need for sysop permissions, because their focus is on moving pages, not everything else that comes with the mop and bucket. On this note I'd prefer to see further unbundling of sysop toolkit, such as WP:Page deleter, WP:Page protector, etc, for those who prefer to stick to particular areas of the 'pedia. Moreover, the benefits of further unbundling would be worth the time and effort, like it has been for NPR and PMR already, while I can see the drawbacks of a new protection level. Overall for every permission granted, it can translate to dozens if not thousands of admin-like actions that otherwise wouldn't have occurred. I can't imagine where the project would be without NPR/PMR to be honest, especially given how backlogged NPP usually is on a good month. Also if editors want more admins then the best strategy for that is to create more stepping stones in order to reduce the hurdle of RFA/AELECT. Whereas recommending page movers apply for sysop rights, simply in order to move protected pages, is well intended but thoroughly unrealistic. CNC^{in solidarity} (talk) 09:44, 25 October 2026 (UTC)

I would also like to note that move protection is hardly being applied to mainspace pages because only sysops can be trusted to move them, it's done because there is no other alternative. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 13:10, 25 October 2026 (UTC)

Moving full protected pages is a demonstrated need, and page movers are great admin candidates. Page movers have been trusted with limited delete permissions since 2021. They also show demonstrated experience in reviewing contentious discussions for consensus and can follow admin-level policy documents well. If a page mover only uses the tools to move pages we're better for it, and if they use the rest of the kit to improve the encyclopedia, even better. The tools are a way to serve your corner of the encyclopedia, not leave it.

That said, I don't think generally unbundling the core block-protect-delete tools is a good idea either. Dealing with disruption requires all three in your toolbox. For example, socks should usually be range blocked as a first resort rather than have the page protected and revision deletion can be important for cleaning up afterward. If we give some people block and some people protect and some people delete, then at best we will still need to wait for someone with the proper tools and at worst we will use the wrong tool for the job. Personally, I think one of our biggest AntiPatterns is that we spend hundreds of person-hours debating new permissions, coding new permissions, writing policies for permissions, processing requests for permissions, and monitoring use of permissions so that our most responsible editors can build an inferior toolkit request by request. At a certain point we need to kindly but firmly say, if someone wants to serve the community with further tools they need to stop making work for others and just get the whole toolbox. — Wug·a·po·des 02:39, 26 October 2026 (UTC)

@Wugapodes: I agree. Just want to clarify that while I think granting page movers the ability to move fully-protected pages is a better idea than what is being proposed here, it still is not something I would support. — Godsy ^(TALK_CONT) 02:54, 26 October 2026 (UTC)

Do you think someone would pass RFA or AELECT if the only reason they are running is to supplement their ability to move pages? I suspect at best, it would be a very hard sell. Skarmory (talk • contribs) 02:56, 26 October 2026 (UTC)

Probably not, but most extended movers work in multiple areas, and the most trusted ones would benefit from the additional permissions that are entrusted to sysops. Daniel Quinlan (talk) 03:04, 26 October 2026 (UTC)

"I want to move pages and I might help with other stuff" was my answer to Q1 and it worked fine. — Wug·a·po·des 03:26, 26 October 2026 (UTC)

• Comment: Another use case for this protection is the current WP:TWAFI. Given that it has been proposed for renaming several times already in its first week on the main page, the mover-protection can ensure that the result of any RM can be enacted quickly (so that editors won't ask why the page was closed as "moved" but never actually moved) while ensuring that even EC editors can't come in and "boldly" move an article that is on the main page after being vetted by the AFI team. FaviFake (talk) 22:22, 24 October 2026 (UTC)

  I believe extended confirmed move protection will be sufficient for most if not all of these articles. If full move protection becomes necessary on an article, and there's consensus to move the article, and the consensus is reached before the full move protection expires, someone can make a request at WP:RM/T and it will be dealt with quickly. Daniel Quinlan (talk) 18:03, 27 October 2026 (UTC)

  A few hours isn't really "quick" for a TWAFI. FaviFake (talk) 18:08, 27 October 2026 (UTC)

  Given the number of administrators involved in TWAFI, watching the current and recent TWAFI articles, and handling requests related to the article, a wait of a few hours is not likely. Daniel Quinlan (talk) 18:26, 27 October 2026 (UTC)

Discussion (mover protection)

Survey (Indian cinema CTOP)

"Anchor" comment placed at the top for the purpose of giving editors something to hit "Reply" on.–Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 14:28, 26 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)

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 (Option B) 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)

I also support D if there's a consensus. At this moment, doing anything is, in my eyes, better than A, which is nothing more than sitting back and waiting until the garbage is so high that there's no volunteer army large enough to empty the landfill. CoffeeCrumbs (talk) 01:56, 26 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)

This is a big reason as to why I don't agree with the two-tiered approach. I knew caste was a significant factor here, but I wasn't aware of just how much of one it was. —Jéské Couriano v^_^v ^{Thriller Night!} 16:47, 24 October 2026 (UTC)

Did not know that. Given that, this should probably be extended confirmed so I'm changing my vote to a mixture of Option D and Option C, with ECR for cinema and ACR for CT/SA in general. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:04, 25 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)
• Strongly oppose ECR ECR should be reserved for the worst of the worst topic areas. Movies may get a lot of passionate editors, but that's because movies are a universal experience. We all watch lots of movies and care strongly about them. Editing movies is a way that many editors come to Wikipedia. We'd be cutting off a significant avenue of recruitment for Indian editors by saying that only experienced editors can work in the topic. I have always worried that ECR would be extended into topics that truly don't need it, and this is a clear example. Movies have nothing on something like Israel-Palestine. I express no opinion on the other aspects, I just would hate to see ECR expand to...movies. CaptainEek ^{Edits Ho Cap'n!}⚓ 02:58, 25 October 2026 (UTC)

  STRONG Oppose ECR, status quo we should not lock down everything and should leave ECR as option of last resort; it is a failure of all other systems and breaks wikipedias ethos of the encyclopedia anyone can edit, if only to protect in worst case areas. Eek is right, if there is need for this let arbcom do it. User:Bluethricecreamman (Talk·Contribs) 03:08, 25 October 2026 (UTC)

  It's reductive to boil this down to just "movies." Like I've said, this is a hugely identitarian thing that intersects inextricably with caste, religion and culture in a way completely alien to the western film world. Athanelar (talk) 00:13, 26 October 2026 (UTC)

  I don't buy that. Western cinema is just as full of propaganda/religion/culture, westerners just have a blind spot for their own media. If you've ever watched a twitter debate between movie dudes, its not very different. We're exoticizing Indian cinema and telling hundreds of millions of Indians that they're too passionate about their culture, so only the staid and sensible (and mostly Western) experienced Wikipedians can interpret their culture for them. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:37, 28 October 2026 (UTC)

  Rest assured I am not speaking from an entirely outside perspective here. I know a thing or two about a thing or two; South Indian cinema particularly, but the same issues abound all over. I really encourage you to read the other comment I posted here, if you ctrl+f "kapu" you'll find it. It really is nothing like anything that exists in Western cinema. Everyone knows Tom Cruise is a Scientologist, right? Now imagine like 80% of the USA are scientologists and slavishly devoted to watching Tom Cruise movies, and you're approaching the ballpark. Tollywood has a term, "TFI banisa", for its superfans. It literally means "Telugu Film Industry slave". I haven't heard any major subsection of the filmgoing western population calling themselves "Hollywood slaves". Imagine an entire cinema full of people screaming and hooting and throwing confetti at the screen because Tom Cruise or whoever their favourite action star is came on the screen. "Jai Balayya!" is something of a cultural catchphrase, meaning "Hail Balayya!" or something to that effect. Balayya of course being a major Telugu actor. Again, imagine if you could shout "Hail Tom Cruise!" in a public place and have at least a few people shout it back without hesitation.

  Granted, the Telugus are about the mos extreme end of this spectrum, but it really, really is not the same in Western cinema. Athanelar (talk) 19:50, 28 October 2026 (UTC)

  @Athanelar Could you please clarify your last sentence? ... I don't think many editors here are going to find creating a CTOP because the Telugus are about the mos[sic] extreme excessively convincing. To put it mildly.GreenLipstickLesbian💌🧸 20:17, 28 October 2026 (UTC)

  I mean that as far as South Asian cinema superfans go the Telugus are probably the most extreme of the bunch, but that it also exists elsewhere, again c.f. Dhurandar. I just can't speak from a position of as much knowledge about other regional cinema industries because the Telugu industry is what I know best. Athanelar (talk) 20:32, 28 October 2026 (UTC)

  Okay, let me rephrase: your comment is coming across as quite dismissive of an entire ethnic group. Could you please rephrase? GreenLipstickLesbian💌🧸 20:36, 28 October 2026 (UTC)

  The fact that Telugu cinema fans are among the most devout and passionate is not an insult to them. Again, see "TFI banisa" above. The reason I said that is because I know a lot about the Telugu film industry and its fans and not as much about other South Asian regional industries, and I didn't want to imply that this same fan culture extends to Tamil cinema or Malayalam cinema or anywhere beyond, because I don't know if it does. I was defining the scope of my knowledge, not making a dig at the Telugus. Besides, I'm not sure how "Telugus are amongst the most extreme [cinema fans]" is any more disparaging to Telugus than Eek's statement Americans are overwhelmingly patriotic is to Americans. Also, to quote myself above, Rest assured I am not speaking from an entirely outside perspective here. Athanelar (talk) 20:47, 28 October 2026 (UTC)

• I still don't buy that that is substantially different than "Guy who has seen all 38 Marvel movies" or "audience that claps at the end of a movie" or "screaming Beatles fans." Americans are overwhelmingly patriotic and turn out in mass droves to watch, funnily enough, Tom Cruise flavored military propaganda like Top Gun: Maverick. Indians being hype about home-grown cinema isn't surprising. Super fans are universal. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:22, 28 October 2026 (UTC)

  And it's certainly not unusual if you compare it to, say, American sports culture (I am an Eagles fan -- we are notoriously violent. Let alone throwing confetti at a screen, we'll throw projectiles at living people.) GreenLipstickLesbian💌🧸 20:29, 28 October 2026 (UTC)

  Sure, and if an argument could be made that American sports fanaticism was leading to a lot of UPE and general disruption on Wikipedia then there would probably be a case for a CTOP there. We do after all have a CCTOP on pro wrestling (albeit not ECR) due to the same sort of thing.

  The thing is, we probably wouldn't need any specific restrictions in this topic area if we instead had an abundance of editors doing cleanup and making reports for normal AE actions under the CT/SA area. But I think what Sennecaster (I think it was them?) has pointed out about the lack of South Asian cinema-related arbitration reports is a good example of a sort of survivorship bias. We don't see a lot of arbitration reports not because it's not a contentious area, but because there's not a lot of people knowledgeable enough/willing enough to do the required enforcement. Athanelar (talk) 20:38, 28 October 2026 (UTC)

  And there are still other cultures that take sports culture much farther, which American fans are often unaware of, because people here can't see past the end of their own nose. ChompyTheGogoat [ Bleat | Munched ] 21:33, 28 October 2026 (UTC)

  Right. Eagles fans are "notoriously violent" for throwing things. Ultras of Glasgow Rangers and Glasgow Celtic are "notoriously violent" because they regularly stab each other when their teams play. Athanelar (talk) 21:44, 28 October 2026 (UTC)

  Eek, given the connexions between Indian cinema - not just the actual films themselves, but the entire industry - and caste (the latter of which you know is a perennial powderkeg looking for a lit fuze and is partly responsible for the Indian milhist 500/30) the question is less "Should we institute 500/30?" and more "Are we going to be forced to institute 500/30?" One way or another, I see Indian cinema being put under XCR for the exact same reasons as Indian milhist. —Jéské Couriano v^_^v ^{Thriller Night!} 17:01, 26 October 2026 (UTC)

  If I were assembling a "how much does it matter that this article is accurate in the real world" tier list, MILHIST articles are A tier in importance, and movies--no disrespect to them--are C or D tier. Movie pages are very popular, and a good way to recruit new users. By shutting out the problem editors, we shut out good editors too. Movies just aren't that important to warrant cutting out such a big portion of our potential editor base. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:46, 28 October 2026 (UTC)

  See my comment below. I would contend that it's the exact opposite and it's not worth dealing with swarms of UPE/COI for the very small number of good faith editors who might make valuable contributions. It's really not the same as Western film - as Jeske said, almost all of them either have a conflict of interest or are true believers. The vast majority are SPAs with no interest in any editing beyond pushing their POV on these articles, regardless of whether they're getting paid for it. They are not improving the project as a whole. ChompyTheGogoat [ Bleat | Munched ] 21:48, 28 October 2026 (UTC)

• Option C preferred. Option B is fine but this should then be revisited to tell if Option C is warranted. As already discussed by Athanelar and other, the caste issue is inextricable to this topic area and warrants the same treatment as the other topic areas. Οἶδα (talk) 22:05, 25 October 2026 (UTC)
• Comment I've added this RFC to T:CENT. QuicoleJR (talk|edits) 22:43, 25 October 2026 (UTC)
• Option A To be quite honest, a restriction this wide on a very active topic area is going to be nigh-impossible to enforce. Yes, there is a lot of UPE editing happening in this very broad area. Yes, there is also a lot of bad editing in this very broad area with new editors not familiar with our policies (or not caring about those policies). Yes, this is a lot of socking in this area that just don't care about Wikipedia policies, they just want their own way. I don't think the other proposals are actually viable. There would be lots and lots and lots of requests for blocks, protections, huge numbers of edit requests that will get ignored for far too long. Ravensfire (talk) 22:52, 25 October 2026 (UTC)

  @Ravensfire: While I haven't yet made up my own mind about this proposal (I find both Athanelar and CaptainEek to have persuasive arguments) I would like to note that this rationale could have been used to oppose implementing ECR on Israel/Palestine as well. There were lots of protections requested when that was implemented, but the admins were able to manage it. QuicoleJR (talk|edits) 23:04, 25 October 2026 (UTC)

  I think that in terms of the sheer number of articles that exist, this would vastly exceed the number for Israel/Palestine. The number of new articles that get created on a weekly basis is absolutely going to be more than exist in the IP area. Indian films, actors, actresses, directors, producers, music folks. Pakistan films, actors, actresses, directors, producers, music folks. Bangladesh. Television equivalents of all of that. This area is going to be absolutely massive. Ravensfire (talk) 23:40, 25 October 2026 (UTC)

  And ECR would quash a lot of that. It's easy to just draftify anything created by non-EC editors - no deeper analysis required. If they keep trying to move back they get blocked. It would take time to work through the backlog, but it's certainly doable. EC editors following protocols can request protection out of the gate so their articles don't devolve. I don't consider "the problem is too big so we should let it continue being a problem" to be as viable argument. ChompyTheGogoat [ Bleat | Munched ] 07:05, 28 October 2026 (UTC)

  The number of articles is something we can estimate. Athanelar, do you have any guesses off hand? Wikipedia:WikiProject Film/Indian cinema task force#Tagging and assessment says 55,000 articles. WhatamIdoing (talk) 04:47, 30 October 2026 (UTC)

  @WhatamIdoing That 55k includes nonarticles (eg tagging files) and I think it's closer to 31k articles. There is also a Wikipedia:WikiProject Indian cinema but the two have a lot of overlap. On the other hand for whatever reason there are not many biographies tagged by either, so it would add I estimate another 10k. Allowing for a bit of undertagging and some other related articles, say 40-45k and growing at 3-5 articles per day.

  It would not be our broadest contentious topic (that will always be BLPs) but it would be our largest under ECP, I think. Andrew Gray (talk) 09:14, 30 October 2026 (UTC)

  For what it's worth, some petscans:

  • Articles in Category:Indian cinema task force articles are 32,000+
  • Articles tagged with both {{WikiProject India}} and {{WikiProject Film}} are 28,000+
  • Articles in both categories Category:India and Category:Film are 49,000+ to a depth of 5 sub-cats or 20,000+ to a depth of 4 sub-cats.

  SunloungerFrog (talk) 09:42, 30 October 2026 (UTC)

• Support D->C->B in that order of preference, Oppose A. We should try the least restrictive thing first and see if that works before trying more restrictive options, but let's try something rather than doing nothing. Levivich (talk) 00:18, 26 October 2026 (UTC)
• First choice D, second choice A: ACR currently does not exist, but is intriguing (currently, WP:ACR points to Wikipedia:Your first article). I oppose ECR per CaptainEek unless and until it becomes clear that a less draconian restriction does not work. mdm.bla 00:35, 26 October 2026 (UTC)

  User:Mdm.Bla, we have something extremely similar to an autoconfirmed restriction in the form of the aggressive semi-protection allowed in WP:GS/PAGEANTS. If a single logged out editor edits a beauty pageant-related page it gets semi'd indefinitely. There's a pretty strong BLP aspect there (especially relating to children) that fuelled it, I believe, although it was adopted before I began editing. Sennecaster (Chat) 17:17, 27 October 2026 (UTC)

  Thanks, I didn't know about that! mdm.bla 04:58, 28 October 2026 (UTC)

• Option C, Option D as second choice, with the understanding that the concern raised over WP:G5 under Option C (if an article is created in violation of the sanction and then receives significant contributions by autoconfirmed editors post-creation) would be enforced by only considering if there has been post-creation significant contributions by EC editors (otherwise you could just game your way past the restriction). The fact that it is unprecedented doesn't mean much to me since it is essentially just a remix of restrictions that we do already use, rather than some wholly new concept.

I hesitate to go for ECR without having tried something less hefty first. As it means only a tiny handful of readers can edit an article, it should only be used in cases where it is unfeasible to allow articles to go without it. This does appear to be true for certain kinds of Indian cinema articles, but to place the whole of Indian cinema under ECR should require that the whole of Indian cinema needs to be under ECR. I do not think that's been established here. ECR can be applied to those kinds of Indian cinema articles where it seems necessary as part of the WP:STANDARDSET, but for Indian cinema as a whole we should try to go with a lesser restriction first. If that doesn't work we can revisit the matter. –Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 14:14, 26 October 2026 (UTC)

• Option A first choice, D second choice (but see below). Oppose B and C as too heavy-handed. From my experience in RCP and NPP, the problem of disruptive editing and spam in the South Asian film industry area is no worse than that in South Asian (non-film) biographies, companies, politics, sports, etc.; and likewise caste is as intertwined with South Asian cinema as it is with virtually any other topic under CT/SA. (Which is, well, a complex topic and I could write plenty about it; but there's no point in typing out a lengthy essay on that here.)

As such I don't see why South Asian cinema should be specifically singled out for ECR or an autoconfirmed restriction since the arguments used above to justify such a restriction would apply equally well to any other CT/SA subtopic. I wouldn't necessarily be opposed to a blanket autoconfirmed editing restriction on all of CT/SA (though in my experience from RCP this restriction feels a little too severe), but this is not what the RfC is about. ECR wouldn't deal with the UPE problems since most of the organised paid editing syndicates operate accounts with XC anyways, and the non-XC paid editors generally produce blatant spam that can be dealt with without needing anything from the CTOP toolkit. The other disruption for the most part can be dealt with using tools already available under the standard sysop and CTOP toolkits.

I think that a blanket autoconfirmed restriction on South Asian cinema would have more benefits than drawbacks, but it comes off as too broad in scope to me since most of the disruption (as I see it from my experience in RCP and NPP) seems to focus on new or "hot" films (and their crew); famous or controversial films, personalities, etc.; and topics already clearly under the caste and milhist ECRs. Most (>80% I guess) pages in the area get very few edits and don't need protection. A narrower scope for option D which applies only to (for instance) films released in the last 365 days and their crew would be fine with me. JavaHurricane 17:02, 26 October 2026 (UTC)

• Option A first choice, D second choice. South Asia movie/music scene is too large to have such tight restrictions. Many new editors from the region may be interested in editing the movies, and imposing a 500/30 restriction would be too harsh for them, killing the incentives to be an editor. In my opinion, South Asia move scene is less controversial and explosive when compared to other contentious topics such as the Israel/Palestine issues, and we still have WP:CT/SA to if manners escalate to nationalism or caste issues. If the goal is to prevent LLM-made article, that job is for the WP:NPP instead of creating another restriction. We can also try to narrow the scope of the restriction - maybe only restrict movies that have racist/caste issues undertones? ✠ SunDawn ✠ Contact me! 17:30, 26 October 2026 (UTC)

  A large number of those "new editors" are UPE (who may not actually be new), and the vast majority never contribute in any other subject areas. TAs and SPAs abound. Getting drawn into editing in general and becoming a constructive editor who follows P&Gs is exceedingly rare. I've advised others who at least attempt to comply to try editing elsewhere to gain experience and reach EC, and it falls on deaf ears. They don't care about anything else. ChompyTheGogoat [ Bleat | Munched ] 05:17, 28 October 2026 (UTC)

• Option A per Java Hurricane and SunDawn. Bad faith editors can easily game EC and AC, so the people most affected by these editing restrictions are potential new editors, the very group the community keeps saying that we need more of. Some1 (talk) 03:00, 27 October 2026 (UTC)
• Option A for now. I'm open to ideas about restricting article creation in parts of WP:CT/SA bc of high rates of LLM/UPE/socking, but I am unconvinced by the AC editing restriction, especially for South Asian cinema, which likely has way more good faith editors than other subtopics like South Asian incorporated entities (businesses, schools, etc.) NicheSports (talk) 18:30, 27 October 2026 (UTC)

I support an ECR article creation restriction, but oppose any general restriction on editing. South Asian films are a hugely popular area for casual editors and are some of our most viewed articles. A general autoconfirmed restriction would lock out huge numbers of casual editors, while doing little to prevent the determined abuse and sockpuppetry these proposals are aimed at. OTOH, an ECR restriction on new article creation may have an impact on the widespread promotional/UPE sockpuppetry focused on boosting non-notable actors, films, and other topics in this area, while having minimal impact on casual editors interested in what they're seeing in the cinema or in the news. Toadspike [Talk] 01:45, 28 October 2026 (UTC)

• 'Status quo, strongly oppose putting the area under an ECR restriction; our top-viewed and edited articles on the website are often South Asian-cinema related. If we're going to block off casual and new editors from incredibly popular topics, there needs to be a good reason. The editing around most entertainment topics, especially fandom related, is pretty universally shit -- and I spend enough time cleaning up after UPEs and awful editors in the film world to know that the South Asian topic area isn't actually that worse than, say, the American or European industries. GreenLipstickLesbian💌🧸 06:40, 28 October 2026 (UTC)

  But the latter are actually policed. They don't make any headway. ChompyTheGogoat [ Bleat | Munched ] 07:06, 28 October 2026 (UTC)

  LMFAO no. Sorry, but.... no. They are not policed effectively. GreenLipstickLesbian💌🧸 07:13, 28 October 2026 (UTC)

  Sorry if that came off a bit sharp, but I've removed too many decades old press releases copy-pasted in to articles by administrators to do anything other than laugh at the idea that this is effectively moderated. GreenLipstickLesbian💌🧸 07:17, 28 October 2026 (UTC)

  It is in relation to the topic area under discussion. You saw the problem and removed it, because you are part of that moderation. Indian cinema has minimal enforcement of any kind. ChompyTheGogoat [ Bleat | Munched ] 07:26, 28 October 2026 (UTC)

  By that standard, we'll only know in 10 to 15 years whether or not the moderation is the same. GreenLipstickLesbian💌🧸 07:50, 28 October 2026 (UTC)

  Huh? The topic has already existed for years and gone largely unmonitored. It won't take long to see whether or not restrictions start having an impact on new additions. Heck, even working RCP it ought to be noticeable once enough protections are applied that they start popping up less often via the various tools. Newer articles won't have pages of edits by TAs and redlink users with zero edit summaries that make it difficult to even track down where the problems are.

  I've never pulled up an article for a Western show/movie and immediately thought "Wow, this is barely even intelligible". Some of them certainly need improvement and yes, there can be sourcing issues, but it's just not on the same level. Even Fandom insertions are better quality. Can you imagine a recent Hollywood blockbuster with entire sections totally unsourced? (Casting is hardly ever sourced, so there's no easy way to check whether an addition is legitimate or a UPE trying to claim a false credit for their client.)

  Old articles being allowed to languish in a subpar state isn't unusual in any subject area, and not the main issue here. No one will ever get around to working on those when newer ones are so rife with bad edits. ChompyTheGogoat [ Bleat | Munched ] 09:31, 28 October 2026 (UTC)

  You're telling me I'm "part of that moderation" because I'm removing ancient issues which slipped past RCP because admins added it; I'm going to say that, if you're judging whether or not moderation of an area is successful by whether issues survive over two decades, by the metric you set for me and Western shows, we're going to have to wait a very long while to see if this works.

  I am afraid I have to disagree with you on your second point too I spend most of my time looking at old articles in subpar states; I can safely say that, speaking from experience, entertainment articles are, across the board, much worse than any other group. They get a flurry of edits when the show or movie first comes out, from fans and PR people alike, then they sit in that state forever. Sometimes fans hang out and add fancruft, copied from fandom (which was copied directly from the marketing department and laundered through Fandom half the time so, no, not better than UPE in any meaningful way.) No industry is unique for that -- Kdramas, Masala films, MCU blockbusters. Don't believe me? check my edit history. Or, do as you suggested and spend some time actually working cleanup in this subject area to see just how extensive the problem is. GreenLipstickLesbian💌🧸 10:19, 28 October 2026 (UTC)

  I will not be working any areas ever because my contributions don't appear to be welcome on Wikipedia. But what your describing isn't remotely close to the issues in the Indian cinema subject area. At all. The fact that fandom content is still better than many of these despite how problematic it is was my point. ChompyTheGogoat [ Bleat | Munched ] 11:10, 28 October 2026 (UTC)

  No, Fandom content is not better -- if anything, I've found it's much, much, much harder to clean up because, again, the spam has been laundered and divorced from many of the obvious flags that RCPs like yourself check for when spam hunting. But I'm afraid we'll have to agree to disagree -- funnily enough, I checked the date your account was registered, and I was actually working on cleaning up my favourite spammy Manipuri film industry sock farm that very same week. I'm not big on metaphors, but I think this is the equivalent of teaching your... well, not grandmother, so let's just say your big sister to suck eggs. GreenLipstickLesbian💌🧸 11:58, 28 October 2026 (UTC)

  Would you two mind if I move this conversation under the "Discussion" heading? It's a bit lengthy and tangential for the survey section. Athanelar (talk) 12:06, 28 October 2026 (UTC)

• Option B as first choice. Descending options C->D after that. Every time I see anything on an Indian film on this project it's either because there's an edit war over box office figures or it's because there's an edit war over its interface with Indian politics. I think we need to treat this as an integral part of a contentious topic and keep it as locked down to responsible editors as possible. We should also consider excluding box office figures from infoboxes as a matter of policy (not just for Indian cinema) and only discussing box office figures when such are well sourced and encyclopedically relevant. Simonm223 (talk) 11:30, 28 October 2026 (UTC)

  I would happily ban all box office stats unless mentioned in depth in reliable sources, across all cinema -- even in this topic area, the sources the regulars revert to (Bollywood Hungama) are not particularly better than the ones they revert out with a high degree of aggression and warnings (Sacnilk, and every source which sites it). Like the victor parameter in the infobox conflict, it just causes more strife and edit warring than good editing. GreenLipstickLesbian💌🧸 12:02, 28 October 2026 (UTC)

  Wildcard, devil's advocate proposal (and sorry if this is already what you mean by this!): we could just ban box office figures in general unless it's a significant part of the notability and discussion surrounding the film (like Avatar's remarkable box office success), since otherwise it's really not important to an encyclopedia, right? This'd have to be a separate discussion, but I think I'd probably be in favour of a moratorium on box office figures in film articles. Athanelar (talk) 12:09, 28 October 2026 (UTC)

  I'd support that in theory, but it's only viable if we do achieve ECR. Otherwise it's easier to allow them from accepted sources than spend even more time fighting all insertions instead of just the ones that aren't adequately supported, which is hard enough. People get pissed when I get protection on an article and they can't continue to update it every five minutes. And @GreenLipstickLesbian as I've already mentioned we've attempted to initiate reviews of the different sources to no avail. I agree that BH doesn't seem particularly more reliable than others to me based on what I've read and I asked for them to be objectively evaluated based on firm criteria rather than just vibes, but until and unless that occurred I followed established consensus, as do the others monitoring those articles. So once again, the lack of input from experienced editors without bias is the underlying problem. (I think I'm the only one who's actually gone through and read the previous discussions leading to the current designations, and they do not inspire confidence.) ChompyTheGogoat [ Bleat | Munched ] 22:03, 28 October 2026 (UTC)

  This is part of why I want to put ECR on this - I think restricting access to editors who have been around long enough to, in theory, have learned "don't put box office figures in an infobox" is needed to prevent edit wars over box office figures. Simonm223 (talk) 12:19, 29 October 2026 (UTC)

I would somewhat oppose full ECR restrictions ; I believe that should be reserved for the most controversial topics when truly necessary. While South Asian cinema definitely has ties to the restricted topic; I doubt that it belongs at the same severity. So I would support C or D. There are a few autoconfirmed users who cause trouble, so I can understand the B position; but I'm not sure if it's enough to warrant it. Dawn Lim (talk) 11:38, 28 October 2026 (UTC)

• Option A have seen no evidence that Indian cinema is so far worse than the rest of CT/SA that additional restrictions are warranted. ~~ AirshipJungleman29 (talk) 12:19, 28 October 2026 (UTC)
• Support B > C > D. This is a very UPE spam and copyvio prone topic, so much so it's as if an entire cohort of editors doesn't know what a good article looks like. I consider the entire topic a no-go area. MER-C 19:20, 28 October 2026 (UTC)
• Option B - This topic sees the most disruption, sockfarms and UPE in CT/SA. It should be placed under ECR. Zalaraz (talk) 00:56, 29 October 2026 (UTC)

Discussion (Indian cinema CTOP)