Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion process.

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• This is a high-visibility page intended for proposals with significant impact. Proposals that affect only a single page or small group of pages should be held at a corresponding talk page. Please do not post large RFCs here, but please do post brief, neutral notifications of important proposals here.
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation can be held at Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for 7 days.

« Archives, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233

Page mover–specific move protection

Should a new move protection level be created, which only allows page movers and administrators to move pages affected by it? 05:31, 29 September 2026 (UTC)

Survey (mover protection)

Tracked in Phabricator
Task T439172

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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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 ^{ᚾparleyinvestigateᛅ} 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)

• Oppose per above. Izno (talk) 04:37, 5 November 2026 (UTC)

Discussion (mover protection)

Name

(Starting a separate section for this.) If this was implemented, what would it be called? Would it be called "move protection", and the sysop protection called something like "full move protection"? Or would it possibly be a level-2/level-2 thing? Input would be appreciated, especially if this became an RfC or something. Axolitl (talk | contribs) 22:20, 26 September 2026 (UTC)

Since page mover is already called extendedmover it would go that this would be called extendedmove technically; we can rename sysop move protection to you your suggestion, or just deprecate standalone "sysop move protection" as a concept entirely (we don't call fully protected pages "move protected") msk 22:28, 26 September 2026 (UTC)

"Mover-protected"? "Page mover–protected"? "Intermediate move protection"? FaviFake (talk) 00:05, 28 September 2026 (UTC)

I would probably name the sysop level full move protection and let this one be move protection. Skarmory (talk • contribs) 23:29, 28 September 2026 (UTC)

Surely "Move protection" and "Full move protection" are the simplest options here. –Maltazarian ^{ᚾparleyinvestigateᛅ} 05:12, 29 September 2026 (UTC)

@Maltazarian Skarmory "Move protection" usually refers to pages that can only be moved by extended-confirmed users. See {{Protection table}}. FaviFake (talk) 07:24, 29 September 2026 (UTC)

I feel like common usage is already for "move protection" to refer to the green lock. Like, sure, technically an ECP page is move protected at an ECP level, but I can't recall hearing anybody talk about it that way.

I'd suggest "extended move protection" as msk did, but then we're causing confusion due to EC not having anything to do with it.

Idk this part isn't all that important to me anyway. –Maltazarian ^{ᚾparleyinvestigateᛅ} 08:24, 29 September 2026 (UTC)

Yeah it's tricky. For now my preference is for "mover protection"; pages will be "mover-protected" FaviFake (talk) 08:28, 29 September 2026 (UTC)

Impact

Looking at the past month of requests at WP:RMTR, I see just seven:

1. Template:Abbr to Template:Abbreviation
2. Lion-man to Lion-man of Hohlenstein-Stadel
3. Pakistani missile research and development program to Pakistani missile research and development programme
4. MV Höegh Osaka to Höegh Osaka
5. Template:RFPP to Template:Requests for page protection
6. Palm Beach International Airport to President Donald J. Trump International Airport

The seventh I cant list. Overall, maybe there will be one hundred moves per year that will be done by page movers instead of admins; I'm not convinced that this labor saving is worth the cost in development time. (I'll add support for RMTR into Move+ some time, which should reduce the labor cost further - I'll also in the nearer future change RM to say whether it is listing a move in the admin section or the standard section, to make it easier to review this in the future) BilledMammal (talk) 03:52, 29 September 2026 (UTC)

I wonder how many times per month template-protected pages are edited by template editors, as a point of comparison. Snowmanonahoe (talk · contribs · typos) 05:14, 29 September 2026 (UTC)

Moves of move protected pages, and edits of template edit protected pages, by month for the past three years:

Month	Moves	Edits
September 2026	24	2781
August 2026	40	3540
July 2026	31	3685
June 2026	30	3260
May 2026	21	2950
April 2026	32	3315
March 2026	71	3205
February 2026	48	2748
January 2026	47	3288
December 2025	87	3197
November 2025	31	3285
October 2025	13	4094
September 2025	37	3439
August 2025	30	3975
July 2025	54	3057
June 2025	38	2867
May 2025	41	3453
April 2025	28	2575
March 2025	32	3125
February 2025	41	3108
January 2025	77	3865
December 2024	23	3051
November 2024	40	2873
October 2024	22	3430
September 2024	45	3065
August 2024	101	3112
July 2024	65	3105
June 2024	26	2834
May 2024	61	2946
April 2024	35	2860
March 2024	43	3442
February 2024	13	3257
January 2024	29	3304
December 2023	30	3196
November 2023	16	2707
October 2023	36	3149

BilledMammal (talk) 05:32, 29 September 2026 (UTC)

Updated the table. The earlier one was moves of all move-protected pages, included extended-move protected. This one is still a bit of an estimate, as it assumes that if a page is protected now it was protected when the move occurred, so it can miss some moves where protected lapsed or was removed, and counts moves of pages later protected. For example, six moves from March are of Epstein files, none of which was done while the page was protected. BilledMammal (talk) 05:56, 29 September 2026 (UTC)

How hard to we really expect it to be to implement? Anyone got an idea? Also Move+ already has RM/TR capabilities last I checked. Did the recent update get rid of them? –Maltazarian ^{ᚾparleyinvestigateᛅ} 05:15, 29 September 2026 (UTC)

Move+ lists moves at RMTR, it's never supported (outside of a prototype I wrote two years ago) implementing the moves at RMTR. BilledMammal (talk) 05:19, 29 September 2026 (UTC)

Ah, I see. My misunderstanding. –Maltazarian ^{ᚾparleyinvestigateᛅ} 05:20, 29 September 2026 (UTC)

50 to 100 moves per year adds up over time, and this project is already over 25 years old. Meanwhile, we have someone volunteering to make the patch, who also happens to be the person who started this discussion, so that cuts down on the needed development time. This doesn't even account for other possibilities for how the protection level could be used; notably, I agree with EggRoll97 above that this would make sense as the standard for protection in case of move wars. Skarmory (talk • contribs) 05:16, 29 September 2026 (UTC)

Sourcing tools preceding / following AfD nominations

Hi everyone. We're all aware that one of the key issues driving nominations at AfD is a lack of proper sourcing on proposed articles. People aren't wrong that it's unlikely many of these pages will be worked on for a long while, which may lead to some resentment of Keep voters willing to salvage an article on notability grounds, but not to help improve the article thereafter.

With that in mind, I'm curious if we might benefit from something akin to the editing interface Refideas notice, at least for some time after an AfD nomination on sourcing grounds, to indicate to editors that come across the page that there are in fact sources available that were raised in the discussion to support what is otherwise unclear notability. Obviously this could be done just as well using Refideas, but doing so is functionally more difficult and not always possible given template restrictions. I'm curious what others have to say. CSGinger14 (talk) 21:53, 14 October 2026 (UTC)

People aren't wrong that it's unlikely many of these pages will be worked on for a long while, which may lead to some resentment of Keep voters willing to salvage an article on notability grounds, but not to help improve the article thereafter.

I would say any such resentment or... really anything would be invalid and silly. AFD is notability gauntlet broadly when deleting is up as a question. If WP:GNG is proven, or one of the sideways Notability gauntlets that are black and white objective ("You pass GNG if you have earned X, Y or Z"), then any Admin honestly doing anything but Keep is being wrong or acting on emotion versus policy.

The best long term solution would be to something that imports all the URLs/sources at least to the talk page in a non-archive bot eligible section up top. Articles can be stubs. Stubs are fine. Something could trivially pass WP:GNG and be a stub for 20 years. That's fine too.

Look at Amrom Harry Katz and how I found it here at this version: https://en.wikipedia.org/w/index.php?title=Amrom_Harry_Katz&oldid=1240112565

If that was sent to AFD back a year or three ago, it's very possible it dies as an article and I do not find it. It took me substantial effort to dig out and find a lot of that sourcing. Our biggest AFD cultural fuck up is simply not having something trawl AfDs for sources that are not mentioned on the page, on prior versions, on talk/talk archives, on AfD and so on.

Honestly, this could be something for a bot. Have it simply API call up every revision ever of an article at AfD or on demand. It scours all the versions of the page and talk, talk archives and AFDs. Any URLs or anything that's obviously a source (if no URL) is scooped up and put somewhere in a list like Article name/sources or something that's linked off talk. Every time it is reran, the sources list can grow. We'd have a permanent record of every reference ever put forth for a given article? The best thing is then each source could over time as needed develop on such a page it's own Perennial Sources-like history of review over time. Perfect space to permanent record quibble over sources, and then if 10 years someone new says "What about X source?" and we can simply say, "Read this section first". — VPP (t/c) 22:12, 14 October 2026 (UTC)

Having worked in politics, I can assure you that regardless of whether they are invalid and silly, sentiments remain, and play a fundamental role in shaping the community dynamic; it's clear in such cases that it's necessary to find middle grounds that preserve existing policy norms while nonetheless addressing the concerns raised by those angry with the way in which the system currently operates, on either side.

Collapsed for brevity

I think it would be a bad idea to offer the most pertinent examples I've come up against in recent memory, largely on account of my active TBAN; I will say from those experiences, though (which I suspect are still somewhat fresh in the minds of some admins active at AfD and ANI), that I really do regret what resulted from them, less on account of the consequences for content than for the loss of an editor who did exceptionally good work, even if we disagreed considerably on the correct follow-through for policy outcomes. Even then, that was something that could have been sorted, were it not for tensions of this nature reaching a boiling point in the referenced setting, which they ended up getting caught right in the middle of, when it seemed as though their primary goal was simply to help calm the waters. We need to start exploring ways of diffusing these tensions before they arise, because what oftentimes results is a dynamic where no one ends up feeling satisfied unless they win, which they carry with them long after the fact, even if we advise them to let it go.

What this is meant to say is that we have a community here that necessarily exists within it's context. Denying that obscures the fundamental problem that we need to address, that there are serious conflicting opinions impacting relations between users, because there don't seem to be proper mechanisms to elevate and address the concerns of both parties in tandem with one another. That's what Consensus/3O/DRR are intended to address, but all of them seem to end up being a zero-sum game in some way or another, which only fuels further resentment on the losing side. I think there's a lot more that needs to be done on this front to reconcile that fact, but I suspect this might be a good, simple place to start.

CSGinger14 (talk) 23:07, 14 October 2026 (UTC)

That is a lot of information.

I was just tossing out an idea I had been noodling with in my head a bit, for a semi-automated way to warehouse all sources for a given article, so no one has to waste time redoing others work. Kind of related to this. But simply, a bot-like tool that will read out all relevant history of a given article and it's talk, and extract every https URL that ever was saved to article or talk (as a starting function). Then the user can dump it as a list on talk, or something like that template idea I'd had. — VPP (t/c) 23:49, 14 October 2026 (UTC)

An list is a good idea. It would need to be easily annotatable, both with objective and subjective comments (e.g. marking dead, doesn't verify anything, paywalled, in-depth, etc) and have an explicit note that not every source needs to be relevant to notability (e.g. a source verifying a subject's birthdate is important but irrelevant to notability). Thryduulf (talk) 10:08, 15 October 2026 (UTC)

Well, I wasn't thinking any of those should or would be scripted. Way more lo-fi; a set tool that you give it an article name. It then proceeds to trawl EVERY revision (in a smart way, deduplicate, limit API costs, etc.) to make a list of every URL ever that showed up in a page edit or talk edit or in redirects to it, related AFDs, etc. Dedupe that, sort A-z off https://whatever and then the tool writes that to your user space, like User:Very Polite Person/url-dumps/The Page You Checked_all_URLs. You get some metrics like when it was pulled, then just literally a link of the sorted URLs, and the diff/edit where (best effort) it was first introduced in the context of The Page You Checked. Then the editor has to do the remedial work or simply move page to The Page You Checked/The Page You Checked_all_URLs and make it a team effort. Each article gets it's own little Perennial Sources.

How to update around iterative cycles/runs, I hadn't thought of. Notes on each source should probably go on talk, so it's easy to update the list over time without worrying about overwriting comments or customization. Like if either the User or Article version exists, check there first. You only need to check diffs/edits AFTER where you last checked (gets faster over time) to find new stuff.

Anyway, something like that as an idea. Some 20 year old article... go to tools server, like how Citation Bot works. Toss in the article, some time later you get a nice sub page catalog of URLs and talk page note saying it's ready. — VPP (t/c) 18:03, 15 October 2026 (UTC)

I think a bot which extracted as many URLs from the article, its talk page, their histories and any corresponding AfDs, de-duping them and formatting them as either a plain bulleted list or something that could be cut'n'pasted into {{Refideas}} - would be very useful for future editors looking to improve or expand the article. It would be a good minimum viable product for something with more bells and whistles (iterative runs, offline sources, corresponding articles on other wikis, richer formats e.g. populated CS1/CS2 templates etc.). Cheers, SunloungerFrog (talk) 09:56, 21 October 2026 (UTC)

I started messing with it on the side already and seems to work ok. — VPP (t/c) 15:33, 21 October 2026 (UTC)

When all the PHP-patching shenanigans are done and PetScan is back up, for some live targets you could look at petscan:39840057, which is all unreferenced articles that survived AfDs. Cheers, SunloungerFrog (talk) 15:42, 21 October 2026 (UTC)

The resentment is real and goes both ways. I've personally seen both of these results:

• The nom is mad because the AFD participant didn't put the sources in the article ("If you wanted to keep this article, why are you making WP:NOEFFORT to improve it?").
• The AFD participant is mad because the nom didn't put the sources in the article ("I just handed you multiple sources on a silver platter. Anyone who isn't a deletionist troll would have copy/pasted them in the article themselves instead of moaning about how nobody else did it for you").

WhatamIdoing (talk) 22:09, 16 October 2026 (UTC)

@WhatamIdoing You’re quite right, which leaves me curious as to whether it might be better to create an outlet (of the sort that I described in my last edit (name change)) to which nominators concerned principally with improving sourcing can turn without having to start a cage match in order to do it.

Half the time these discussions seem to devolve into violent battles over policy interpretations, when the nom just wants to see some fundamental improvements to the reliability of referencing on the page. It seems as though half of those where the sourcing can be found just end up being a waste of everybody’s time (and end in keep regardless), which undermines efforts to bring much needed attention to the other half, where it’s far more necessary for those policy interpretations to be considered.

Always glad to see your name pop up in discussion,

Best,

CSGinger14 (talk) 06:15, 17 October 2026 (UTC)

I'm not hopeful. The problem is fundamentally that "I" want things to be a certain way, but "I" don't want to (or don't have the skills to) do it myself. So "my" options are:

• I can add a maintenance tag, such as {{More citations needed}}. The median article has been in Category:Articles needing additional references for over five years. Category:Articles with unsourced statements has a four-year median. Of course, many tags get added and addressed right away, especially in high-traffic articles, but the tag may languish there for years. Also – and I think this is important in terms of speaking to the motivation of the editor – unless you are watching every edit to the article, or unless someone actually reverts your tag, you probably won't notice if the problem gets addressed. So this feels a bit like screaming into the void.
• I can blank individual bits of uncited content. Problem: It can be difficult to do that without making the article worse. Problem: People will sometimes yell at you. Problem: If you do a lot of this, people will hate you. Problem: If you don't know all the little unwritten rules, and you don't have any social capital, you'll get blocked. After all, we flag section blanking so we can revert vandals, and not so we can thank editors for removing encyclopedic content that needs a citation added. And none of these actually solve my (perceived) problem, which is the absence of a little blue clicky number at GA- or FA-level of density. (I just had a prolific AFD nom tell me today that "all content requires citations".)
• I can send the article to AFD. Problem: People will sometimes yell at you. But you get BIG rewards, and relatively immediate ones, too: People will often drop their current (and possibly more important) activities to give you lots and lots of attention right now, and some part of that attention will frequently be fixing up the article, so you have done a doubleplus good thing by finding a sneaky way to manipulate other WP:VOLUNTEERS into doing something that you couldn't or wouldn't do yourself, and you can see it happening on a predictable schedule. Of course, there are limits, but it usually doesn't reach that point, and it's usually a WP:TBAN rather than a block, and as long as you've only got a couple of noms active at any point in time, it's usually after years of getting what you want.

The rewards for misusing the AFD system. Until it stops being rewarding, the AFD system will keep getting misused. WhatamIdoing (talk) 06:51, 18 October 2026 (UTC)

Then I think that's the fundamental question we need to answer, either:

1. How do we stop misuse of the AFD system from being rewarding; or
2. How do we create an expectation that the objective purposes for which AfD is misused should/must be raised elsewhere in advance of a nomination?

The second question I consider to be more easily answered. I've been cooking something up but I'd want to know that it wouldn't just die here after a week before I considered putting real flesh on it.

Best,

CSGinger14 (talk) 07:47, 18 October 2026 (UTC)

If a source comes up that is really good but is not used on the article, consider adding it directly to an article as WP:Further reading or as an WP:EL. There, an entry indicates to editors and readers that more sources are available. (WP:EL does say "If the website or page to which you want to link includes information that is not yet a part of the article, consider using it as a source for the article, and citing it", but this discussion is presuming that we are stuck in the state before that. Call being stuck in that state one of the "other reasons".) CMD (talk) 02:52, 16 October 2026 (UTC)

@Chipmunkdavis Though I agree with you that it's a preferable option (particularly in advance of AfD), I don't think that instruction extends far beyond the bounds of this conversation, unless we sought to proselytize. Even still, uninvolved editors may simply ignore them, EL in particular, given that such sections are often devoted to platforms relevant to the given subject, but not qualifiable as a source in and of themselves. Part of why I felt that it would be beneficial to have a notice for these references similar to how Refideas is implemented was because it would highlight sourcing for which a consensus has necessarily been reached to indicate that they're reliable secondary coverage, which might help to guide newer editors unfamiliar with site expectations, and in turn lessen the chance that they have their first edit(s) erased as a custom/rule.

The proposal operates under the assumption that editors involved in AfD discussions will broadly not engage with the improvement of nominated articles upon their rescue. Perhaps that's misconstrued, but though it obviously doesn't account for all cases, the vast majority of those occur when someone from the ARS (or someone who shares its ideals) tidies up the article amid the fray, rather than sticking around to perform grunt work thereafter.

Though I'll admit that this is aimed at promoting inclusion, how I hope to do so is by reducing the extent to which editors feel that AfD needs to be used as an instrument for cleanup. Perhaps it would do the exact opposite (i.e encouraging editors to nominate more pages indiscriminately in the hopes of getting a few sources attached after the fact), but that's precisely what I'd hoped we could come to some understanding about through this discussion. Maybe some fusion of the point raised by VPP, in tandem with a shifted expectation that a challenge to the article's notability should first be raised at its talk, prior to / rather than immediately bringing it to AfD (talk discussions wherein/whereafter a system similar to the one I described above could also be implemented).

Best, and thanks for your engagement,

CSGinger14 (talk) 06:22, 16 October 2026 (UTC)

We already have a problem with editors sending articles to AFD in the hope of forcing everyone else to drop their current projects, some of which is significantly more important than whether Chris Celebrity gets fixed up during the next week. WhatamIdoing (talk) 22:21, 16 October 2026 (UTC)

Yes, there are a few editors who openly admit they use AfD to "enforce" the WP:V policy. Katzrockso (talk) 01:16, 18 October 2026 (UTC)

That is so weird. What does that look like? Just to be nasty and strong arm people into editing? — VPP (t/c) 02:43, 18 October 2026 (UTC)

"Nice little article you've got there. Shame if anything'd happen to it..." WhatamIdoing (talk) 06:53, 18 October 2026 (UTC)

That deplorable 'custom' I'm familiar with. — VPP (t/c) 07:29, 18 October 2026 (UTC)

We had a similar problem with portals in 2019. After a proposal to remove the namespace was rejected, a now-banned editor nominated them for MfD at rates of up to 100 per week and succeeded in getting most portals deleted. Certes (talk) 21:17, 19 October 2026 (UTC)

I tried to click that blue text and wondered why my cursor didn't become a hand. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 06:38, 22 October 2026 (UTC)

@CSGinger14 I think you're being generous. I find a lot of nominators don't do due diligence searches. Even where they do, it's often limited. And when two sig cov sources are found, some nominators (and previous delete voters) won't withdraw their objections. The problem with PROD is it relies on someone objecting. If the creator is no longer an active editor, the page has less chance of uplift/survival. The issue with AfD is that, instead of the closer/AfC reviewer determining if the article now means notability requirements, it's essentially a vote (even if we say it isn't). So a page can be subjectively deleted or saved. I'm happy to support your proposal but I don't think it goes far enough. I think we need one of two AfD circuit breakers:

• if you AfD an article, the discussion doesn't not start immediately, the article is templated for 7 days. You are obliged to reconsider your nomination if two sig cov IRS sources exist/are added in that time or it can be 3O'd if rescuer thinks the nominator is being unreasonable.
• if two sig cov IRS sources are added during the discussion, the previous delete votes get less weight or are thrown out

But honestly, I'd like to see an investigations process for bulk nominators where there is suspected bias/abuse. Mme Maigret (talk) 00:22, 27 October 2026 (UTC)

How would this differ from ANI? I have certainly seen questionable AfD nominations be brought up there. M kuhner (talk) 16:56, 1 November 2026 (UTC)

Re-upping for a week as I haven't had a chance to look into this but want to avoid a bot archive. CSGinger14 (talk) 04:12, 1 November 2026 (UTC)

Edit summary reminder on by default?

Tracked in Phabricator
Task T441726

New users often get reverted because they don't explain what they are doing. Often vandalism, but at times they have a good reason to remove text. The problem is they don't tell us. Should we ask the WMF to turn the "remind me when I forget an edit summary" on by default for new editors? Or at least test it? In solidarity, —Femke (talk) 🐦 19:42, 18 October 2026 (UTC)

I think that would be a good thing to trial. The only potential downside I can see is more misleading or irrelevant edit summaries, in good or bad faith, as not everyone understands what an edit summary is for (e.g. I've seen at least two in the past few days where people left their email address in the edit summary), and that might be harder to detect than an empty summary (I don't know), but overall my gut feeling is that it would be a net positive. Thryduulf (talk) 19:47, 18 October 2026 (UTC)

That sounds like a good idea, I've encountered it in other wmf wikis. The error message should only ask for a brief summary, to avoid burdening new users. FaviFake (talk) 12:58, 19 October 2026 (UTC)

Only time will tell how that will turn out. But, the idea is interesting in that a clever bot could add "obvious" edit summaries and ask for user confirmation. An obvious example would be typo corrections. I would like that for my own edits, given that I don't like to do obvious edit summaries. Another example is reference addition or cn tag addition etc. This does not have to be real time and will involve no LLMS. This would be more useful than reverse-genius projects like abstract Wiki, etc. Yesterday, all my dreams... (talk) 14:59, 19 October 2026 (UTC)

You can enable it for yourself right now by going to Special:Preferences#mw-prefsection-gadgets and selecting the corresponding option. FaviFake (talk) 15:02, 19 October 2026 (UTC)

Sorry, that is the last thing I would want to turn on. If it automatically suggests "reference added" as the summary and I just click ok, I would like that. Yesterday, all my dreams... (talk) 15:07, 19 October 2026 (UTC)

It doesn't, but there are other scripts at WP:USL that allow you to save pre-set edit summaries. I prefer to use a text expander app like aText. For example, I could set it up so that when I type "zref", it immediately turns into "reference added". I have hundreds of these, ranging from small templates to entire paragraphs. FaviFake (talk) 15:11, 19 October 2026 (UTC)

The fact that you have to tell me about it means that over 90% of users do not know about these. My suggestion was to have it for everyone. Anyway, I have said all I needed on this, and will leave it in the hands of you guys. Have a good day. Yesterday, all my dreams... (talk) 15:27, 19 October 2026 (UTC)

I would support this. I also think it would help new users pause and think a little bit before publishing an edit. qcne (talk) 15:32, 19 October 2026 (UTC)

Agreed. I run across many users with edit counts in the hundreds (and sometimes even thousands) who rarely if ever use edit summaries. A not insignificant number of them are problematic for one reason or another, and it makes it much harder to track what they've been doing. For good faith newbies it can help us intervene and correct them sooner so they don't continue making the same mistakes. ChompyTheGogoat [ Bleat | Munched ] 18:04, 19 October 2026 (UTC)

What do people think if the option is only to turn it on or off. That is: also for experienced users? I'd love to know more about what is behind edits of more experienced editors too. In solidarity, —Femke (talk) 🐦 18:08, 19 October 2026 (UTC)

I have zero issues with this being a universal "On". qcne (talk) 18:11, 19 October 2026 (UTC)

I can't think a good reason not to turn it on for everybody. There are occasionally times when there should be no edit summary (because something automated will add one) but it's no hardship to say that you actually do want to make an edit without a summary. Thryduulf (talk) 18:23, 19 October 2026 (UTC)

I always try to add one even when it's not really necessary - even just a single word - pro forma. If someone is skimming my contributions I don't want them to have to stop and check individual edits just to see whether there's a problem. My sandbox history is full of increasingly irrate summaries when I'm trying to work out tedious code issues XD ChompyTheGogoat [ Bleat | Munched ] 18:56, 19 October 2026 (UTC)

See also: "label" "label" "tag" "label". Just because. ChompyTheGogoat [ Bleat | Munched ] 19:00, 19 October 2026 (UTC)

I've opened a phab: phab:T441726. My preference is to test this first, as it introduces more friction which can backfire. But if there is no capacity to test, I would prefer this is enabled. In solidarity, —Femke (talk) 🐦 20:37, 19 October 2026 (UTC)

Yes, there is no "good" reason. But there is a real reason: laziness. If it is viewed as nagware, it will put some people off. An experiment is well warranted. Yesterday, all my dreams... (talk) 14:42, 20 October 2026 (UTC)

Please consider this edit. Why doesn't the system automatically add a summary for it? It would take a simple, simple bot to do it, and not even in real time. Let us start there, before introducing nagware, please. Yesterday, all my dreams... (talk) 15:14, 20 October 2026 (UTC)

I'm sure there are additional situations where an automated summary would be possible, but there are far more where it's not, and countless edits (including large scale changes) with no descriptors. ChompyTheGogoat [ Bleat | Munched ] 15:36, 20 October 2026 (UTC)

So we could prompt for large scale changes but not simple cases such as above. Yesterday, all my dreams... (talk) 16:01, 20 October 2026 (UTC)

Smaller changes can still have major impacts. The size of an edit isn't necessarily indicative of its significance. Besides, where would you draw the line? Any cutoff would be arbitrary. ChompyTheGogoat [ Bleat | Munched ] 16:05, 20 October 2026 (UTC)

I would start with link additions then see what happens. The two of us can discuss this for ever and a day. Let us wait for other comments. Thanks. Yesterday, all my dreams... (talk) 16:19, 20 October 2026 (UTC)

Most of the edits I see that are purely link additions are through the newcomer tasks, so those are already tagged as such. Edits without summaries are most often newbies manually adding or removing information. ChompyTheGogoat [ Bleat | Munched ] 16:26, 20 October 2026 (UTC)

Support. Summaries are optional and many good edits are made without them, but it's a good habit to encourage. Certes (talk) 20:48, 19 October 2026 (UTC)

I would love to have a trial with actual statistics, and then make a decision based on those statistics. Best, HouseBlaster (talk • edits • he/they) 02:48, 20 October 2026 (UTC)

Let us not just love to, but insist on. Let us release no cure (did someone say Viox?) without a Clinical trial, please. Yesterday, all my dreams... (talk) 14:47, 20 October 2026 (UTC)

Support as a trial, but we should also turn "Add two new dropdown boxes below the edit summary box with some useful default summaries" on by default if we do so. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:37, 22 October 2026 (UTC)

Another idea I had, is a marathon A/B test with a bunch of existing settings tested. This intervention would possibly lead to more false edit summaries, meaning it can backfire too? In solidarity, —Femke (talk) 🐦 07:19, 22 October 2026 (UTC)

I do seem to recall that mobile (maybe one of the apps) had a dropdown at one point, and it was misused to the point that patrollers found it to be a signal for edits that needed extra attention. Anomie⚔ 11:47, 22 October 2026 (UTC)

Wikipedia:Canned edit summaries, still around in some form as Special:AbuseFilter/633. One of our best anti-vandalism tools. CMD (talk) 11:53, 22 October 2026 (UTC)

Interesting. I have the gadget enabled, although I pretty much only use it for either spelling/grammar or formatting corrections. Anything more extensive I type out manually. I guess the users who'd abuse such a feature don't know or care enough to bother enabling it. I'm mildly surprised that they'd outweigh good faith new users who'd prefer that option though. ChompyTheGogoat [ Bleat | Munched ] 19:49, 22 October 2026 (UTC)

I would also support a trial. What were you thinking, first 50 or 100 edits? First X mainspace edits? Relatedly, it would be good if someone could put together a quick and basic info page about what the warning looks like, perhaps something that Special:Preferences#mw-prefsection-gadgets could link to. That would also be a useful page to note any test results and track changes in defaults. CMD (talk) 07:25, 22 October 2026 (UTC)

I would say the group I expect the biggest difference for are newbies. So an A/B test among TAs and nonconfirmed editors would make most sense. To reduce confusion, I image their settings won't get changed once they reach a certain edit count. In solidarity, —Femke (talk) 🐦 16:55, 22 October 2026 (UTC)

Support: For newbies, more so than experienced editors. But happy to support for both Mme Maigret (talk) 09:30, 27 October 2026 (UTC)

Support changing the default in a trial, but Oppose any change that would prevent disabling the setting. Daniel Quinlan (talk) 17:35, 27 October 2026 (UTC)

Support adding it as default for a trial, collecting data for groups across editing levels. As far as I know, gadgets can always be disabled if needed. Chaotic Enby (in solidarity · talk · contribs) 18:05, 27 October 2026 (UTC)

Oppose unless it turns off once you get a certain number of edits/certain user right, or if not, a button to turn it off in the publishing interface in the bottom. Support a trial for a couple of weeks. Theeverywhereperson talk here ^{In solidarity!} 15:15, 29 October 2026 (UTC)

Support, as long as it is optional for more experienced editors. GreatWhiteEditor (talk) 20:52, 29 October 2026 (UTC)

Did anyone here read Wikipedia:Perennial proposals#Automatically prompt for missing edit summary? WhatamIdoing (talk) 04:40, 30 October 2026 (UTC)

I hadn't seen that, but most points have been made. It's clear that this should be tested first. With the positive results from the extra friction of edit check, this may be turn out great. It may also not. In solidarity, —Femke (talk) 🐦 07:49, 30 October 2026 (UTC)

Oppose unless phab:T367412 is fixed first. This will lead to even more people using bad summaries (like "created redirect") when creating and retargeting redirects, suppressing the automatic summary, which actually includes the target. Warudo (talk) 14:15, 30 October 2026 (UTC)

Support, even I forget to do edit summaries sometimes and I've been on Wikipedia for a while! GarethBaloney (talk) 19:00, 3 November 2026 (UTC)

RFC - Indian cinema CTOP

Should South Asian cinema, broadly construed, be placed under general sanctions as a subtopic of the South Asia contentious topic in the same way as caste and Indian military history?

Specifically, "South Asian cinema, broadly construed" should be understood to include at a minimum films as well as all associated cast and crew (actors, directors, musical directors, etc.) including but not limited to India, Pakistan, Sri Lanka and Bangladesh.

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. Article creation in the topic area is restricted to editors with extended-confirmed permissions. Other editing within the topic is placed under autoconfirmed restriction.

D. The whole topic is placed under autoconfirmed restriction only.

Worth noting that the proposals for autoconfirmed restriction are without precedent as far as I'm aware.

Answers which were already given during the RFCBEFORE discussion (included below under 'Discussion') have been transcluded into the 'Survey' subsection. Courtesy pings for those editors in case they want to modify their responses at all: IrisChronomia, Gurkubondinn, Jéské Couriano, CoffeeCrumbs, CNMall41, ABx11

Athanelar (talk) 10:57, 23 October 2026 (UTC)

Survey (Indian cinema CTOP)

"Anchor" comment placed at the top for the purpose of giving editors something to hit "Reply" on.–Maltazarian ^{ᚾparleyinvestigateᛅ} 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)

