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

RfC: Name of the "Discussion" button

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

15 years ago the "Discussion" button was changed to "Talk", in an attempt to encourage participation from new editors. Since then no evidence has been presented in this discussion that this change achieved it's aims. Irrespective of that, there is consensus against changing this back to Discussion, based on a similar mentality. As this discussion may well resurface again in another 15 years of sooner, I'll do my best to summarise the arguments within, or at least those that appeared noteworthy.

The supporters cited consistency with other wikis, the "Talk" connotation regarding AI chatbots, as well as "Discussion" being more recognisable, intuitive, as well as the intended function of the page. The opposers highlighted that there is no evidence that this solves the suggested issues, such as misuse of talk pages and misunderstanding their purpose, and that it remains consistent with the Talk namespace. Further into linguistics, talk and discuss were described as synonyms, while the overview naming convention was also considered to be not broken. Naysayers criticised speculation regarding positive change, along with concerns over implying broader discussion than talking solely about the article. Also that Talk headers exist to clarify the purpose of the page.

As an alternative, over a dozen supporters and opposers (to changing to "Discussion") supported "Talk page", but this wasn't enough to sway the naysayers, otherwise known as the overall sentiment for consensus to not change the button name at present. At around 2:1 with arguments slightly more valid(*) than supporters (who failed to demonstrate evidence of the benefits of such a change), it's noteworthy from a closing perspective that a sizeable portion of both Yays and Nays supported an alternative here. This alternative may therefore benefit from further discussion, but bare in mind that the majority of opposers still did not support this alternative. (*)Naysayers failed to provide demonstrable evidence of why the current Talk button name is better, but the onus wasn't on them to do so for supporting the status quo, thus I considered the support arguments to be slightly weaker.

An interesting take towards the end of the discussion from InfiniteNexus was to Show "Discussion" for signed-out users and new accounts; show "Talk" for established accounts when signed in; retain "Talk" as the name of the namespace, but nobody appeared to take an interest in this alternative proposal, apart from myself. Also discussion on changing the namespace occurred, with lack of support generated. Finally quick plug for related RfC on adding talk headers to existing talk pages, for those unaware and also interested. (non-admin closure) CNC^{in solidarity} (talk) 16:52, 23 October 2026 (UTC)

---

Fifteen years ago, we decided to change the label of the "Discussion" button to "Talk". Should we change it back to the default label? 16:03, 3 September 2026 (UTC)

Current label

Default label

Survey (button name)

Yes. And other language Wikis usually say discussion, eg Italian, French etc. Yesterday, all my dreams... (talk) 16:07, 3 September 2026 (UTC)

Yes (ETA: if "Discussion" does not pass, my second choice is now "Talk page". 23:48, 27 September 2026 (UTC)) because:

• More and more of our readers are assuming that the "Talk!" button on our articles takes them to an AI chatbot.
• As was explained below, users are mistaking it for text-to-speech. Most online news articles nowadays have a button that reads the article aloud for them.
• Most people reading foreign Wikipedias probably have a decent grasp of the language, but enwiki is the largest and typically attracts more non-native speakers. "Talk!" is more recognizable than "discussion" and it's also an imperative verb.
• "Talk" is the more opaque of the two terms for newcomers, which further helps to hide its intended function, which is to "discuss" how to improve the article itself, not to "talk" about the topic of the article. "Talk!" also has a broader meaning and can be used in context where "discussion" cannot.

FaviFake (talk) 20:56, 3 September 2026 (UTC)

I have already seen these reasons, no need to ping in an edit summary please. --ABx11 (she/they) 00:44, 4 September 2026 (UTC)