Unproductive side-discussion which has ended up at WP:AE. ~~ AirshipJungleman29 (talk) 18:35, 29 October 2026 (UTC)

• You probably could have worded it better. "Extreme" is a word with quite a few negative connotations. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 20:48, 28 October 2026 (UTC)

  Oh, please. My statement was Telugus are about the most extreme end of this spectrum and that statement comes at the end of a lengthy comment talking about how passionate Telugu film fans are. Literally what else could I possibly be referring to by "this spectrum" except their passion for film? Athanelar (talk) 20:54, 28 October 2026 (UTC)

  I would say that employeeing any Ethnic stereotypes, especially in a contentious topic is unhelpful and should be avoided. You don't want to rephrase or strike your statement? GreenLipstickLesbian💌🧸 21:16, 28 October 2026 (UTC)

  You don't want to ask CaptainEek to rephrase or strike the statement Americans are overwhelmingly patriotic? Athanelar (talk) 21:36, 28 October 2026 (UTC)

  Patriotic is a word which carries positive connotations. If the sentence had been "Americans are overwhelmingly nationalist", then this would be a different discussion. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:44, 28 October 2026 (UTC)

  Patriotic is a word which carries positive connotations. For you, maybe. It definitely doesn't for me. Athanelar (talk) 21:47, 28 October 2026 (UTC)

  Ah. That explains a lot. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:49, 28 October 2026 (UTC)

  @Athanelar We're not talking about CaptainEek's behaviour; wrong or right, it is not a valid justification for your own.

  With all cards on the table, I debated reporting this to AE, because casually using stereotypes is well below the standards expected in a contentious topic, but I prefer to avoid the drama if at all possible. I'd prefer not to, but saying that people of a certain ethnicity do or believe X is harmful, even if it's not ill-intended. GreenLipstickLesbian💌🧸 22:28, 28 October 2026 (UTC)

  the Telugu film industry and its fans does not mean "all Telugus everywhere behave this way due to inherent ethnic factors". No derogatory statement was made and this smacks of western virtue signaling. ChompyTheGogoat [ Bleat | Munched ] 22:36, 28 October 2026 (UTC)

  You're right; but the fact you take umbrage with what I said being an "ethnic stereotype" and not what they said is not because one of us did something wrong and the other didn't, it's because of your own Amerocentric worldview.

  I have no interest in doxxing myself to win an argument, so I will leave it at asking you to please stop pearl-clutching at me. I have said nothing which is ethnically offensive to Telugu people, and I promise you I can say that with more than a reasonable degree of certainty. Anyone who has seen me around the project knows I'm not needlessly belligerant, if I'm standing behind my words to this extent I am doing so out of certainty that I've said nothing wrong. Athanelar (talk) 22:33, 28 October 2026 (UTC)

  Now at WP:AE#Athanelar, in case anybody wants to make a statement about my behaviour during this discussion. Athanelar (talk) 23:31, 28 October 2026 (UTC)

  Oh good grief. ChompyTheGogoat [ Bleat | Munched ] 23:42, 28 October 2026 (UTC)

  That's exactly the point - you're applying your personal assumptions. I also dislike patriotism, but I don't assume negative connotations because I know most people don't intend it that way. Extreme is simply a modifier. "Extreme kindness"; "extremely charitable"; even "extremely passionate" can be positive - heck, I'd bet there are plenty of people involved with this topic who would see "extremely passionate about their favorite stars" as a positive statement. It's simply descriptive. ChompyTheGogoat [ Bleat | Munched ] 22:11, 28 October 2026 (UTC)

  That's a fair explanation here. I withdraw my point, as this is a matter of opinion. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:12, 28 October 2026 (UTC)

  Still carries negative connotations. When you say "extreme end", the first thing that comes to mind is extremism. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:43, 28 October 2026 (UTC)

  If seeing the word "extreme" in the same paragraph as a mention of brown people makes your mind go to "extremism" when the context very obviously implies nothing of the sort that is a commentary on you, not on me. Athanelar (talk) 21:45, 28 October 2026 (UTC)

  Implying that this is because it mentions Telugu people is an aspersion, and an assumption of my thoughts. It would be the same if we were talking about, say, Americans or Brits. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:46, 28 October 2026 (UTC)

  I don't think I worded this well, so to clarify: the connotations would still be there if we were talking about any other people, and ethnicity has nothing to do with it. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:47, 28 October 2026 (UTC)

  I highly doubt you would still be griping at me if I typed a paragraph about the history of Brits and tea consumption and ended it by saying "the British are among the more extreme end of this spectrum [of tea culture and tea consumption]" Athanelar (talk) 21:51, 28 October 2026 (UTC)

  Actually, the first thing that comes to mind here is the American Revolution and the second thing that comes to mind is the slave trade. So yes, I probably would be griping at you here. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:55, 28 October 2026 (UTC)

  That's one hell of a leap. ChompyTheGogoat [ Bleat | Munched ] 22:12, 28 October 2026 (UTC)

  I lived in an ultra-confederate lost-cause state for nearly a decade. That's why I made that logical leap. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:15, 28 October 2026 (UTC)

  So it's your personal bias showing through, as we've pointed out. Not a universal interpretation. ChompyTheGogoat [ Bleat | Munched ] 22:17, 28 October 2026 (UTC)

  It's less personal bias and more lived experience, but yes, I do now agree with your point that this matter is entirely subjective. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:19, 28 October 2026 (UTC)

  Bias develops out of lived experience. No one is born with it but we all have them, and it takes constant work to attempt to overcome them - or at least prevent them from affecting your interactions with others. When it comes to marginalized groups listening to what actual members of those groups say is one of the best tools for doing so. ChompyTheGogoat [ Bleat | Munched ] 22:45, 28 October 2026 (UTC)

  That is a fair point, and I agree. What is the relevance of your point about marginalised groups here though? (Sorry about my signature, I'm currently in the middle of changing it)

  ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ

  22:48, 28 October 2026 (UTC)

  It's an aspersion to imply I could've meant literally anything untoward based on my word choice in this context. Athanelar (talk) 21:49, 28 October 2026 (UTC)

  I'm not saying that, I'm saying that you could have chosen your words more carefully. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:50, 28 October 2026 (UTC)

  An assertion which is based on the idea that the words I chose could possibly carry the connotation of "extremism" in this context, which is completely absurd. Bad day to be a fan of extreme sports, for all anyone knows you could be expressing your enthusiasm for Jihadi skateboarding. Athanelar (talk) 21:55, 28 October 2026 (UTC)

  Extreme sports is a very idiotic wording and the first thing that comes to mind when you mention extreme sports is getting shot out of a cannon into a volcano. I am generally not a fan of the use of the word extreme as a descriptor unless it is talking about extremism, due to the fact that it contains those connotations of extremism to begin with. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:59, 28 October 2026 (UTC)

  Sounds like you have an overall problem with the English language. Extreme has been used as a descriptor for a wide range of ideas before "extremism" was known as a specific concept. This is an extreme interpretation. ChompyTheGogoat [ Bleat | Munched ] 22:14, 28 October 2026 (UTC)

  Well, there's this. Also yes, I do have a problem with the English language. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:16, 28 October 2026 (UTC)

  Once again, I do not think I worded this well, so to be more precise, "extreme sports" carries a connotation of violence. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:02, 28 October 2026 (UTC)

  Extreme sports do carry a high risk of injury. That's precisely why it's used. And people still love them despite it. ChompyTheGogoat [ Bleat | Munched ] 22:15, 28 October 2026 (UTC)

  Lots of words carry connotations of lots of things. Extreme sports have nothing to do with extremism, the Mountain chicken is a species of frog and the Chicken of the woods is a species of mushroom. It is strange that out of all the definitions of the word 'extreme' you would insist we all stick to one. Athanelar (talk) 22:06, 28 October 2026 (UTC)

  Extreme sports have nothing to do with extremism but they bring those connotations to mind anyway. Maybe it's just a quirk of my brain, but synonyms are hard to comprehend to me. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:10, 28 October 2026 (UTC)

  Also, "chicken" is not a negative connotation. "extreme" is. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:11, 28 October 2026 (UTC)

  Not true! If I called you a "chicken" I'd be calling you a "coward". Does that mean one could conceivably argue that Chicken of the woods might, if you squint at it hard enough, mean "coward of the woods" and therefore if I say "I think chicken of the woods tastes great!" I'm some kind of Klingon who enjoys eating cowards?

  I hope you're starting to see my point. In any case I think this discussion ought to end here because we're thoroughly derailing things. I need to move this all down to the appropriate section once it quiets down. Athanelar (talk) 22:13, 28 October 2026 (UTC)

  I have heard the word "chicken" used in that context about 4 times before, so I think this is just a case of differences in opinion and perception. But yes, we probably should end this discussion here. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 22:17, 28 October 2026 (UTC)

  "People are extremely passionate about this subject" is not a stereotype, nor derogatory. I could make the same remark in regards to many Western topics. The fact that it's racially charged is a significant factor in why it needs to be a CTOP. You wouldn't say people can't refer to ethnicity in a discussion about caste restrictions because it's intrinsic to the entire reason for the discussion. ChompyTheGogoat [ Bleat | Munched ] 21:28, 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 ^{ᚾparleyinvestigateᛅ} 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)

Pre-RfC 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)

Both are intrinsically linked to caste, Huh? That's entirely false. I'm fairly certain that the scores of WP:UPE editors in the Indian cinema topic area are not motivated purely by nationalistic or caste-specific sentiment. You do get the odd film that flares nationalistic rhetoric (for example Dhurandhar: The Revenge) but tbh that is not significant enough to require a special carveout, SASG and IMH are good enough for those. The problem that it looks like we are trying to solve is UPE Sohom (talk) 08:55, 26 October 2026 (UTC)

@Sohom Datta read this. ғѳmɑɭʱɑυե (Any pronouns)ᵀᵃˡᵏ 21:57, 26 October 2026 (UTC)

@F0malhaut42 and @Athanelar There might be underlying caste lines in the Telegu industry but those are not the ones that have seen the most problems onwiki. For what it's worth, the WP:UPE disruption is not confined to just the Telegu film industry. UPE disruption exists in the Tamil industry, Telegu industry, the Bengali film industry, the Hindi one and potentially even the Punjabi one. The constant and primary disruption factor onwiki is WP:UPE, not motivated editing (which would require significantly different considerations) denoted by the fact that that most of the reports related to disruption show up on WP:SPI and not WP:AE and are typically less about POV-pushing of specific caste-associated sets of movies (obviously we ignore the SASG specific ones like Dhurandar that are already covered by ECR) Sohom (talk) 00:53, 27 October 2026 (UTC)