If it moves the needle even a teensy tiny bit, please god yes. I feel like I am the only person monitoring these, it is one of the few places on Wikipedia that actually DOES have a deadline (since you have to remove it before the archive bot gets it, otherwise you aren't allowed to clean it up anymore, joining the nearly 6,000 instances of enshrined untouchable vandalism), and I am so, so, so behind on it. Gnomingstuff (talk) 20:58, 3 September 2026 (UTC)

@Gnomingstuff: re: "you aren't allowed to clean it up anymore" - says who? Where and when was that decided, and was there broad participation? A rule that requires vandalism to be enshrined sounds like a really bad rule and one that should be reconsidered. HierophantOfOmens (talk) 07:12, 5 September 2026 (UTC)

Please do not ping me to a discussion I am obviously aware of given that I commented in it 5 minutes ago. If I want to look at a discussion, then I will do so on my own time. If I am not currently looking at a discussion, then I'm probably doing something else that I would prefer to not be interrupted during. In this case, it was doing the cleanup this whole thread is about, and now I am not doing it, all thanks to your ping.

The RfC was here. Gnomingstuff (talk) 07:15, 5 September 2026 (UTC)

I don't see how one interprets "There is no consensus one way or the other regarding editing talk page archives for any other reason, such as removing a nonsense post that was not reverted prior to archiving ... This close should not be construed as limiting removal of content from archives for other policy-based reasons, such as the legitimate use of oversight or revision deletion, nor should it be construed as affecting the reversion of vandalism to archives, which I don't believe was ever really in question here" (from the RfC close) as meaning "you aren't allowed to clean it up anymore", or that there is any such thing as "enshrined untouchable vandalism". Levivich (talk) 07:24, 5 September 2026 (UTC)

The RFC's closing statement begins: "There is consensus that talk page archives can be edited to remove material that breaches policy, such as copyvio, libel, and serious personal attacks..."

The first link in "the nearly 6,000 instances of enshrined untouchable vandalism" adds a racial slur to someone else's comment. That's obviously something that should be fixed (if it hasn't already been).

Mostly, when I see this kind of comment, though, I'm reminded of User:Betacommand, whom we tasked with tagging WP:NFCC violations. Then we left him to deal with the social fallout all on his own, and it turns out that having the technical skills to find and tag various files did not automatically give someone an endless supply of patience and kindness to people who felt entitled to ignore the legal policies, or at least to yell at someone before making a show of how they're grudgingly complying with these completely unnecessary, overly picky rules. It did not end well. I am concerned that we are doing the same thing to our AI defense folks. WhatamIdoing (talk) 20:35, 5 September 2026 (UTC)

You know, having learned to dabble (a tiny bit) in the site API... I bet you USD $1 that list of 6000 is bigger. — Very Polite Person (talk/contribs) 14:52, 5 September 2026 (UTC)

It absolutely is much bigger, I just have not been doing as much talk page cleanup because I only have so much time between that and AI cleanup. If you count stuff that I have found and fixed before archive bots strike then I suspect the number is in several tens of thousands. Gnomingstuff (talk) 17:47, 3 October 2026 (UTC)

Also support “Talk Page” as a next-best option

Because something has to be changed, and this discussion is like that Onion article “There Is a Huge and Intractable Problem with People Thinking ‘Talk’ Signals a Chatbot/Text to Speech” vs “No, There’s Not (There’s Just Not)” Gnomingstuff (talk) 17:45, 3 October 2026 (UTC)

If you believe that the opposition to "Discussion" is just No, There's Not (There's Just Not) then you either haven't read or haven't understood the opposing viewpoints. While there are some people who are disagreeing that the problem is a significant as proponents for change claim, the more substantive objection is best summed up as "Changing "Talk" to "Discussion" will not solve the chatbot problem, but it will cause other problems". Thryduulf (talk) 21:23, 3 October 2026 (UTC)

Yes to simply renaming the visual presentation of the clickable buttons from "Talk" to "Discussion". Very good idea. We have no justification, need or reason to be the weird outlier versus other wikis, and per other arguments here. — Very Polite Person (talk/contribs) 22:41, 3 September 2026 (UTC)

No per Maddy from Celeste and Very Polite Person below. Firstly there is no evidence that this will solve the problem it attempts to - everybody who thinks "talk" means "discuss this article with a chatbot" will think "discuss" means "discuss this article with a chatbot" so we gain nothing. Secondly the 2011 change was made for a good reason and that reason still exists, we will still refer to the page as a talk page and that will still confuse new editors who cannot find a button for a "talk" page, so we will lose significantly here - possibly even more than we were doing in 2011 as we are facing a bigger editor recruitment problem now than we were then. Thryduulf (talk) 22:50, 3 September 2026 (UTC)

No per ... Very Polite Person below.

I'm confused. Very Polite Person has always supported this proposal from the start, saying it's a very good idea. You're the first person to oppose. FaviFake (talk) 22:59, 3 September 2026 (UTC)

That's because I misattributed a comment, my opposition is per Anomie not VPP (my apologies to both). Thryduulf (talk) 23:05, 3 September 2026 (UTC)

How dare you, etc. All good. — Very Polite Person (talk/contribs) 00:16, 4 September 2026 (UTC)

• No - Using a different word (“Discussion”) on the tab we click to reach the article’s TALK page makes no sense to me. I would expect to click on a tab reading “Talk” to reach the article’s TALK page. Blueboar (talk) 23:26, 3 September 2026 (UTC)

  Which, incidentally, would also be the button you'd expect to click in order to talk with other users (or with a chatbot) about the topic, or to have the article automatically read aloud to you... FaviFake (talk) 23:34, 3 September 2026 (UTC)

  Nah… to have the article read out loud I would expect a “Read out loud” button. Blueboar (talk) 18:12, 3 October 2026 (UTC)

  Sure, but if you had to choose between "Talk" and "Discussion", you would click "Talk", as in "Page, talk to me!".

  Anyway, would you support the alternative Talk page which has been proposed below? FaviFake (talk) 18:32, 3 October 2026 (UTC)

  I see them as the same, so… meh… I really don’t care. Blueboar (talk) 21:08, 3 October 2026 (UTC)

  If all the other equivalent encyclopedias apparently use their native tongue "Discuss", why wouldn't we want to be doing it how the others are? — Very Polite Person (talk/contribs) 00:18, 4 September 2026 (UTC)

• Yes per Favi and Gnoming, "discussion" is much more intuitive, and we should be targeting readers' and newbies' experiences here. One of the faults of our decision-making process is that only experienced editors participate and prioritise their own experience. Kowal2701 (talk, contribs) 00:14, 4 September 2026 (UTC)

  The argument in favor of Talk, both in 2011 and now, is that "Talk" is more intuitive since it's the name of the namespace, and it's what everyone calls it, and that it would be better for readers and newbies to therefore have the button called "Talk." They're not prioritizing their own experience, they're targeting readers' and newbies' experiences.

  So does anyone on either side of this debate have any actual data to present, or are we just voting based on our own personal experience/opinion of what is less confusing for others? Levivich (talk) 01:54, 4 September 2026 (UTC)

  True, and it's the latter, no idea if there's a way to request data collection via survey (there should be) Kowal2701 (talk, contribs) 02:42, 4 September 2026 (UTC)

  Do the however many tens of thousands of prompt junk posts I have reverted count as data? The neverending deluge of stuff like this day after day after day, hundreds per week, thousands per month. Gnomingstuff (talk) 06:58, 5 September 2026 (UTC)

  No. I'm not talking about data that people misuse talk pages, anyone that's read some knows that. I'm talking about data about the button label. That edit wouldn't be prevented if the button was called "Discussion." A survey, as Kowal suggested above, and A/B testing, as CMD suggested in the discussion section below, could bring useful data, though. Levivich (talk) 07:12, 5 September 2026 (UTC)

• (edit conflict) Weak no because while talk might suggest that the Talk page is for discussing the subject of articles, discussion isn't better in this regard. Of course, if the proposer has a better idea or wishes to clarify, I am open to changing this vote. --ABx11 (she/they) 00:17, 4 September 2026 (UTC) Hard no. The only reason that has been presented to me via a ping isn't sufficient as I had already seen these reasons. And after seeing the arguments against it presented elsewhere, I'm convinced that this might cause confusion, and frankly, I'm not even convinced that it even helps in this regard. --ABx11 (she/they) 21:22, 5 September 2026 (UTC)
• No per Maddy from Celeste BilledMammal (talk) 00:19, 4 September 2026 (UTC)
• No per Blueboar, Thryduulf, et al, and per the 2011 discussion that lead to the change to "Talk" in the first place. The conclusion drawn then remains very much valid. A tab leading to the Talk: namespace should be labeled "Talk".

Plus I think the idea that somehow "Talk" leads people to think it's a chatbot and "Discussion" will not is an unfounded conclusion. That really would need some sort of actual supporting evidence besides anecdotes, because I haven't seen any such activity. (I have seen many cases where none-too-bright people for some idea think it's a page for contacting the subject of the article, but that can be dismissed as clear lack of competency.)

Finally, what other language Wikipedias do is irrelevant. Each language Wikipedia is a separate entity. Yes, a lot of them use the cognate of "discussion" for that tab. But they also use that cognate for the namespace for their discussion pages. Which circles back to the whole reason the English Wikipedia tab is "Talk". It matches the namespace. To change the tab and not the namespace makes little sense. Either change both or change neither. Changing only one creates unnecessary confusion. oknazevad (talk) 00:41, 4 September 2026 (UTC)

Furthermore, Talk and Discuss are synonyms, so I'm not seeing the tangible benefit. --ABx11 (she/they) 00:44, 4 September 2026 (UTC)

• No Way, way too many references to "the talk page" litter the database and help guides. This would make "the talk page" harder to find and I don't see the value. * Pppery * _{it has begun...} 03:11, 4 September 2026 (UTC)
• No Fiddling with labels won't help people who are unfamiliar with Wikipedia. Having a discussion button that leads to talk is confusing (absurd, actually). Discussion invites commentary even more than talk. Johnuniq (talk) 06:17, 4 September 2026 (UTC)
• No (summoned by bot) Fiddling with labels won't help people who are unfamiliar with Wikipedia. Having a discussion button that leads to talk is confusing To the extent that there may be a problem (not sure of that), this isn't going to provide an answer IMO. All websites have their particularities and at least WP doesn't periodically reframe its appearance for trivial reasons. Pincrete (talk) 07:50, 4 September 2026 (UTC)
• (summoned by bot) No per oknazevad and Pppery. As others have said, what other Wikipedias do is irrelevant, it would lead to more confusion from newbies, and it wouldn't decrease confusion with AI chatbots. Kovcszaln6 (talk) 10:19, 4 September 2026 (UTC)
• Yes "Discussion" is a noun, while "talk" is a verb. Velocifyer (talk) 17:27, 4 September 2026 (UTC)

  From the Merriam Webster dictionary: "Talk: noun ... 4: a formal discussion, negotiation, or exchange of views —often plural" - Donald Albury 19:02, 4 September 2026 (UTC)

  They probably meant to say that "Talk!" can also be interpreted as a verb while "Discussion" can only be interpreted as a noun. FaviFake (talk) 19:40, 4 September 2026 (UTC)

• No Perhaps a bit counterintuitively, contra some of what is said above, "discussion" would lead new people to think it's a place for discussing the article in general i.e. a forum. Jahaza (talk) 20:57, 4 September 2026 (UTC)
• No I do not see a net positive from making the change. - Donald Albury 23:23, 4 September 2026 (UTC)

  I consider "Talk page" to also be acceptable. Donald Albury 18:55, 13 September 2026 (UTC)

• Yes, as a small but hopefully meaningful step in the right direction. I would also be open to changing this for a month or so, and seeing if there was any meaningful difference. Axolitl (talk | contribs) 16:22, 5 September 2026 (UTC)

  I would also support Talk page. Axolitl (talk | contribs) 04:09, 13 September 2026 (UTC)

• No per Thryduulf. —Kusma (talk) 20:49, 5 September 2026 (UTC)
• No. Ain't broke, so don't "fix" it. Seraphimblade ^{Talk to me} 01:33, 8 September 2026 (UTC)
• Talk page. (see ExtantRotations' comment below) I think this is unambiguous and less likely to be confused with LLM slop chatting. I doubt this option will reach consensus, but "yes" and "no" are both bad choices as they have too many drawbacks. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 17:02, 8 September 2026 (UTC)
• No to "Discussion", Yes to "Talk page" per ExtantRotations. --Ahecht (TALK
  PAGE) 18:38, 8 September 2026 (UTC)
• Sure we can always change back again. 15 years seems an appropriate time to try something new. —TheDJ (talk • contribs) 22:22, 8 September 2026 (UTC)
• No. I don't mind causing confusion/alarm/despondency with a change if there's a clear benefit, but here I think it's just speculation to say that one of these words is better than the other. This would create a lot of fussing and complaining and I can't believe it would be worth it. Mike Christie (talk - contribs - library) 23:57, 8 September 2026 (UTC)
• No. I think that the term Talk describes the intended purpose adequately. GrinningIodize (you just lost the game) (talk) 22:35, 9 September 2026 (UTC)
• This is oddly specific, but I would permanently change the button to "Discussion" for only ChatGPT and the other articles on the AI chatbots. Why are people always Googling ChatGPT when they could use Google AI mode? For the other pages, lean yes as a trial. EDIT 02:41: Actually, yes, per FaviFake, and additionally because that's what Commons does as well. Also, I believe it should be made clear that only the button's name is changed, not the namespace. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 02:38, 11 September 2026 (UTC)

  There are way more of these than one would think, I've been requesting semi-protection on the most common offenders but new ones keep popping up

  worst of the lot are the ones on deepfakes because the prompts are specifically people asking for revenge porn Gnomingstuff (talk) 21:09, 13 September 2026 (UTC)

  FYI I'm okay with "Talk page", I know the inconsistency between ENwiki and the other Wikimedia projects will still exist, but I'm willing to compromise. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:51, 3 October 2026 (UTC)

• Oppose change to "Discussion". As User:Johnuniq said, the word "discussion" invites even more commentary than "talk", and it'll make it sound for new users like the comments section from a journalism site. Concerns of "talk" implying a chatbot is IMHO weird, because... how? At most, a new user would reasonably mistake it for a recommendations comment thread or help desk. Plus, {{Talk header}} exists and that cancels out most of the concerns with new users not understanding the purpose of talk page. Too many things in the encyclopedia says "talk page" and making a mandate to change that would be time-consuming and we don't need to fix what is not broken. I would support change to "Talk page" as per User:not-cheesewhisk3rs. In solidarity, Brynn Who Likes Editing | talk w/ me! 07:58, 11 September 2026 (UTC)

  Concerns of "talk" implying a chatbot is IMHO weird, because... how?

  I don't know what to say here, if people who actually do talk page patrol are telling you that this is a thing, then it seems at least worth considering that they know what they are talking about

  see also the edit histories of basically any even tangentially AI-related page, many of which (e.g. Talk:Google Gemini) have banners added by people who could tell you that this is a thing Gnomingstuff (talk) 21:11, 13 September 2026 (UTC)

• No The "Article" button takes the user to the page in articlespace. The "Talk" button takes the user to the page in talkspace. Giving more names to this space would likely just add to the confusion, and "Discussion" doesn't make the purpose much clearer either. Would likely support "Talk page" though. FlammablePizza (talk) 01:07, 13 September 2026 (UTC)

  Article and talk aren't the only namespaces though. On Wikipedia pages it says "Project page", in MediaWiki it says "Interface page", User says "User page" etc. Axolitl (talk | contribs) 04:08, 13 September 2026 (UTC)

  That being said, "Talk page" is a valid option. Axolitl (talk | contribs) 04:09, 13 September 2026 (UTC)

• No to "Discussion", Yes to "Talk page". I'm with others here that changing it to 'Discussion' would be unnecessarily confusing re: the discrepancy between that term and the namespace, as well as with all the existing references to talk pages that are all over essays, help pages etc. Changing it to "Talk page" seems to elegantly solve all of the issues that people have with "Talk" without running into the problems with "Discussion". Athanelar (talk) 00:47, 14 September 2026 (UTC)
• No with caveats as per Blueboar and the 2011 discussion, with my caveat being that we try and make sure all talk pages have the this is a talk page notice for new users. I don’t know if there’s a tool for speeding that process up, though I’m sure it’d be easy to implement in tools such as rater, though that is a separate discussion.Edlectro28 (talk) 15:42, 22 September 2026 (UTC)

  Unfortunately that's controversial and we would need a different RfC for that, but, luckily for you, I'm already working on it! Please feel free to comment at WT:RFC § Add the Talk header template to existing article talk pages before the RfC goes live. FaviFake (talk) 15:48, 22 September 2026 (UTC)

  I got carried away! Anyway, my no still stands, and that’s great timing and thanks for letting me know. I’ll be sure to say my piece over there. Edlectro28 (talk) 15:52, 22 September 2026 (UTC)

  Perfect! (To clarify, the actual RfC will happen on this page, that's just the workshop discussion.) FaviFake (talk) 16:06, 22 September 2026 (UTC)

  Thanks Edlectro28 (talk) 16:08, 22 September 2026 (UTC)

  Change to "Talk page" as this can solve the problems mentioned in this RFC and the one 15 years ago. Szxq (talk) 04:08, 23 September 2026 (UTC)

• Oppose "Discussion" per the 2011 discussion; Support "Talk page". "Talk page" would match the style of tab name used on other Wikipedia interface instances, and would be even less likely to be confused for discussing with a chatbot than either "Discussion" or the status quo "Talk". Regards, User:TheDragonFire300. (Contact me | Contributions). 05:16, 25 September 2026 (UTC)
• Change to "Talk page" – not a major change that disrupts the past 15 years of display, the namespace name, or the edit history and wiki culture; however, seems like a promising way to cut down on people thinking the talk page is a chatbot. Skarmory (talk • contribs) 23:41, 27 September 2026 (UTC)
• No WP:BIKESHED. ~~ AirshipJungleman29 (talk) 10:47, 30 September 2026 (UTC)
• Oppose "Discussion" as no one refers to it as such, it would still confuse newcomers; leaning to supporting a change to "Talk page" as that's commonly referred to as such and is quite a bit more clear than just "talk". AlphaBetaDeltaLambda(αβδλ)^talk 22:24, 2 October 2026 (UTC)
• Show "Discussion" for signed-out users and new accounts; show "Talk" for established accounts when signed in; retain "Talk" as the name of the namespace. The problem primarily stems from confusion from users unfamiliar with Wikipedia jargon, not experienced users. InfiniteNexus (talk) 19:49, 12 October 2026 (UTC)
• No, I would expect a link going to the talk page to be labelled "talk". Would prefer "Talk page" over "Discussion", but would prefer the status quo most of all. Arnav Bhate (talk • contribs) 03:34, 22 October 2026 (UTC)

Discussion (button name)

Presumably, "Talk:Foo" would automatically be created (or maintained) as a redirect to a given "Discussion:Foo"? BD2412 T 16:53, 3 September 2026 (UTC)

No, only the label of the button would be changed, not the name of the page itself. The pagename of the talk pages have always started with "Talk:", even before we changed the button label to "Talk". FaviFake (talk) 17:01, 3 September 2026 (UTC)

Wait, so this proposal is JUST changing the visual presentation of the buttons on web and mobile versions of the page from "Talk" to "Discussion"...

...and that's it? If so can you make the RFC a teeny bit clearer that it's a MUCH smaller but impactful change, and as editors there is no actual impact? — Very Polite Person (talk/contribs) 22:40, 3 September 2026 (UTC)

Yes, exactly!

 Done, and i also added a side-by-side image comparison for clarity FaviFake (talk) 22:52, 3 September 2026 (UTC)

Why change just the label and not also the namespace? Levivich (talk) 23:07, 3 September 2026 (UTC)

The default namespace is fine. When editors open a talk page, they're almost always greeted by a {{talk page banner}} that immediately tells them in a bolded font that "This is the talk page for discussing improvements to the [Weather] article. This is not a forum for general discussion of the subject of the article." We couldn't ask for a better notice.

The button, on the other hand, is completely ambiguous: it just says "Talk!", which is website design means "talk with our chatbot!" or "chat with the community!". There's a reason "Discussion" has always been the default. Plus, changing the namespace would be a nightmare, while changing the label of a button literally takes 1 second. FaviFake (talk) 23:20, 3 September 2026 (UTC)

It probably isn’t just chatbots — it really started to accelerate in early 2022 (before ChatGPT and derivatives) and some comments show indicators that the users are mistaking it for text-to-speech, Siri, etc. No I don’t have any diffs handy but I have personally dealt with tens of thousands of these Gnomingstuff (talk) 23:38, 3 September 2026 (UTC)

I remember a phase from around then of IP users creating talk page sections containing a short phrase repeated in the heading and body (eg. this where a user posts to Talk:Plain with a heading Structural plain and a comment of structural plain). They read like someone trying to search for specific information or navigate to a different article, where they were re-entering the term a second time as a comment in order to make the "Add topic" submit button become clickable. I think some kind of filter was added to stop very short new-thread comments from being posted?

The bigger issue still seems to me to be the new thread talk box itself, with its deeply cryptic request that the user enter not a comment but a "Description". Belbury (talk) 17:28, 8 September 2026 (UTC)

If there's a filter, I don't know about it and it's not working very well. Here's an example from 2 hours ago. (The person they pinged has only ever made one edit, in 2021, to their userpage, so there's virtually no way this is a legitimate attempt to ping them.) I've tried to get a filter put into place, but no one ever did it.

The reason you see this stuff less often now is that I have been going through every single edit made to talk pages, every single day (except when I get behind), since 2025. Gnomingstuff (talk) 07:54, 19 September 2026 (UTC)

Oh, this is the talk page? I wanted the discussion page. I must have clicked the wrong thing. ~2026-47946-04 (talk) 07:21, 4 September 2026 (UTC)

Given that this plan is only to change the display text on the icon, why not change the text to Talk Page instead simply Talk? It removes the ambiguity of being an LLM and is still fewer characters than the current proposal. Plus it remains in line with the existing set up. ExtantRotations (talk) 16:40, 5 September 2026 (UTC)

I think one word, without "page", would be more friendly to newbies and readers. "Discussion" and "talk" are words used for discourse surrounding something, so its purpose as a button seems more obvious. If you were new and saw "talk page", I don't think it would be clear that it is for discussion of the article. Axolitl (talk | contribs) 17:36, 5 September 2026 (UTC)

You know what, I take back what I said. I would not be opposed to adding "page". Axolitl (talk | contribs) 20:37, 5 September 2026 (UTC)

Contra Axolitl, I think this is a very sensible suggestion with few downsides. "Talk page" is no more or less obviously for discussing an article than either "talk" or "discussion", it matches what we tell new editors to look for and the elision of "page" in casual discourse is hardly unintuitive. Thryduulf (talk) 17:39, 5 September 2026 (UTC)

This is a good idea, and will avoid rewritting years of documentation calling it the “talk page”. Velocifyer (talk) 19:15, 5 September 2026 (UTC)

With the exception of the first, the labels are supposed to be verbs. It's an article: talk about it, edit it, view its history, etc. WhatamIdoing (talk) 20:39, 5 September 2026 (UTC)

I would support Talk page as well. --Ahecht (TALK
PAGE) 18:36, 8 September 2026 (UTC)

Re some of the comments above, is there any reason to think clueless people who think "talk" means talking to an AI chatbot wouldn't think the same for "discussion"? Anomie⚔ 22:09, 3 September 2026 (UTC)

Language barrier possibly, “talk” is a more recognizable word than “discussion” and it’s also an imperative verb

to be clear I don’t expect this to have an earth shattering effect but literally any tiny improvement would help Gnomingstuff (talk) 23:40, 3 September 2026 (UTC)

Would be curious though to hear whether other wikis have this problem to the same extent (proportionate to their size obviously) Gnomingstuff (talk) 23:41, 3 September 2026 (UTC)

I don't think other wikis would have this issue because the default is not "Talk" and, as Yesterday suggested above, most other wikis haven't changed the default. I'm an admin on a smaller wiki myself and we've never noticed editors coming to the talk page to have the article read aloud to them or chat with a bot. I'd guess this is partially due to the fact that we've always kept the default label.

But of course I'd love to know if this problem affects other larger wikis. FaviFake (talk) 23:51, 3 September 2026 (UTC)

Talk:Google sees this kind of disruption about once every few days. de:Diskussion:Google about every few months. Google gets 11 times as many pageviews as de:Google. So they're on the same order of magnitude, but maybe we get a bit more problems per pageview than them? There's so many possible confounding factors though that I wouldn't really put any weight on something like this. For one, most people reading dewiki probably have a decent grasp of German, whereas enwiki is typically a top search result for everyone, so it's to be expected that we get a lot more people who can't really understand what these things mean. ;; Maddy from Celeste (WAVEDASH) 00:14, 4 September 2026 (UTC)

We should remember that other language Wikis have distinct cultures. The French Wiki crowd often know each other surprisingly well, almost like the usual customers at a cafe in Paris. The Italian Wiki has far fewer vagabond editors and apart from hot topics like fascism is rather stable. The Spanish Wiki is somewhat similar. The German Wiki is highly controlled, more than one would expect and most users know the rules. But they all use discussion as the button text. Yesterday, all my dreams... (talk) 05:06, 4 September 2026 (UTC)

I would encourage people to go and have a look at that 2011 discussion. The consensus there was that having the link text differ from the namespace's name was confusing to newcomers, who were being told to go to the "talk page" but couldn't find a "talk" link. I don't see why this wouldn't still apply. ;; Maddy from Celeste (WAVEDASH) 22:43, 3 September 2026 (UTC)

• This sounds like something that could genuinely, and without significant collateral, be A/B tested. CMD (talk) 03:04, 4 September 2026 (UTC)

  At the very least the placeholder text could be A/B tested (although it would be nice to get a heads up). The reason so much of this stuff has lines like "English", "History", "Social science"/"SST", "MAPEH" etc. is because people who want to cheat on their homework see "Subject" and assume it is a chatbot asking them what the school subject is. Gnomingstuff (talk) 07:02, 5 September 2026 (UTC)

• A point I forgot to make is that this is a very frequent vector for posts requiring oversight. People will post their actual phone numbers, addresses, bank account numbers, you name it, because they think it's ChatGPT. So if we can discourage that even a little, it's a clear net positive. Gnomingstuff (talk) 06:59, 5 September 2026 (UTC)

  Speaking as an Oversighter, I see no evidence that prompts for Chat GPT are a common reason for posts being oversighted. I've looked at the most recent 20 suppressions on talk pages and only 1 of them seems likely to be an LLM prompt, people have been posting phone numbers, bank accounts, etc to Wikipedia since long before LLMs were a thing (subjectively I don't think it's increased significantly either). I also see no evidence that suggests changing the label of the page will reduce the incidence of people doing this. Thryduulf (talk) 10:57, 5 September 2026 (UTC)

• Wait, who added this RfC? The signature appears malformed. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 08:12, 5 September 2026 (UTC)

  It's normal to end the statement of the RfC question with just a timestamp, since it isn't supposed to express anyone's opinion. ;; Maddy from Celeste (WAVEDASH) 08:16, 5 September 2026 (UTC)

  I see. Hason-LEK-🇸🇬 ● 💬 ● 🧱 ● 🧪 08:21, 5 September 2026 (UTC)

  This is officially permitted. About 10% of RFCs use that style. A lot of editors never even notice. WhatamIdoing (talk) 20:44, 5 September 2026 (UTC)

Is there empirical evidence supporting either the contention that the current "Talk" label is confusing for some new editors or the contention that changing the label to "Discussion" would be confusing? I'm not comfortable making assumptions and this is something that is testable. ElKevbo (talk) 16:48, 7 September 2026 (UTC)

There wasn't any evidence when we first decided to change it and there still isn't any, afaik. FaviFake (talk) 17:02, 7 September 2026 (UTC)

"We never knew what we were doing before, why start now?" -- Wikipedia, in a nutshell. (Somehow, it actually works.) Levivich (talk) 17:57, 7 September 2026 (UTC)

There was plenty of anecdotal evidence from people who dealt with new editors, e.g. , , . The argument in favour of "discussion" doesn't have even that. Thryduulf (talk) 18:11, 7 September 2026 (UTC)

Should we ping participants whose most recent comment here was posted before "Talk page" was proposed as an alternative solution? FaviFake (talk) 15:51, 30 September 2026 (UTC)

Yes, to see whether there are issues with "Talk page" that have not yet been brought up, and how much support there is for it. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 22:25, 2 October 2026 (UTC)

Courtesy pings: Yesterday, all my dreams..., HierophantOfOmens, Very Polite Person, Blueboar, Kowal2701, BilledMammal, oknazevad, Pppery, Johnuniq, Pincrete, Kovcszaln6, Jahaza, Anomie, Maddy from Celeste, ~2026-47946-04, BD2412, Chipmunkdavis

You are being pinged because you commented on this proposal before the suggestion to change the label from "Talk" to "Talk page" was made. You may wish to comment or amend your existing !vote to specify whether you prefer this alternative compared to the one proposed initially. FaviFake (talk) 22:32, 2 October 2026 (UTC)

I'm not convinced "talk page" will actually help but I have no substantive objection to it. * Pppery * _{it has begun...} 22:34, 2 October 2026 (UTC)

I'm not sure that there is a problem, nor that this will help, but have no substantive objection. Most editors will barely notice the change I suspect. Pincrete (talk) 05:28, 3 October 2026 (UTC)

... That's because editors are not the people being confused by the label. FaviFake (talk) 09:47, 3 October 2026 (UTC)

Meh, I guess. I don't think adding "page" really clarifies anything for the confused; I think the whole thing is a bit WP:BIKESHED anyway. No change is needed at all. If a change is made though, this is better than reverting to "Discussion". oknazevad (talk) 15:16, 3 October 2026 (UTC)

The suggestion that adding "page" [doesn't clarify] anything for the confused keeps being brought up, so I'll revisit my original reasons in light of the new proposal:

More and more of our readers are assuming that the "Talk!" button on our articles takes them to an AI chatbot.
— User:FaviFake 20:56, 3 September 2026 (UTC)

If you compare "Talk!" to "Talk page!", it becomes obvious that the former is more misleading than the other on this front.

users are mistaking it for text-to-speech. Most online news articles nowadays have a button that reads the article aloud for them.
— User:FaviFake 20:56, 3 September 2026 (UTC)

Nobody would ever expect a button that says "Talk page" to read the page aloud for them. The same can't be said about "talk".

enwiki is the largest and typically attracts more non-native speakers. "Talk!" is more recognizable than "discussion" and it's also an imperative verb.
— User:FaviFake 20:56, 3 September 2026 (UTC)

Just like "discussion", "talk page" is not an imperative verb. "Talk", on the other hand, is.

The upsides are basically the same, if slightly less effective than "discussion". FaviFake (talk) 15:33, 3 October 2026 (UTC)

I would suggest that most of the people who are confused enough (in terms of language or technological proficiency) to go through the multiple steps of going to the talk page, clicking "Add topic", writing a post and submitting it, all while thinking they are talking to a chatbot or a text-to-speech system, probably would not be able to appreciate the nuance of us saying "talk page" instead of "talk". ;; Maddy from Celeste (WAVEDASH) 20:30, 3 October 2026 (UTC)

As you said, there are multiple steps of going to the talk page. I'm just trying to make the first and most important step less misleading. Not everyone who clicks "Talk" without knowing what it does ends up completing every step; they might just think "Huh, i must've clicked the wrong button", and go back to the article. We can help those people too. FaviFake (talk) 20:35, 3 October 2026 (UTC)

Give this user a "True..." Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:40, 3 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.

Enabling iFrame graphics from Our World in Data on English Wikipedia

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.

---

Moved from Wikipedia:Village pump (technical) § Enabling iFrame graphics from Our World in Data on English Wikipedia

 – per talk there

Hi all I’m posting this on behalf of Booksmurf, Doc_James and myself.  We would like to try and get a consensus on whether to enable iframes from Our World in Data, specifically allowing MDWiki:WikiProjectMed:OWID_popup to be run on English Wikipedia. showing a static image from Commons which becomes an interactive graph once clicked on and a reader agrees to the consent pop up. Below we have put together a summary of the background information but in short the system has passed a security review from the WMF and is currently being used on Basque and Spanish Wikipedia. Just to make clear, this isn’t a discussion on using iFrames from any source, only from Our World in Data.

Context

About Our World in Data

Our World in Data is a project run by the UK charity Global Change Data Lab, which is attached to the Oxford Martin Programme on Global Development at the University of Oxford, They produce over 2,000 interactive charts and data tools on a very wide range of topics under CC BY-SA licenses. They collate data from the UN, governments, and other reliable sources. Several people within the community, affiliates and WMF, have connections with the OWID team. In addition the Head of Engineering at Our World in Data took part in the last discussion about this topic (links below).

Development history

1. The OWID gadget was created by Wiki Projtec Med.
2. There was a pilot rollout on Basque and Spanish Wikipedia in April 2024, which the WMF paused shortly after to address concerns raised at the time.
3. An interim process was created to show images from OWID on Wikipedia, which relies on thousands of files on Commons and many kinds of images are not possible to visualise on Wikipedia using this method.
4. There was a security review where WMF security assessed the risk as low.
5. A Memorandum of Understanding (MOU) was put in place between WMF and Our World in Data in July 2025 covering how projects may incorporate this visualization method.
6. Implementation on Wikipedia
   1. The OWID iframe has been enabled on Spanish and Basque Wikipedia under the July 2025 MOU.
   2. The method includes a one-time consent prompt: the iframe content is not loaded until a reader actively interacts with the gadget (e.g. presses "play").

Example graphics

Below we provide examples of the kinds of graphics OWID produces. These graphics were created using the current, more difficult process, which can only visualise some kinds of graphic OWID produces. The iframes however allow using many types of interactive content that the all Commons approach does not support. there are two options for what to display:

1. Current: A current version of the graphic that will remain synced with the latest version on the OWID website
2. Snapshot: Allows users to choose a specific versions of the graph from a specific time period

Literacy rates

Annual co2 emissions per country

Asthma prevalence

Some examples of the kinds of graphics that currently can’t be shown using the older method but could be shown using this proposed method are shown here on the Wikiproject Med Wiki.

Summary of discussion

Previous discussions

There have been three previous discussions on the English Village Pump, none of which reached consensus but a lot of technical issues were discussed and resolved.

1. August 2025 (concerns raised)
2. November 2025 (no engagement)
3. April 2026 (overall support)

Impact (enabling iFrame graphics from Our World in Data)

There was consensus that the tool would be very useful for showing visualisations of data. Editors and affiliates who work with external data-holding organisations (UN agencies, governments, NGOs) noted that the existing options for getting institutional data onto Wikipedia ( manually uploading static images to Commons, or attempting to route data through Wikidata) do not scale and are error-prone.

There was consensus that the tool would be very useful for showing visualisations of data — and the case for it is stronger than a simple feature request. A few things make this approach powerful rather than just convenient:

• It fills a longstanding gap. Editors have wanted interactive data visualisations for years, but MediaWiki has no native way to render them — Wikipedia has always been limited to static images (SVGs, PNGs). This is a persistent capability gap, not a new ask. Using static images from Commons means that there is significant and often undone work to keep the graphics up to date on Wikipedia when new versions are released. The OWID graphics using the Commons approach do not fill this gap because they an only render a limited number of OWID graphics
• The content is built and maintained by a partner who already specialises in data visualisation. OWID already produces and maintains 2,000+ interactive charts as its core mission, with dedicated engineering resources behind them. Wikipedia doesn't need to build or maintain any visualisation tooling itself — it only needs to display what OWID already keeps current. That's a fundamentally different cost structure from the Commons or Wikidata routes, where volunteers have to do the ongoing maintenance work by hand (see John's reply below for a detailed account of why those routes don't scale).
• The usual iFrame risk profile doesn't map cleanly onto this case. The standard objection to embedding iframes is that you're pulling in content from an unvetted, potentially unreliable third party with no accountability. That's not the situation here: this isn't a general allowance for arbitrary third-party iframes, it's a single, named non-profit partner, vetted through a WMF security review, and governed by a signed MOU that constrains what they can do with any data collected through the embed. The generic risks of "working with iframes" — foreign control of content, uncertain data handling, no recourse if something goes wrong — are mitigated specifically because there is a formal governance relationship in place, not because iframes are inherently safe.

Put together: this is a capability the community has wanted, it comes at very low build/maintenance cost to Wikipedia, and the usual reason to be cautious about embedding someone else's content doesn't really apply here, because OWID isn't "a third party" in the open-ended sense — it's a defined, agreed-upon partner.

Security discussion

WMF security assessed the overall security risk as low.

Summary of concerns

The main concerns raised in the August 2025 discussion centred on two related issues:

• Loss of local control: an iframe embeds content that Wikipedia projects cannot version, vet, or revert the way they can wikitext or hosted media, since it is served live from an external domain (OWID) rather than from WMF infrastructure.
• Reader privacy / IP exposure: loading the embedded graph causes the reader's browser to contact OWID's servers directly, exposing their IP address to a third party.

Summary of mitigations

The mitigations put in place, and discussed by the community, include:

• A Memorandum of Understanding (MOU) between the WMF and Our World in Data, agreed in July 2025, governing how OWID may (or may not) use data collected through the embed. The exact terms of the MOU have not been made public to editors.
• A consent pop-up shown the first time a reader triggers the gadget on a page — nothing loads from OWID until the reader explicitly agrees.
• Browser storage partitioning (e.g. in Chrome), which limits OWID's ability to correlate a given visitor's iframe activity with their activity elsewhere on the web — noted as a partial mitigation rather than a complete guarantee, since it depends on the reader's browser.
• Version control: OWID has built the ability for us to link to a specific archived version of the content rather than the most recent live version. Therefore we have some version control.

Thanks for your time

John Cummings (talk) 16:04, 16 September 2026 (UTC)

Discussion (enabling iFrame graphics from Our World in Data)

Support/Oppose (enabling iFrame graphics from Our World in Data)

• Support: Personally I think having this would be extremely valuable, I work in the UN system, helping different agencies share their knowledge and content on Wikipedia. I think my experience is fairly representative of other people I know working with other large institutions. A lot of UN and other Intergovernmental Organization data is shared on Our World in Data.

Before this opportunity there were three options for sharing data visualisations and none worked very well at all and basically weren’t scalable:

1. Sharing graphics on Commons: I do this for a lot of my work and its extremely time consuming to agree licenses, someone has to update the graphics on Commons and exchange them on all versions of Wikipedia, its a huge amount of work and isn’t scalable.
2. Visualise using data from Wikidata: as far as I know no UN agency is willing to share under CC0 and is very unlikely to change this policy. Visualising from Wikidata onto Wikipedia is very complicated and is also risky for the organisation since on Wikipedia it can say the data is coming from an organisation but then anyone can change a value on Wikidata and this isn’t true any more. Also extremely time consuming to keep updated.
3. Use the old OWID in data approach: This approach has over 1.7 million+ svg files, its extremely complicated and fiddly, I’ve read the instructions several times and cannot make it work. I do not think its a realistic option for a long term widely adopted approach.

If this is approved I would like to spend time on improving the documentation and encouraging UN agencies to make sure their data is up to date in OWID

Thanks again

John Cummings (talk) 16:07, 16 September 2026 (UTC)

• Support: This will allow us to use more complicated interactive graphs that are not supported via the current all Commons approach. The current methods also do not support at all or support well, the larger interactive graphs pertaining to COVID. Just to many SVGs I think. Doc James (talk · contribs · email) 17:20, 16 September 2026 (UTC)
• Support: This is a great idea! Interactivity makes this vastly more useful than a static image. Wikipedia really needs things like this to keep people visiting articles instead of just reading summaries. I really hope it gets approved! NavinoEvans (talk) — Preceding undated comment added 11:53, 17 September 2026 (UTC)

Yearly healthcare expenditure per person (total public and private). See file page.

• Support: Go to Commons:Help:Interactive data graphics by Our World in Data for info on what exists now, the OWID slider. The iFrame version that is proposed is much better, provides much more info, and is much easier to maintain. Go to any OWID interactive graphic at the source, and compare it to the current OWID slider to see what I mean. For example, OWID source versus the OWID slider to the right. --Timeshifter (talk) 12:54, 17 September 2026 (UTC)
• Support: As per above. Battleofalma (talk) 09:19, 18 September 2026 (UTC)
• Support: The functionality described above has multiple practical uses that would benefit open knowledge sharing. EriedgenArc (talk) 08:34, 19 September 2026 (UTC)
• Support Looks reasonable and beneficial. -- GreenC 16:15, 19 September 2026 (UTC)
• Support: The more ways ze can visualise data the better! Octavosaurus (talk)
• support - we know our readers want more readily accessible graphics, especially since sharing knowledge becomes more image focussed due to social media, so I see lots of readership benefits Lajmmoore (talk) 16:00, 22 September 2026 (UTC)

• Oppose. Have to say this every time this up: I am not interested in giving up our presentational autonomy to OWID. The information we share must be something we can change locally (or within our sphere of influence). OWID is not.

  And again, please ensure this kind of request is advertised at a place where people don't just care about bugs and misbehaviors. It is exceedingly obnoxious that it keeps coming up at VPT, which is a place for technical problems, and not at WP:VPR. Izno (talk) 16:10, 22 September 2026 (UTC)

• Support as an interim solution: Ideally, the data would be in a .json file on Commons and these map/timeline visualisations would be an option in the Chart extension, giving us automatically-generated interactive images that are redistributable. Then again, we know that the relevant software development on MediaWiki can take years and still be unreliable. The ideal shouldn't be the enemy of the good. If we can have multi-dimensional visualisations relating to health, development, and economics, that are easier to take in than lots of images, and if the right protections are in place for user data, then we should. MartinPoulter (talk) 09:34, 23 September 2026 (UTC)
• Oppose per Izno. VPT is not the correct venue for this, and it being brought up here unstead of the correct venue should invalidate the proposal. - The Bushranger _{One ping only} 22:08, 23 September 2026 (UTC)

  The Bushranger, the proposal has now been moved to the Village pump {proposals) space. Thanks to Timeshifter for moving it. To the best of my knowledge there is no policy to 'invalidate' a proposal if it is initially proposed in a different place. John Cummings (talk) 19:16, 24 September 2026 (UTC)

  You are correct!​ FaviFake (talk) 23:57, 27 September 2026 (UTC)

• Support. This is a step in the right direction. Alaexis_¿question? 13:26, 24 September 2026 (UTC)
• Support I support either and both pulling data directly from OWID or copying/migrating their datasets to the Wikimedia ecosystem and generating this content from here. I get the concern and opposition that this is the first time we are pulling in non-Wikimedia data to serve to readers in Wikimedia platforms. However, I trust OWID as a mission-aligned project to Wikimedia, and also I think that it is critical now that we develop our infrastructure for processing datasets. A major part of the pressure on us is that we lack the infrastructure to host the datasets in the Wikimedia platform; or at least, our data visualization infrastructure is inaccessible and not being used. We need to quickly gain capacity to serve interactive data visualizations. We should accelerate this process, and go beyond OWID to bring in open government datasets into the wiki ecosystem. Now is not the time to make all editorial decisions about what data we want and what data we do not, but as for OWID datasets, yes, we want all of these. Bluerasberry (talk) 18:34, 24 September 2026 (UTC)
• Support - After balancing the benefit to readers (informative, quality data) vs the drawbacks (lack of control of underlying data), this seems like a good idea, because the maps are exceedingly useful. The primary concern seems to be lack of data control (or ability to specify a particular historical version). But WP already permits external data to be linked directly from WP articles, e.g. with template {{External media}}. It is not a black-and-white choice, a balancing is required. Noleander (talk) 12:25, 25 September 2026 (UTC)

  OWID has provided us the ability to link to specific historical versions if we wish. Or the ability to link to the most recent version. Doc James (talk · contribs · email) 14:29, 25 September 2026 (UTC)

  Just to make clear for Noleander, when we say 'the most recent version', this is a live version from the OWID website that is automatically updated when OWID collects new data from the data provider. John Cummings (talk) 21:33, 25 September 2026 (UTC)

• Oppose The community has regularly, and correctly, in my opinion, opposed efforts to make more widespread use of Wikidata because of the complications and confusion that causes for editors and because of the differing standards and practices that exist between the two projects. The exact same arguments and issues apply here. Further, I am flabbergasted that we spent so much time and effort to ensure that the IP addresses of unregistered editors are no longer visible to most editors and we're not suggesting that a third party be given access to the IP addresses of countless editors. Finally, the current implementation has significant UI issues e.g., clicking the "play" button suddenly and unexpectedly makes the video much larger instead of just playing the video/animation as expected. ElKevbo (talk) 13:25, 26 September 2026 (UTC)
• Support i am convinced of what Bluerasberry is proposing. Hence per Bluerasberry i support too. Accesscrawl (talk) 17:38, 26 September 2026 (UTC)
• Support should be allowed on a case by case basis, doesn't have the same vandalism issues as Wikidata. (t · c) buIdhe 17:46, 27 September 2026 (UTC)

  Thanks Buidhe, this is something I should have brought up in my support. If we say to the agencies which produce the data we can share it on Wikidata but anyone can change it at any time, so they need to monitor it, this isn't a very interesting proposition for them. John Cummings (talk) 09:40, 28 September 2026 (UTC)

• Support – This is a good idea! Wikipedia has way too many static images when interactive elements are much better. We're WP:NOTPAPER, after all. FaviFake (talk) 23:58, 27 September 2026 (UTC)
• Support - we are not obligated to use these images, and as long as we can freeze the data to a particular time if we want to and OWID isn't radically changing their UI constantly, editors retain control of the presentation in just the same way as we would using freely-licensed images created by someone else. Wikipedia (for understandable reasons) does very poorly with giving readers images and other visualizations; this would help at least within its area of concern. Rusalkii (talk) 00:02, 28 September 2026 (UTC)
• Support Interactive graphics will better serve readers; it's reasonable to want full control over how data is displayed, but the utility of OWID graphics would significantly improve articles. 🏰 Richard Nevell (talk) 21:39, 30 September 2026 (UTC)

Discussion and questions (enabling iFrame graphics from Our World in Data)

• "link to a specific archived version": if you do that, you are right back to the volunteers-have-to-update-manually problem that you seemed to be trying to solve. You can link straight to the OWID, and always get the latest version, no manual updating; or you can go for versioning, in which case the approach isn't solving the problem. You surely can't do both. Best would be to extract the version ID from the (current) OWID ... if it's there: if not, persuade them to provide it ... and not try to do manual version updates. Chiswick Chap (talk) 17:54, 16 September 2026 (UTC)

  Editors can choose which version they want. I would generally go with the most recent version, agree. But even if one goes with an archived version, it is just the one instance that needs updating, not the 100s or 1000s of underlying files. Doc James (talk · contribs · email) 18:08, 16 September 2026 (UTC)

  Hi Chiswick Chap, I'm sorry for the misunderstanding, I've put a few lines in the summary above to explain that there are two options, one to have a live version of the graphic that stays synced to OWID and one to have a specific snapshot of the graphic. John Cummings (talk) 08:51, 17 September 2026 (UTC)

  Oh good. Thanks for explaining. Chiswick Chap (talk) 12:19, 17 September 2026 (UTC)

  No problem Chiswick Chap, let us know if you have any other questions and please consider supporting the request :) John Cummings (talk) 22:07, 17 September 2026 (UTC)

• In addition to the "return to article" button at the bottom, I would like to see an X in the upper right corner to close the pop-up window. The bottom button wasn't very obvious to me, since it filling the entire width of the page has a bit of a dark pattern effect since it looks like a footer and not a button. Having an ✕ or Ⓧ in the upper right has become the standard for pop-ups, pop-ins, and modal dialogues across the web such as cookie notices, privacy policies, "special offers", newsletter signups, and even our own MediaViewer. --Ahecht (TALK
  PAGE) 18:48, 17 September 2026 (UTC)

  Sure, we can definitely add that to both methods. Doc James (talk · contribs · email) 22:02, 17 September 2026 (UTC)

• Comment: Shouldn't this discussion be held on VPP? VPT is usually limited to technical issues, questions, and answers, and does not usually hold RFCs or proposals. – Jonesey95 (talk) 20:21, 16 September 2026 (UTC)
  • Thanks Jonesey95, I wasn't sure where to put it, its a technical request so I guessed the best place was here. Do you know where any rules for this are? Also do you know if there is a process to move a conversation or is it just a case of copy and pasting the whole thing? John Cummings (talk) 21:57, 16 September 2026 (UTC)
    • Yeah, we should probably have a line at the top of this page that says something about RFCs and proposals generally belonging at VPP. – Jonesey95 (talk) 00:00, 17 September 2026 (UTC)
• Are these meant to work well on mobile? The CO2 one basically crashes the browser page, I'm guessing bots data set is to large for my phone to handle. It's fine if it doesn't work, but it should fail more gracefully. -- LCU ActivelyDisinterested «@» °∆t° 00:38, 26 September 2026 (UTC)

  Works for me… but the new approach should work better on mobile Doc James (talk · contribs · email) 05:17, 26 September 2026 (UTC)

• @John Cummings, I'd recommend viewing this in night mode, where the text is incredibly hard to read. Any ideas for how to address this accessibility issue? Axolitl (talk | contribs) 01:35, 26 September 2026 (UTC)

  The iframe should address this Doc James (talk · contribs · email) 05:21, 26 September 2026 (UTC)

  This actually only affects Minerva dark mode AFAICT, not Vector. Axolitl (talk | contribs) 05:29, 26 September 2026 (UTC)

• I have made a request for this discussion to be looked at by an admin for resolution. John Cummings (talk) 11:21, 8 October 2026 (UTC)
• I just want to add my thoughts on the comments that have been made to oppose the proposal. I think that honestly this approach isn't that different to what is already in place. All sources I'm aware of OWID using are considered reliable or perennially reliable by English Wikipedia. The only difference I can see with this approach and either adding OWID graphics through simple uploading of static graphs or the older system for generating OWID graphs is that these graphics will provide the latest version of the data. Thanks again John Cummings (talk) 19:44, 13 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.

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 ^{ᚾparley$\lor$investigateᛅ} 18:56, 21 October 2026 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussion (mover protection)

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 ^{ᚾparley$\lor$investigateᛅ} 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 ^{ᚾparley$\lor$investigateᛅ} 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 ^{ᚾparley$\lor$investigateᛅ} 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 ^{ᚾparley$\lor$investigateᛅ} 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)

Wiki Loves Peace 2026

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.

---

Hello everyone,

I am requesting community feedback regarding a CentralNotice banner for Wiki Loves Peace 2026, an international photography campaign supported by the United Nations Office for Disarmament Affairs (UNODA) aimed to document peace-related heritage, memorials, museums, monuments, public art, and other sites connected to peace and reconciliation around the world.

As guided by DerHexer on the Meta-Wiki CentralNotice request page, I am seeking community consensus on allowing the banner to run on the English Wikipedia as well. The banner period would be the first week of October and the last week of October 2026, for a total of 14 days.

Peace-related heritage is located in every region of the world, and the English Wikipedia has a global audience. Allowing the banner to run on the English Wikipedia would help inform contributors worldwide about the campaign and encourage participation in documenting places that embodies the pursuit of peace.

P.S. The campaign has also been featured by the Wikimedia Foundation on all its social media channels: Instagram, Linkedin, Facebook, YouTube, Bluesky, Threads.

Comments, questions, concerns, or support are all welcome.

Thank you for your time. ❯❯❯ Raydann^(Talk) 08:45, 30 September 2026 (UTC)

• Support: as proposer

❯❯❯ Raydann^(Talk) 08:59, 30 September 2026 (UTC)

Comment: As stated on the CN request page, “I have added a limit of 25 % maximum reach (with 5 displays per week)” in order to reduce banner blindness for this new campaign. If you have further questions or wishes for adjustments, I will try to follow the conversation here and on the request page. Best, —DerHexer (Talk) 10:05, 30 September 2026 (UTC)

I oppose running these banners for anonymous users; banners are not free. I support an impression diet of at most two per week (for a total of four banners over the campaign period). Best, HouseBlaster (talk • edits • he/they) 17:57, 30 September 2026 (UTC)

I support this, with any ordinary reasonable limits (e.g., as already set by DerHexer). WhatamIdoing (talk) 18:23, 30 September 2026 (UTC)

• Oppose. I do not think the number of en-wiki readers or editors who would be interested in "[t]ak[ing] photographs of subjects relevant to the theme of peace" and uploading them to Commons is high enough to justify something as burdensome as a CentralNotice. Advertising the campaign on Commons (the affected project), social media, mailing lists, etc. seems like a more proportionate approach. Extraordinary Writ (talk) 05:00, 1 October 2026 (UTC)

  Any registered editor who finds that ignoring or clicking away a banner five times a week is "burdensome" can go to Special:Preferences#mw-prefsection-centralnotice-banners and turn them off. WhatamIdoing (talk) 02:54, 2 October 2026 (UTC)

  I think the percentage of users who are aware of that is extremely small. Maybe I'd feel differently if CentralNotices had opt-out instructions. Extraordinary Writ (talk) 22:12, 2 October 2026 (UTC)

  I suppose we could run a local site banner or a watchlist notice to tell people about it. Or maybe you'd like to write something for The Signpost about it? (I could imagine a whole series on various prefs settings. For example, did you know that changing your language to en-gb usually has the effect of shortening a lot of software messages?) WhatamIdoing (talk) 22:22, 2 October 2026 (UTC)

• Provisional support, but what specifically are the metrics (eg number of times it runs) and how do they work? I can't seem to find the details and while I am willing to support projects related to peace, I do want to have the "spam" concerns sorted out before I "lock in" my !vote. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 08:34, 1 October 2026 (UTC)

@Hason-LEK-SIN, with the current configurations (25% traffic limit and 5 displays), the banner will be shown to 25% of eligible users. For example, if 100 people are eligible to view the banner, it will not be shown to all of them, but only to a quarter of those users. Furthermore, the banner will be shown to an individual user at most 5 times per week, so if a user has seen the banner 5 times, they won't be shown the banner again until the limit resets the next week.
For this specific campaign, the banner will only run for 2 weeks: the first week of October, which is currently passing by (meaning that the total time duration for the banner is shrinking), and the last week of October, from the 23rd to the end of the campaign on 30 October. Therefore, a person can see the banner at most 5 times this week, and at most 5 times during the last week of October. ❯❯❯ Raydann^(Talk) 23:32, 1 October 2026 (UTC)

For ENwiki, that seems sufficient, while for Commons, the Wiki loves Peace campaign is already advertised on the home page, so there may be no need for the banner. Given all those limits to prevent spam, I wholly support. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:37, 2 October 2026 (UTC)

I support HouseBlaster's proposition, 2 per week, I think it makes sense for enwiki as one of the most prominent wikis to promote it's sister project's initiatives, but seeing one every weekday on a related project feels overkill. Sohom (talk) 15:51, 2 October 2026 (UTC)

I don't think it works that way. I think it's 5 times in ~20 page views, and the nothing else for the rest of the week. WhatamIdoing (talk) 20:24, 2 October 2026 (UTC)

• Is peace neutral? I could see this drawing complaints from both the "this is criticism of [insert current war]" and the "no justice no peace" POVs. _signed, Rosguill ^talk 16:13, 2 October 2026 (UTC)

  Perpetual proposal to change Wiki Loves to Wiki-would-generally-very-much-like-to-have-better-coverage-of CMD (talk) 03:28, 4 October 2026 (UTC)

• Oppose As Clausewitz put it, war is the continuation of politics by other means. So is peace. It is inherently non-neutral.--Wehwalt (talk) 16:20, 2 October 2026 (UTC)

Comment: Traditional outreach channels are already being actively used (mailing lists, community groups, social media, and direct outreach to affiliates and local communities), @Sohom can perhaps attest to that.

Regarding banner fatigue, I am willing to compromise on a limit of 25% max reach and 2 impressions per week (4 total across the campaign period) for both logged-in and anonymous users.

My reasoning is that English Wikipedia reaches a global audience. Peace related heritage sites exist in every region of the world, and uploading a photograph is a relatively easy first contribution than editing Wikipedia articles. Several of the strongest submissions received so far have come from people who stated that they had never previously contributed to Wikimedia projects.

Regarding the neutrality discussion, debating differing interpretations of peace is unlikely to be productive. This nuance was discussed extensively during the development of the campaign with UN staff. At face value, the project is a photography and documentation campaign, similar in nature to Wiki Loves Monuments, with the additional criterion that the subject be connected to peace, remembrance, reconciliation, disarmament, or peacebuilding.

Questions about the wider concept of peace are understandable, but the campaign itself is a photography campaign. I would prefer to keep this discussion focused on the proposed banner and its configuration. ❯❯❯ Raydann^(Talk) 18:11, 2 October 2026 (UTC)

• Support - I almost opposed because this just doesn't seem very enwiki-related, but 25% of users for less than two weeks, max 2-5 impressions/week? Meh, why not promote a peace initiative on a sister project, it seems pretty low key and maybe we'll get some good photos to use in enwiki articles out of it. Levivich (talk) 22:03, 2 October 2026 (UTC)
• Given that more than 40% of the first week has already passed, I would like to request revised banner dates on enwiki to allow a fair full week of visibility. Possible alternate: 7-14 October, while keeping 23-30 October unchanged. ❯❯❯ Raydann^(Talk) 21:50, 3 October 2026 (UTC)

  Sure. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:36, 3 October 2026 (UTC)

  Sure Sohom (talk) 03:06, 4 October 2026 (UTC)

  I continue to strongly oppose displaying any banners for anonymous users. I'm fine with the suggested dates. Best, HouseBlaster (talk • edits • he/they) 20:47, 4 October 2026 (UTC)

• I'd oppose running banners on this. Photo contests like WLM and WLE have clearly defined parameters. The concept of "peace" is quite a bit looser. Secondarily, although I believe that this would be impartial, I empathize with the concerns around appearing impartial and do think that possibility should tip an otherwise balanced scale. Ed ^{[talk] [OMT]} 16:01, 8 October 2026 (UTC)
• Hmm, given that we have not yet reached a consensus and time is running short, would it be acceptable to omit the first week entirely and run the banner for just one week (20 to 27 October, so that people who see the banner at the last minute still have 3 more days to upload pictures), with a 25% maximum reach and a limit of 2 impressions per user per week? I hope this extremely conservative proposal eases skepticism while still giving the campaign some visibility on English Wikipedia. ❯❯❯ Raydann^(Talk) 22:49, 12 October 2026 (UTC)
  • @Raydann: The time element is unfortunate, but per m:CentralNotice/Usage guidelines#Approval I'm not sure there is a consensus in this discussion to run banners at any impression levels. Ed ^{[talk] [OMT]} 09:27, 13 October 2026 (UTC)

  I support this proposal, provided that no banners are shown to anonymous users. HouseBlaster (talk • edits • he/they) 13:38, 13 October 2026 (UTC)

  Support, honestly I was almost persuaded to oppose this, but I don't really buy into the opposes. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 10:56, 18 October 2026 (UTC)

• Noting for transparency that this discussion has now been advertised on the mailing list. Extraordinary Writ (talk) 23:02, 12 October 2026 (UTC)
  • In fairness, I saw the mailing list note and ended up opposing. Ed ^{[talk] [OMT]} 09:28, 13 October 2026 (UTC)
  • TBH given this is time sensitive (the first quarter of October is slipping away...) I could understand why this list was sent. But who was it sent to? Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 10:37, 13 October 2026 (UTC)
    • @Hason-LEK-SIN: m:Wikimedia-l. Ed ^{[talk] [OMT]} 11:44, 13 October 2026 (UTC)

Support running a banner between the 20th and 27th for logged-in editors. EnWiki is almost guaranteed to reach potential participants that otherwise would be unaware it was going on (I didn't know until now). It's a minor bit of advertising for a sister project that we directly benefit from getting more activity to, surely we can accept that. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 00:12, 15 October 2026 (UTC)

Oppose. I suppose it's hard to object to the broad concept of Peace. But this is being run by a group called "Wiki4Disarmament" pushing disarmament. That is a bad look at a time when the dominant political issue in Europe is re-arming to face up to Russian aggression. the wub "?!" 16:20, 18 October 2026 (UTC)

Just a clarification: Wiki4Disarmament is the name of the GLAM project under which UNODA has appointed me as its Wikimedian-in-Residence. There is no group, it's just me. ❯❯❯ Raydann^(Talk) 16:50, 18 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.

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)

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please give feedback/workshop these however you think necessary.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Template rejection for AI-generated unblock req

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.

---

As title. We should create a template e.g., {{unblock-ai}} and {{ubai}} to host a standardized, ice cold rejection text where
admins may use at their discretion had they decided an unblock request is not worth their time. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 07:28, 20 October 2026 (UTC)

Intended as a solution to SPAs and UPEs that makes no effort to contribute to the Wikipedia in any way. Since they're lazy, I don't see why we should cushion them with a human-written denial message. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 07:30, 20 October 2026 (UTC)

I often wonder if using a LLM to write an unblock appeal should an instant removal of TPA on rejection. FMecha (to talk|to see log) 13:10, 21 October 2026 (UTC)

For a second offence, possibly, and certainly not if they've never been informed of our LLM-related policies. Thryduulf (talk) 13:20, 21 October 2026 (UTC)

We actually have one: {{Decline-ai}}, which produces:

This unblock request appears to have been written by a chatbot using a large language model. The purpose of unblock requests is to determine whether you, the human operating this account, understand why you were blocked – not to test a chatbot's ability to tell us what we want to hear. A message written or rewritten by a chatbot can also cause you to sound like you're making empty promises. It is better to write the unblock request yourself. Please read through the guide to appealing blocks for more help.

OutsideNormality (talk) 19:44, 20 October 2026 (UTC)

Y I see! I've seen that response quite often and didn't realize it was a template. Let's close this thread, then. 海盐沙冰 _{/ aka irisChronomia / Talk / Uploads} 06:41, 22 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.