It's both. There are tons of disruptive editors who can't be taken to SPI because a bunch of unsourced insertions with no edit summaries or attempts to communicate leave no proof either way. I've been accused of bias numerous times for blocking such changes. There's nothing to take to AE because the current restrictions are too vague to apply to this problem. If they did we wouldn't need to implement additional ones. ChompyTheGogoat [ Bleat | Munched ] 23:35, 27 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)

A nice case study I just stumbled upon for this discussion: WP:ANI#Anirvinya 2009, about a user who for months now has been receiving warnings for unsourced content, largely in the subject of Telugu cinema, with edits like this one and this one, arbitrarily adding "results" like "Blockbuster", "Flop", and "Superhit" to the filmographies of various Telugu actors.

When people in this discussion have said that restrictions in this topic area run the risk of scaring off new editors for whom their passion for South Asian cinema would otherwise be an entry point, it's worth pointing out the unfortunate other side of that. A topic which attracts massive amounts of inexperienced editors is not always a good thing. The user in question is also currently at 563 edits, which means the majority of their disruptive-at-worst and unproductive-at-best contributions would have been avoided if the topic area were under ECR as proposed, considering they have essentially gained EC by editing in this topic area. Granted, they also probably could've been avoided by a more timely report, but the fact that users like this are slipping through the cracks is exactly the reason that myself and others are backing restrictions in this topic area. Athanelar (talk) 01:33, 2 November 2026 (UTC)

Post RfC start discussion

What kind of enforcement actions are available and aren't working? Indian cinema rarely escalates to the arbitration enforcement noticeboard; is this a lack of capacity (awareness of CTOPs, energy to do so, confidence to do so), range hopping TAs, mostly handled by non-CTOP admin actions, etc? Is this mostly getting reported to SPI, ANEW, and RfPP? Is this appearing at AN/ANI, and if so, what are those threads like?

Looking at a few recent protections from the protection log; Dalit Film and Cultural Festival under CT/CASTE, Fighter (2024 film) under IMH, Jailer 2 (1 year ECP, no subtopic), Achhut Kannya (no subtopic). Most people are getting blocked/topic banned for subpar conduct in CASTE or IMH or modern politics (check WP:AELOG for yourself to be sure, but I've read or participated in almost all cases in the last year and definitely in CT/SA). It's hard picking out the cinema related ones from the protection log alone, but it's not as frequent as other CT/SA protection clusters. The main clusters I am aware of are modern politics and political parties, castes, and military history. As for why I'm asking, characterizing how disruption is currently being handled helps a lot in understanding what we are struggling with. I don't go out of AE and AN very often, my main area is copyright after all, and I would imagine that this will also draw people that are unfamiliar with the scope of enforcement entirely. Sennecaster (Chat) 17:37, 27 October 2026 (UTC)

In my anecdotal experience we've had a lot of film-adjacent articles come through AfC in some form or another with UPEs, socks, etc. One which springs to mind is Mission C2000 which was tendentiously created and recreated under lots of different titles by Alakmarsaify socks. Admittedly I've never dived much into cleaning up the topic area myself because what I have seen of it at AfC has really kept me at bay. @ChompyTheGogoat is probably in a better position to call up some specific examples since they were recently doing cleanup. Athanelar (talk) 22:59, 27 October 2026 (UTC)

There's not enough enforcement period. Most of it goes through SPI or ANI when someone (usually me) actually bothers. The current CT/SA restrictions don't apply to this subject area, and most editors just drop whatever insertion they feel like with little to no sourcing and no communication, primarily from TAs or low count named SPAs.

Anyone who thinks we shouldn't need additional restrictions should spend some time actually working cleanup in this subject area to see just how extensive the problem is and why current remedies aren't sufficient. I just ran an editor to ANI with 2500 edits over multiple years, compromised almost entirely of unsourced or poorly source additions to this subject area. They had 18 warnings (and an additional dozen miscellaneous TP messages) that they ignored. All of those other editors were content to drop drive-by templates and move on without actually addressing the problem - and it's far from the only case. Even under ECR we'd have to work through grandfathered editors like this, but "difficult to enforce" is not a viable excuse for not implementing restrictions - otherwise why have restrictions at all? At least this would give enforcement some teeth. Widespread ECP and a low bar for blocks would have a huge impact. The problem has been allowed to build up for years and it will not be handled without additional restrictions. Milder sanctions might have been sufficient if it had been addressed sooner, but that ship has sailed.

Whatever is decided, you can deal with it without me. Or don't. Keep letting it fester. I'm washing my hands of it regardless. I'm done being the only person who cares. ChompyTheGogoat [ Bleat | Munched ] 23:46, 27 October 2026 (UTC)

ChompyTheGogoat, you sound dangerously close to total burnout. Maybe you're already there. Someone else will pick up that cleanup work later. Anecdotally, I've been doing copyright nonstop for 3 1/2 year straight, and then have done arbitration enforcement for 2 years straight. I am burnt out. I don't have capacity to report or handle everything even in copyright. That's okay though. I completely understand your frustrated, I have had extremely similar moments, but I am not here to be your "enemy" or to say that there's no need for action here. I'm trying to figure out what specifically needs to be targeted, whether or not any proposal here gains consensus or not. Okay, we need to get the AFC people more involved in identifying socking/UPE and escalating. That is doable. Okay, maybe we need to get RCPers using more semi-auto tools that make reporting a lot easier. EditCheck should hopefully be helping, but if it's not we need to know and the people that do this are not omnipresent and not high in number. There's a lot of people here that are interested in stopping disruption and frequently work arb enforcement, so you're speaking to people that do not have experience in this specific topic. I don't do AFC. I don't do SPI, and a lot of my wiki-friends are SPI but only think of it from the UPE and socking perspective. None of us are saying that there isn't an issue. The people that are familiar here are administratively conflicted out in a lot of ways, or don't want to open themselves up to the very real risk of harassment. We are asking in good faith because we want to know what we can do in the meantime. We're aware of the issues now, we can do something about it.

WP:CT/SA covers all of South Asia, broadly construed. It covers Indian cinema. What you're experiencing is the very real reality in that CTOP enforcement is incredibly stretched thin and simply do not patrol that topic enough. I don't appreciate All of those other editors were content to drop drive-by templates and move on without actually addressing the problem - and it's far from the only case.'s lack of good faith, so I really do ask that you step back before you say anything you regret. I get the burnout. I really do. I have spent a lot of time arguing with people that they can't add copyright violations back. But it doesn't give you the right to take that frustration out on others, and not on people that aren't familiar with the issue because that isn't their expertise or interest. It's the reality of wiki work that we have different things, and that we get burnt out and frustrated, but we have to emphasize and understand each other despite that. Sennecaster (Chat) 03:57, 28 October 2026 (UTC)

Horse, barn door. I tried giving myself a break by working on another topic area that I'm passionate about and got accused of LLM use after spending hours hand writing an entire article, so when I say I'm done, I'm done. It really doesn't matter what other editors think of me at this point.

Someone else will pick up that cleanup work later. If that was true we wouldn't be in this situation in the first place. Editors have spent years ignoring the problem, as Jeske said below. And when I said All of those other editors were content to drop drive-by templates and move on without actually addressing the problem that is literally what happened. Eighteen editors dropped templates and ran, without looking at the pile that had already gone unanswered or bothering to file at any noticeboards. For years. That is a fact, not hyperbole. It is not the only such case that I've filed. So yeah, when the people who have no experience in this subject area still think they're qualified to drop a !vote claiming we don't need to make any substantial changes, I take issue with it (and yes, some are saying that). They're free to abstain if they don't have the relevant experience to give an informed opinion. I also have no prior experience or interest in the topic. I stumbled across it and saw a problem that no one else was stepping up to deal with, so I did. Or at least tried. And it's no wonder no one wants to do it. It's incredibly thankless work - it's one thing getting harassed by the POV pushers that are causing the problem, and quite another when other experienced editors patrolling noticeboards are more worried about the formatting of my reports than the actual problem I'm reporting. You want to know why people are hesitant to report? That's why. Too much infighting and pedantry; not enough concern for the actual damage being done to the project. I'm highly disappointed in this community overall, and with AI hoards at the walls - now including fully autonomous agents - I don't think you'll be able to hold out for long while competent editors are being chased off. Even veteran editors of 20+ years are giving up in frustration, and I can understand why. Guess I waited too long to sign up. ChompyTheGogoat [ Bleat | Munched ] 05:04, 28 October 2026 (UTC)

I understand you're frustrated, but it's very likely that some of those 18 editors have their own overwhelming backlogs of work. Like with me for example, I almost definitely have flagged some Indian cinema articles for AI (if there is AI) instead of dropping everything to go fix it, because I am currently about 200 tabs deep in other unfinished AI cleanup and I do not have the time. There are a finite amount of hours in the day.

And if you mean userpage warnings, what more exactly are people supposed to do? Stand outside their window with a boombox? You can't force someone to change their behavior. Gnomingstuff (talk) 02:58, 29 October 2026 (UTC)

I think the point Chompy's making is that that's exactly why we need restrictions in this topic area. People obviously don't have the time or interest to dedicate to cleaning up this topic area, reporting editors and pages for arbitration remedies, etc. It's not that any of those 18 editors should've dropped what they were doing and solved the problem themselves, it's just that if we don't have the interested and able editor-power to do it, then we need another solution. Athanelar (talk) 03:10, 29 October 2026 (UTC)

Yes, the warnings. That's why we have noticeboards. Sanctions are a thing. Most of the ones I've taken the time to report do get blocked, and there would be much less disruption if others had bothered to do so sooner. The time it takes to file said reports is far less than the cleanup that's now needed for all those thousands of edits. I refuse to believe that all 18 editors (and all of the others who dropped additional messages there, or other warnings on other editors) were so very busy in that exact moment that they couldn't possibly take the time to compile a few diffs. Other types of disruption in other subject areas get addressed far more quickly.

So, if people aren't willing to address the huge number of problematic editors on a case by case basis, we instead need sweeping restrictions that will stop the vast majority of them, even if a few good faith also get caught up in the net. Page protections are one of the best tools we have for preventing ongoing distribution with minimal effort, and the sooner they can be applied in subject areas that are rife with these issues the less needs to be fixed. ChompyTheGogoat [ Bleat | Munched ] 03:37, 29 October 2026 (UTC)

Other types of disruption in other subject areas get addressed far more quickly.

This feels like the thing (and I've probably done it too) where a person is so focused on putting out a metaphorical fire in their room that they don't notice that the rest of the house is also on fire. Every part of Wikipedia is falling apart. I'm familiar with the amount of squabbling that goes on with film articles (since I have to slog through the hundreds of drive-by talk page comments per month that just say "Box office"), and even that is nothing compared to the dozens of backlogs of hundreds of thousands of articles needing maintenance.

As far as sanctions go, it's emotionally exhausting enough to even create one noticeboard report, and I don't blame anyone who just doesn't have it in them. Gnomingstuff (talk) 12:50, 29 October 2026 (UTC)

I have edited other topics. I'm aware that there are widespread issues, but this subject area as a whole is more problematic than most, which might have some articles and editors that are problematic but are more monitored overall, especially on the most popular articles. I can guarantee that any Indian film article I open will have issues - usually extensive ones - and if (or rather, when) I find an editor in the history who's part of the problem it's virtually guaranteed nothing was ever done about it, regardless of their edit count.

As a reminder I've already been chased off the project, and not purely over this topic, so yeah, I know there are problems. Lots of them. This probably won't even matter in the long run. ChompyTheGogoat [ Bleat | Munched ] 18:38, 29 October 2026 (UTC)

From what I recall off the top of my head, cinema-related articles only show up at AE if they implicate Indian politics, caste, or history (as those are the ones that tend to draw the fiercest nationalistic responses). Otherwise, it's closer to what Chompy says - nobody gives a rat's ass about that specific topic area other than the mercenary editors and the naive newcomers, and I suspect part of the problem is that outside of India few have much interest in Indian cinema and those that do don't want to deal with the unusually-insistent mercenaries and true-fan types that populate the topic area. —Jéské Couriano v^_^v ^{Thriller Night!} 02:12, 28 October 2026 (UTC)

Yep - even with ECR it'll take some dedicated editors with no vested interest who are willing to roll up their sleeves for the overall integrity of the project to really get a handle on things. I think once the current swarms who feel like they have free rein to insert whatever they feel like realize that won't fly anymore things will simmer down and be easier to maintain - but that works needs to happen first or it will just continue to snowball. Good luck. ChompyTheGogoat [ Bleat | Munched ] 05:09, 28 October 2026 (UTC)

Hence my linking catch-22 above. I think it's safe to say the issues are threefold:

1. Nobody with experience is familiar enough with Indian culture and how it interacts with cinema, especially where caste is involved. This makes them incompetent, through barely any fault of their own, to actually edit in and administer the topic area. Those who are knowledgeable about the subject matter are vastly outnumbered and overwhelmed.
2. Few/none of the new users entering the area are willing or able to treat Wikipedia as anything more than an extension of Indian media, and almost all of them either have a conflict of interest or are true believers.
3. The topic area is in an intractible ethnopolitical hellhole CTOP and tends to be connected to two potent third rails in that hellhole (caste and politics). This makes experienced users even more reluctant to touch the topic area and sets up new users for failure (CTs are the worst places to learn to edit; the intractible ethnopolitical hellholes especially so).

The ways to fix this would require, at a minimum, ECR in the immediate term. This is a very similar blend to the situation that caused WP:ARBPIA3 to happen. Once that is set up, and the firehose of edits to the area is slowed to a more manageable amount, there needs to be a community-wide effort to assess the articles for neutrality and COI concerns, with anything failing the test being sent to AfD if they cannot be improved. Anyone trying to disrupt this with nationalist, LLM, or COI bullshit needs to be at minimum topic-banned from the cinema topic area. Anyone evading these bans needs to be indef'd and restricted to one account, if that is possible as a discretionary sanction. (For anyone thinking about what precedent I'm looking at, SCI and MM are moreso what I'm looking at than any of the 17 PIA cases.) If this disruption continues despite everything, haul the mess to ArbCom, with an eye primarily towards amending CT/SA to make ECR de jure in the topic area indefinitely. —Jéské Couriano v^_^v ^{Thriller Night!} 06:52, 28 October 2026 (UTC)

@Jéské Couriano; I appreciate the clarification. Unfortunately, my experience over at CCI tells me that community cleanup efforts are vastly outpaced by the pace of crap added or the size of things to review without serious political and social capital. Doug Coldwell's whole pile of crap GAs isn't even fully cleaned up yet. A lot of what you're saying about CT restrictions, but we have a critical lack of capacity that is making everything worse. Treating admins poorly will not help the issue (I'm not accusing anyone, but it is a fear expressed to me). I just don't know what we can do that doesn't amount to "bully administrators into doing things they actively resent doing", since we have always been hesitant to elect admins focused heavily in "experienced user conduct" (a phrase from my own RFA).

As for cleanup: Chunking down Indian cinema to specific subtopics (ie. telugu films, marathi TV) with aggressive presumptive removals would lead to less reviewer/community burnout. It could also be turned into an editathon or drive. This level that's being described means that something much more drastic than a methodical combing and AFD can resolve without exhausting significant portions of the community. Despite my criticisms and counter-suggestions, there's a lot of good ideas here, and I think I know some things that I can angle people with more capacity than myself to get started on regardless of the outcome here. I myself am not experienced enough with background conflicts to admin fully in CT/SA, like you've described. I can handle blatant POV pushing and caste warring, but I've had to call in help from multiple sources both wiki editors and not to even begin on trickier reports. It's an issue and the more that you know here, the more you're likely to end up WP:INVOLVED. Sennecaster (Chat) 22:55, 28 October 2026 (UTC)

I would imagine the scope of the issue would more or less mandate that the subtopic be further broken up into further subtopics in order to actually deal with it. "Indian cinema" is the sort of overly-large topic area that ArbCom themselves comments about at WP:ARBIMH#Breadth of topic bans, and experiences with one subset of it don't necessarily translate well to other subsets (h/t Athanelar). The editathon/drive idea would certainly help as well (to get out in front of "how about AFI?", that to me seems more of a mixed bag, but it'd be worth a try for some of the lesser-known articles in the area that haven't drawn mercs or zealots), but this would fall into the same issue of anyone not "read in" being driven off by mercenaries and "true fans". Hence I think there would need to be an ECR in order for us to even entertain any such cleanup. The other alternative is going scorched-earth on users in the topic area to get rid of the UPEs, and that's counter-productive and would be a waste of admin time even if it weren't. —Jéské Couriano v^_^v ^{Thriller Night!} 00:39, 29 October 2026 (UTC)

I was thinking that setting up a tracker within the task force page could be helpful with cleanup - after restrictions are in place, because people will absolutely get driven off if they attempt it now (hi). Having a system to mark what's been reviewed, tagged, nominated for deletion, etc would help give a visual representation of progress and motivate people because they could see that even small contributions can move the needle. Maybe a bot could move pages through in batches to address the backlog in a format that feels manageable. ChompyTheGogoat [ Bleat | Munched ] 01:02, 29 October 2026 (UTC)

That would help, but the overall scope is the bugbear here. Going through it one subtopic at a time is still going to be the best way to handle this. This is an issue that has been festering for years; a quick fix at this point is unrealistic. —Jéské Couriano v^_^v ^{Thriller Night!} 01:44, 29 October 2026 (UTC)

Oh, I know. That's just one idea that could potentially help with working through content. Restrictions and above all willing editors are necessary if any progress is going to be made at all. ChompyTheGogoat [ Bleat | Munched ] 02:59, 29 October 2026 (UTC)

RFC for Dog

I started an RFC at Talk:Dog#RFC on lead image. Please join in the discussion. Wolverine X-eye (talk) 10:30, 24 October 2026 (UTC)

There's an innovative idea about automagically rotating the image, so we can have a big photo without having to choose just one photo of just one dog to represent all of them. WhatamIdoing (talk) 04:55, 30 October 2026 (UTC)

On a DYK article's Talk page, remove the Do not modify this page notice from the Talk page's DYK Nomination section

note: to see an example of the current state of what causes the problem

1. Go to the Wikipedia Main Page.
2. Select any of the articles in today's DYK list.
3. Look at that article's own Talk page.

This numbered sequence of successive events illustrates how the problem happens:

1. An article is nominated to be included on the Wikipedia Main Page article list Did You Know...?
2. The article has a Talk page (Talk_A).
3. In a different place, there is a DYK Nomination discussion of the article.
4. The DYK Nomination discussion (Talk_N) ends.
5. Talk_N receives a header that says Do not modify this page (intended to prevent the modification of Talk_N).
6. Talk_N is reproduced as a section on Talk_A.
7. Now, Talk_A has a section that says Do not modify this page (intended to prevent the modification of Talk_N).
8. Eventually, Talk_A needs to be modified.
9. A user (User_A) who needs to modify Talk_A sees a section of Talk_A (described in 6. above) that says Do not modify this page (intended to prevent the modification of Talk_N).
10. User_A understands this prohibition (against the modification of Talk_N) to mean that modification of Talk_A is forbidden.
11. User_A leaves Talk_A unmodified for the sake of obeying the directive that had forbidden modification of Talk_N.
12. A confusing message has prevented User_A from accomplishing Wikipedia's mission; this is a serious problem.

Let's fix this problem! —catsmoke ^talk 05:18, 27 October 2026 (UTC)

@Catsmoke I made this edit to {{DYK top}} so that on talk pages it will say "Do not modify this section" instead of "this page". That won't fix existing pages, but it should fix it for ones created in the future. A bot task would be needed to fix existing ones by running through the 78,000 subpages at Special:PrefixIndex/Template:Did_you_know_nominations/ and replacing page with {{talk other|section|page}} -- you can request one at WP:BOTREQ. --Ahecht (TALK
PAGE) 17:16, 27 October 2026 (UTC)

I feel kind of weary transcluding {{talk other}} so many times. Couldn't this be achieved with <noinclude> tags? Axolitl (talk | contribs) 23:43, 27 October 2026 (UTC)

Or alternatively, something like "Please don't modify the nomination"? Axolitl (talk | contribs) 23:45, 27 October 2026 (UTC)

I'm not sure what exactly the aversion to using {{talk other}} is when it's already transcluded on nearly 5 million pages. Adding 80,000 DYK pages to that number is a negligible increase. --Ahecht (TALK
PAGE) 19:24, 29 October 2026 (UTC)

Apple

I belive that searching up "Apple" should take you do a disambiguation page, showing both Apple Inc. and Apple, as in the fruit. Both are very common topics, and I belive neither should have a primary position.

Yes, Apple has trillions of dollars. But, the fruit is often more common in daily conversation. ThejimsterF (talk) 08:59, 27 October 2026 (UTC)

ThejimsterF Nothing wrong with coming here, but this is probably best discussed at Talk:Apple. I'd suggest that you review the several prior discussions on this very topic(linked to at the top of the talk page) before proceeding with such a discussion. 331dot (talk) 09:09, 27 October 2026 (UTC)

Per the Q&A on the Apple talk page, "In at least 6 move discussions (see the list below) on this page, Wikipedia editors have determined that the fruit is the primary topic, so disambiguation is not required.". So it seems like this has been discussed and settled. I'm not sure how long it's been though, or if circumstances have changed. I can do stuff! (talk) 21:16, 28 October 2026 (UTC)

25th Anniversary Logo

I propose temporarily changing the Wikipedia logo for the 25th anniversary to be the one shown above. As you can see on this page, it is an unofficial logo for the 25th anniversary.

The actual website has a different logo, which only has the wordmark and a puzzle piece with "25" written above it.

The reason is that the logo is very iconic and should be kept. It symbolizes what the standard globe already symbolizes (the diversity and evolution of Wikipedia), but it also acknowledges the 25 years of Wikipedia's existence.

Some language versions like the German Wikipedia use a similar logo.

This is temporary (until January 15th, 2027), only affects the English Wikipedia, and would replace the current wordmark logo. Koubaki (talk) 14:57, 27 October 2026 (UTC)

We've already changed it to wikipedia-wordmark-en-25.svg in the vector2022 (desktop default) and minerva (mobile default) skins and the exact logo you posted in the vector2010 (desktop default prior to 2022) skin. This is consistent with vector2022 and minerva using the wordmark in place of the globe logo. --Ahecht (TALK
PAGE) 16:41, 27 October 2026 (UTC)

As you can see here on Vector 2022 before the 25th anniversary there was a globe. Koubaki (talk) 19:21, 27 October 2026 (UTC)

I believe we went with the horizontal wordmark as it was one of the default options created by the WMF. It allows the tagline to stretch along the entire image. de.wiki gets lucky because its tagline doesn't need "of the". CMD (talk) 22:42, 27 October 2026 (UTC)

That's probably why the logo I'm proposing uses "Celebrating 25 years" as its tagline. Koubaki (talk) 10:13, 28 October 2026 (UTC)

@Koubaki I slightly misspoke, but it did not use the full-height globe, it used a logo that was primarily the wordmark with a small globe icon next to it. --Ahecht (TALK
PAGE) 19:20, 29 October 2026 (UTC)

I'm aiming for something like the German Wikipedia, with only the tagline changing to "Celebrating 25 years". Koubaki (talk) 19:47, 29 October 2026 (UTC)

I support using this logo. GreatWhiteEditor (talk) 20:55, 29 October 2026 (UTC)

I would have supported this earlier, but it seems rather silly to change it at this point when the year is nearly over. ChompyTheGogoat [ Bleat | Munched ] 22:02, 29 October 2026 (UTC)

Agreed. Axolitl (talk | contribs) 22:36, 29 October 2026 (UTC)

Proposal for section-level page protection

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I would like to propose a feature that allows administrators to protect only a specific section of an article instead of protecting the entire page. Sometimes, vandalism happens only in one section of an article, while the other sections remain fine. Protecting the whole page can prevent good-faith editors and trusted users from improving the rest of the article. With section-level protection, administrators could protect only the section affected by repeated vandalism while allowing everyone else to edit the remaining sections. This could help reduce vandalism while allowing editors to continue improving articles. I understand that this feature may require technical changes, so I would like to know whether it is possible to implement it on Wikipedia.

What do other editors think about this idea? Foxy-Voxy (talk) 17:20, 29 October 2026 (UTC)

Almost certain to be more trouble than it is worth. Vandals will find ways around this (some are obvious, though per WP:BEANS I'll not state them here), or simply vandalise something else. AndyTheGrump (talk) 17:25, 29 October 2026 (UTC)

No no.. but I think the proposal addresses a different problem. For example on articles about public figures, the controversy section may be repeatedly targeted for removal sometimes due to promotional interests or pressure from the subject's representatives. As a result, the entire article may end up fully protected, preventing even trusted users TAs and autoconfirmed editors from editing other sections. My suggestion is not that section-level protection would stop all vandalism. Rather it could allow administrators to restrict editing only in the section experiencing repeated disruption while keeping the rest of the article open to constructive contributions. This would give administrators another option instead of having to protect the entire page. Foxy-Voxy (talk) 17:31, 29 October 2026 (UTC)

'Controversy sections' are strongly discouraged in articles: WP:CRITS. Allowing them to be selectively protected is an active encouragement to keeping an article badly structured. AndyTheGrump (talk) 18:15, 29 October 2026 (UTC)

If it's mechanically possible, it would be nice to have as an option. There would be no downside to the capability, and though the upside may be not the most often, it may be worth it. Especially for high profile articles on explosive modern events (think the Kirk shooting) where it can be a good idea to be able to leave the GENERAL body of the article open - but slam EC on a section. — VPP (t/c) 17:52, 29 October 2026 (UTC)

I think this would fall under the same issues as WP:PEREN#Allow watchlisting individual sections of a page. —Jéské Couriano v^_^v ^{Thriller Night!} 18:29, 29 October 2026 (UTC)

A version of it is mechanically simple via subpages and transclusion, which is common in the project space, but that this is not done in the article space seems a clear sign the community doesn't find it a good idea. CMD (talk) 03:31, 30 October 2026 (UTC)

As I discussed, this doesn't achieve the original commenter's goal of preventing vandalism to a section without protecting the entire article, since someone can still vandalize the section by replacing the transclusion. isaacl (talk) 16:27, 30 October 2026 (UTC)

Or they could comment out the transclusion and insert a modified version of the text, and 95% 9f it will look the same. When there is a will... Yesterday, all my dreams... (talk) 17:22, 30 October 2026 (UTC)

Of course almost anything is theoretically possible in software, but it might be too costly or impractical to change. At its core, MediaWiki is built on pages as the smallest managed unit of content, including version control, traceability, and access control. Changing this would be a drastic change. Either the underlying storage format has to be changed from wikitext to something that has the concept of managed subunits, or articles become an aggregation of individual managed wikitext components.(*) Both of these approaches would have a significant impact on the conceptual model for editing and thus the user interface, and require all tools reliant on parsing the underlying wikitext to be modified. Personally, I don't think it's practically feasible.

(*) We can manually compose articles out of transcluded pages now, but the main article still has to be protected to avoid vandalism, regardless of the protection levels for the subcomponents. isaacl (talk) 21:13, 29 October 2026 (UTC)

Are there examples where this would have been useful? It sounds so incredibly easy to workaround that I can't imagine the change being worth the trouble. Even if the option were easily available, the complexity of the user interface for admins to follow may not be worthwhile. Johnuniq (talk) 03:02, 30 October 2026 (UTC)

Yes, and the complexity of the software that would "effectively" enforce it would be pretty high. So the level of trouble you mentioned will be high if it is going to work right. Yesterday, all my dreams... (talk) 03:27, 30 October 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

COI edit request backlog drive

In previous discussions at WP:AN, most recently WP:AN#Nearly 1000 outstanding COI edit requests (over 1,320 as of writing this post), attention has been brought to the concerning state of the COI edit request backlog, and an initiative for a backlog drive has now sprung up, with preparations taking place at the newly-revived WP:WikiProject Edit requests.

I would expect December or January to be the target for holding the drive, as, to the best of my knowledge, there are not too many other things scheduled then.

I come here to give a broader audience of editors the opportunity to provide input, and also to seek any help that people might be able to lend, especially from those with experience organizing these things. –Maltazarian ^{ᚾparleyinvestigateᛅ} 01:10, 31 October 2026 (UTC)

RfC on the talk header

Should the talk header (shown in § Example below) appear atop the talk page of any non-redirect article that contains one or more discussions?

• A – Yes, and I have no opinion on how this should be implemented.
• B – Yes, but only if this is implemented via a bot that automatically adds the {{Talk header}} template atop eligible pages. (Just like other bot edits, this can be turned off on specific pages.)
• C – Yes, but this should preferably be implemented via a MediaWiki feature without using a bot. If a native feature proves technically infeasible, this should still get done through other means, like a bot.
• D – Yes, but only if we are able to implement this via a MediaWiki feature without using a bot. If this proves technically infeasible, then I oppose this proposal.
• E – No.

23:48, 1 November 2026 (UTC)

Example

See example

Survey (talk header)

Blank message so reply tool works 1brianm7 (talk) 00:50, 2 November 2026 (UTC)

• Option E. The header contributes to banner blindness for little benefit, option D if absolutely necessary. 1brianm7 (talk) 00:50, 2 November 2026 (UTC)
• Option E. Like what many have said, I think this will only worsen the issue of banner blindness. I will say that this probably can be implemented with MediaWiki:Talkpageheader. Axolitl (talk | contribs) 01:12, 2 November 2026 (UTC)
• E > D > B. I’m not convinced we need to add it to every talk out there. I might support making part of the default. Dw31415 (talk) 03:33, 2 November 2026 (UTC)
• Option E - banner blindness is real. Many less-frequented pages do not need this bloat. Ealdgyth (talk) 13:43, 2 November 2026 (UTC)
• Option E per Ealdgyth. We need to take steps to decrease the number of talk page banners; this proposal would be a massive step in the wrong direction. Best, HouseBlaster (talk • edits • he/they) 19:27, 2 November 2026 (UTC)
• Option E per what I said last time. Graham87 (talk) 08:49, 3 November 2026 (UTC)
• Option E. No objection to the header, but no need for it to be imposed everywhere. Cabayi (talk) 09:20, 3 November 2026 (UTC)
• Option E Thanks but absolute no to automatic banners which generate clutter and arguments. If new users need hints on what to do, that should be shown only to them with an opt-out. Johnuniq (talk) 01:27, 4 November 2026 (UTC)

Discussion (talk header)

Perhaps the original poster could add a background section, where they can discuss the motivation behind each of the proposed options? What problem is being addressed? isaacl (talk) 00:07, 2 November 2026 (UTC)

This appears to be the RFCBEFORE discussion: Wikipedia talk:Requests for comment#How should these be handled?. I agree with Isaacl that a background section would be helpful here. Some1 (talk) 01:25, 2 November 2026 (UTC)

Voting E feels slightly pointless as this sort of template spreads mimetically regardless of its actual value, but at the same time I see no reason to speed that process along with a bot. CMD (talk) 00:55, 3 November 2026 (UTC)

Consistency in placement of infobox titles

In Template:Infobox#Content_parameters, it lists two ways to put a title on an infobox; inside the infobox's border or on top of the infobox. Therefore different infoboxes alternate between the two: Template:Infobox software and Template:Infobox organization for example. There are also color difference, where some titles within infoboxes have no background color while some such as Template:Infobox_OS do. Currently there is no guidance on which of these is optimal.

Furthermore, this is changed often without consensus such as here in Template:Infobox company. It has resulted in some articles looking cluttered, especially when the logo of a company is in black text like Samsung Electronics.

This proposal aims to set a consistent placement and color of titles to ensure uniformity across the encyclopedia and to improve clarity by reducing visual clutter. There should ideally be one way to place the title with room for color changes if inside is decided to be optimal. Update6 (talk) 04:32, 2 November 2026 (UTC)

I don't see any point having a title for an infobox that is identical to the title of the article. Why does Wikipedia do that? I do see that Template:Infobox says it is "not recommended" to have neither an "above" nor a "title", but there is no recommendation against using both (which would seem like a better thing to recommend against).

There is at least one infobox that doesn't automatically produce a title, {{Infobox ship}}. See Titanic for an example without a title and Cutty Sark for one with a title. It looks like there are only 3590 of 43,000 ship infoboxes with a title.

While searching for any discussion about why we recommend against not having a redundant title for an infobox (which I haven't yet found), I came across Wikipedia_talk:Manual_of_Style/Archive_115#Infobox_headings which also is about the inconsistency in above/titles for infoboxes (and also has an editor pointing out there neither is typically very useful). Plantdrew (talk) 18:40, 4 November 2026 (UTC)

Another prior discussion about the inconsistency: Template_talk:Infobox/Archive_15#Standardisation_of_heading?, and another questioning the need for anything: Template_talk:Infobox/Archive_6#Infobox_headings. Plantdrew (talk) 18:48, 4 November 2026 (UTC)

When the article contains multiple infoboxes, such as when the article covers multiple related subjects, a title can make it clear which element the infobox relates to (Marylebone station is a poor example). Infoboxes for multiple pieces of legislation related to a topic also come to mind, as at Deeside Railway. However these are an argument only for not removing a title parameter completely not against discouraging in cases where there is a 1:1 correspondence between article topic and infobox topic. Thryduulf (talk) 20:47, 4 November 2026 (UTC)

RfC on proposals to reduce the NPP backlog

An RfC on changes to NPP is now open at Wikipedia:New pages patrol/2026 backlog discussion/RFC phase

It involves a series of proposals for changes to the NPP process. The intention of these proposals is to reduce the NPP mainspace article backlog, which has been steadily growing and recently exceeded 30,000 unreviewed articles.

Proposals in this RfC (Σ = 10)

#	Topic	Options	Result	Note
Autopatrolling articles
1	Autopatrolling articles based on age	5
2	Autopatrolling articles approved by AfC	2
Autopatrolled criteria
3	Reduced requirements for autopatrolled	4
4	Alternative pathway for autopatrolled	4
Draftification and NPP
5	Draftification permissibility	3
6	AfC for articles draftified by New Page Patrollers	2
Other
7	Partial reviewing	2
8	Notability reviewing	4
9	Title reviewing	2
10	Unreviewed status visibility	2

07:00, 2 November 2026 (UTC)

Cleanup drive for MOS:LANG

I found out about MOS:LANG not too long ago, and it seems to be one of the least implemented parts of the MOS. I am thinking that regular cleanup drives could be useful. Apart from articles already tagged with {{Cleanup lang}}, obvious targets would be articles in subcategories of Category:Words and phrases by language, Category:Cuisine by country and similar categories.

I also recently learned about {{title language}}, and the ability to use DISPLAYTITLE to tag only part of a title with {{lang}} (which {{title language}} doesn't allow). That should be part of this cleanup drive as well; I think it is still common that non-English titles are either not italicised, or italicised only with {{italic title}}.

I'm not aware of any such drive at the moment. I hope there is interest in one, or at least that some more editors will take on this task. There is so much untagged non-English text! Helpful Cat🐈 14:06, 3 November 2026 (UTC)

Wikidata should have an "image of actor" property for live action characters

The same way Wikipedia uses the "image of cosplay" property as a compromise for character that don't have a free image

Some entries for characters mistakenly use the "image" property to show an image of the actor out of character anways OxyLight (talk) 05:18, 5 November 2026 (UTC)