This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
RfC: Merge nominations at MfD
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.
This was a complicated discussion, one that went beyond the initial question and into the depths of current perceived issues and misinterpretations. Firstly, I want to thank all participants for remaining civil, relatively focused, as well as knowing when to step away from rehashing the same arguments. It was however necessary that such counter-arguments and cross-examinations occurred, based on the complexity of the issues at hand, of which appeared plentiful.
To save editors the time of reading the full summary, the discussion failed to reach consensus due to criteria at WP:CLOSINGPAG. Namely: Have major concerns raised during the community discussion been addressed?, alongside the near split of supporters and opposers of the proposal. It's clear that there remains unresolved issues, beyond the scope of this RfC alone, which was the primary reason that consensus became impossible, even if strong support had been acquired.
To summarise the argument in favour; no venue since PAM closure, consistency with AfD/XfD, no examples of alternative venues, and redundant essays. There was also a distinct faction of conditional supporters, on the basis that outcomes are possible without the need for MfD, that this process should not be encouraged even if allowed, and should come with checks and alternatives before nominating. The opposers largely focused on not broken and lack of evidence of current issues, concern from MfD regulars, continued criticism of AfD-PAM merge, differing scope of MfD, consistency for sake of consistency, potential to cause further problems, and that alternatives to MfD for specific cases do exist (such as publicising discussions).
There was further review from editors regarding the closure of PAM, including the positives of the time and energy saved from consolidating discussions, along with the downsides of defacto restrictions on merge discussions (with an example provided). Alternatives included amending RFCs to allow for such merge proposals, undoing the closure of PAM, a new venue, and even multiple venues. The specifics that either remains unclear, or lacks a universal understanding, is whether MfD would be used as a first resort for controversial merges, or only after other avenues have failed; lack of clarity over what a "formal PAM discussion" actually is, continued confusion over PAM status, while reviewing the closure of RfC was also suggested.
Needless to say, there remains more unanswered questions than any resolved. While most editors simply !voted in favour or against, with solid rationales, a minority did engage in productive back and fourth attempting to resolve these questions, but to no avail. It remains thoroughly unclear to me, as the closer, what the best course of action should be following this close (if there even should be one). I can only hope that more experienced editors can try and assemble a plan, whether that be attempting to gain consensus over the interpretation of the previous RfC that remains uncontested (I'm not suggesting a close review based on endorse/overturn, but merely attempting to generate a consensus over the interpretation of the close itself that remains unchallenged); or otherwise for example refining the proposal to allow merge discussions at MfD, but with certain restrictions as previously described, as some form of compromise beyond blanket acceptance. One solution could also be to wait and see if issues arise (do nothing). Either way, the adjacent issues described in this close do appear to have created a roadblock for further changes, and would almost certainly require resolving prior to any further related changes being eligible for consensus.
I can only apologise that I can't be of more use here having evaluated this dispute in full; often it's clear what sort of direction editors need to take a discussion in, but given the number of discussions that have already occurred without consensus being achieved, it's difficult to believe that there is an obvious solution to this that would resolve these issues. Predominantly because it never presented itself in the discussion. (non-admin closure) CNCin solidarity (talk) 17:47, 27 October 2026 (UTC)
Should editors be allowed to nominate miscellaneous pages for merging at MfD? 09:37, 12 August 2026 (UTC)
Yes. There needs to be some sort of venue when talk page discussions don't attract enough editors or more eyes are needed. voorts (talk/contributions) 14:18, 13 August 2026 (UTC)
No per my comments at the pre-RfC discussion. Don't "fix" what isn't broken - there has been precisely zero evidence that this proposal would remedy anything at all. Regular MfD participants tell us that it would unnecessarily expand the scope of the discussion board and add extra friction.Katzrockso (talk) 20:26, 13 August 2026 (UTC)
No per extensive comments by me and others at the pre-RFC discussion. The tl;dr is that there is no convincing evidence of a real-world problem here and the proposed solution is not a good "fix" as the structure and function of MFD is fundamentally unsuited merge proposals. —Myceteae🍄🟫 (talk) 20:45, 13 August 2026 (UTC)
Yes as PAM was the only formal process for proposing a controversial merge of two projectspace or draftspace pages. With its closure, now we're left with a gaping hole, where the previous formal process for nominating projectspace pages and drafts for merging has been shut down with nothing set up to replace it. There's a reason why AfDs or any other XfDs don't take place in talk pages: as voorts said, those wouldn't attract nearly enough editors. This is especially a problem for non-article pages, which often have very few if almost no watchers. Hell, these discussions hardly attracted any editors at all even before PAM was shut down!There's no reason why an editor should be effectively unable to propose a merge just based on the page's namespace. This solution would finally make all XfD venues consistent: currently, MfD is the only venue where a page cannot be nominated for merging. All other "for discussion" venues routinely handle merge nominations for their respective namespaces. The current situation also creates an odd inconsistency: it is possible to formally nominate an article to be merged into a draft, yet there is no corresponding process for formally proposing that a draft be merged into an article, or even into another draft! FaviFake (talk) 22:09, 13 August 2026 (UTC)
Given that nobody has had any issues with merging pages that would be at MfD since PAM has been closed down how long ago, doesn't that suggest this isn't an issue at all? Katzrockso (talk) 23:02, 13 August 2026 (UTC)
Nobody has had a problem yet. But there is a very obvious hole that needs filling, and we should fill it before someone falls into it. Thryduulf (talk) 01:29, 14 August 2026 (UTC)
What's to stop people from doing what was done before: starting a talk page discussion? Katzrockso (talk) 02:35, 14 August 2026 (UTC)
Nothing. This is for situations that require more than a talk page discussion for some reason. Thryduulf (talk) 03:40, 14 August 2026 (UTC)
I don't think there has ever been a situation that requires more than a talk page discussion - we don't have anything beyond talk page discussions. Katzrockso (talk) 13:24, 14 August 2026 (UTC)
We don't have anything beyond talk page discussions precisely because the process for formally proposing a merge of a miscellaneous page was shut down in March of this year. FaviFake (talk) 20:46, 14 August 2026 (UTC)
A MfD discussion is also a talk page discussion. Katzrockso (talk) 23:15, 15 August 2026 (UTC)
Huh? —Myceteae🍄🟫 (talk) 23:29, 15 August 2026 (UTC)
This is getting off track anyways. The point is that the need for an alternative forum to discuss these mergers behind the talk page hasn't been demonstrated. If a consensus doesn't form or more input is needed, what stops editors from using the typical Wikipedia:Dispute resolution processes? Katzrockso (talk) 03:01, 16 August 2026 (UTC)
The fact that the venue for nominating pages in that namespace prohibits merge proposals; that's what stops them. FaviFake (talk) 09:33, 16 August 2026 (UTC)
This does not stop them from using RFCs or Village Pump or WP:3O or WP:DRN or seeking input from a relevant noticeboard or WikiProject. —Myceteae🍄🟫 (talk) 15:40, 16 August 2026 (UTC)
It would be easier and less disruptive to make a change to allow RFCs for the rare case of project space merge proposals. The table there is inaccurate anyway, or at least incomplete, since AFD is not used for all merge discussions—e.g., project space, templates. —Myceteae🍄🟫 (talk) 15:49, 16 August 2026 (UTC)
I took a stab at fixing the table. If you think project space merges should be handled by rfcs, you might want to bring that up at WT:RFC. Chessenjoyer (talk) 16:01, 16 August 2026 (UTC)
Since there is no evidence of a live issue and several other options exist in the event that one of these merge proposals needs more attention, I have no plans to spend time making additional proposals. My point is that other options and venues exist. —Myceteae🍄🟫 (talk) 16:34, 16 August 2026 (UTC)
(edit conflict)It would be easier and less disruptive to ... allow RFCs for ... project space merge proposals How is that easier and less disruptive than using the existing XfD venue for misc pages? The editor literally just needs to say "merging" in the MfD nomination and that's all that's needed.The table there is inaccurate anyway You're right, I fixed it! FaviFake (talk) 16:02, 16 August 2026 (UTC)
Multiple editors have explained at length:
Why adding this type of discussion will make MFD less efficient/effective;
Why the structure of MFD is not appropriate for project page merge discussions; and
Why talk pages (which can also host RFCs) are better suited for this.
I doubt it will be helpful to repeat these arguments again. And anyway, there are multiple other venues available to solve a problem which hasn't even been demonstrated to exist. —Myceteae🍄🟫 (talk) 16:32, 16 August 2026 (UTC)
RFCs shouldn't be used as the main process for proposed mergers. However, the RFC process has been used occasionally in the past for particularly complex discussions (e.g., a decision that could involve a merge, but has non-merge components), and it has been used as a supplement for important or contentious merges. For example, if someone revived the idea of merging WP:V and NOR, you can bet that the community would insist that the "proposed merge" be tagged as an RFC, in addition to be listed in WP:CENT and probably a the watchlist notice, too. WhatamIdoing (talk) 23:48, 18 August 2026 (UTC)
That should have been considered when the PAM-AfD merger was rammed through without any consideration for downstream consequences, not months after the fact. Nonetheless, that advice was inappropriately changed to say "Deletion discussion venues" without any community input. Katzrockso (talk) 18:43, 16 August 2026 (UTC)
That should have been considered when the PAM-AfD merger was rammed through without any consideration for downstream consequences I fully agree, that's why I and most if not all merge regulars have always opposed the PAM-AfD merge from the start.that advice was inappropriately changed to say "Deletion discussion venues" without any community input I added a huge {{current discussion}} banner at the top of that section due to this discussion. If one actually opens MfD, merging is still not allowed. You can add a parenthetical like (except MfD) if you want. FaviFake (talk) 18:49, 16 August 2026 (UTC)
I have a slight preference for Chess enjoyer's change but mostly I think this should have waited. Though the table was inaccurate it is not helpful to fiddle with it in the middle of this discussion. —Myceteae🍄🟫 (talk) 20:00, 16 August 2026 (UTC)
A completely erroneous table is worse than a slightly erroneous table?Feel free to revert my edit of course! But I think the banner should stay. FaviFake (talk) 21:12, 16 August 2026 (UTC)
To bring us back on track, the distinction editors are making is the talk page of the pages that are being considered for merger vs. a separate venue like MFD. If I want to merge 'Wikipedia:Foo' with 'Wikipedia:Bar', the discussion should take place at 'Wikipedia talk:Foo' or 'Wikipedia talk:Bar' and should be prominently linked on the other WP talk page. I agree that other dispute resolution processed should be used when talk page discussions fail. If the discussion just fizzles out with no consensus, editors should also consider dropping it and moving on… —Myceteae🍄🟫 (talk) 15:39, 16 August 2026 (UTC)
Yes for consistent with AFD. Crouch, Swale (talk) 22:15, 13 August 2026 (UTC)
Yes per FaviFake. This is a problem is one of the several that wouldn't exist if the closure of PAM had been done with just a bit more thought, but it does exist and there are only three logical solutions to it. The first is the one proposed here, the second is to undo the closure of PAM and while I have sympathies towards that course of action I don't think it's fair to say quite yet that the merger has failed (and it was also not discussed at all in the preceding discussion so interested editors probably aren't aware of it). The third option is to start a new venue just to handle merges of non-articles, but that would be a lot of overhead for not a lot of benefit relative to MfD. I know the MfD editors have expressed a desire not to have more work, but MfD is not overloaded and nobody is forcing them to contribute to discussions where deletion is not proposed. If it turns out that it actually does cause problems in practice, then the decision can be revisited, but until then it seems at worst to be the least bad option. Thryduulf (talk) 22:55, 13 August 2026 (UTC)
Yes. With all due respect to the MFD regulars, MfD is not a place which requires specialized tools or knowledge to participate. If you don't want to participate in merge discussions at MFD, well, don't participate in merge discussions at MFD. Best, HouseBlaster (talk • he/they) 01:42, 14 August 2026 (UTC)
Yes, with the understanding that the result of an MfD could be one of the other possible outcomes of a MfD rather than merge or not merge. CMD (talk) 01:55, 14 August 2026 (UTC)
Yes It would not make much sense if we allowed merges at AfD for regular articles, but did not for miscellaneous pages. In my opinion, bringing merges to AfD has been a large success, and there is no downside with this proposal. ᴢxᴄᴠʙɴᴍ (ᴛ) 02:06, 14 August 2026 (UTC)
No. Why? This would further confuse the already confused scope of MFD. The AfD-PM merge has been an utter disaster, why repeat it with another venue? PARAKANYAA (talk) 02:34, 14 August 2026 (UTC)
I've been seeing drastically more participation in merge discussions after the combination, so I am curious what was a "disaster" about it. Before the combination, merge discussions were obscure and unlikely to be seen by most editors unless they were following the article or subject matter in question. ᴢxᴄᴠʙɴᴍ (ᴛ) 03:39, 14 August 2026 (UTC)
Editors with no experience or knowledge of the articles in question opining isn't necessarily a good thing. Katzrockso (talk) 13:20, 14 August 2026 (UTC)
The AfD-PM merge has been an utter disaster. Out of curiosity, can you give some specifics? I don't like the outcome very much because it's created the need for me to do a bunch of emergency updates to gadgets, but other than that, how's it going? –Novem Linguae (talk) 03:54, 14 August 2026 (UTC)
Making it impossible to have any lengthy merge discussions leads to both terrible, ill reasoned merge closures where no one realizes the problem with the target, that you then cannot undo, and on the other hand frequently makes it impossible to merge things where there is a consensus to merge, because AfDs are very brief and you cannot reopen after a keep closure for several months. Previously, you could open a merge discussion after an AfD if there was a no consensus or technical keep close, but now you have to wait upwards of 6+ months after an AfD close to do anything. Hell I once got someone mad at me for reopening a no consensus AfD ten months later. See current clusterfuck at 1993 Philadelphia meeting; whereas before we could have had a reasoned merge discussion, now we cannot.
There was a reason that merges frequently took a long time and it was because they were hard to do well and are frequently not the right thing to do, so they took time. Now we're just making bad decisions quickly. This will make it so we are making bad decisions quickly at MfD. PARAKANYAA (talk) 05:09, 14 August 2026 (UTC)
I am a bit flummoxed that you would prefer the old "AfD for 3 weeks, then spend another 3+ weeks on a merge discussion" over the new method where both are decided at the same time, saving vast amounts of editor time and energy not reiterating the exact same thing a second time. Not to mention starting a merge immediately after an AfD keep could feel impolite and disruptive. In other words, I agree to disagree completely on this stance. ᴢxᴄᴠʙɴᴍ (ᴛ) 05:27, 14 August 2026 (UTC)
The vast majority of AfDs do not extend to 3 weeks and the "problem cases" are always going to take longer and we should be given more time to discuss them as it is fundamentally a content issue that is about content rather than "does the thing meet notability y/n". Notability is a standard to meet, while whether something should or should not be merged frequently depends on the current page; that can change much, much faster than the existence of sources does. Merging PM into AfD is forcing AfD to make content decisions rather than a "should the article exist y/n" binary as was previously. This is terrible. It's not impolite because there were different considerations at AfD than merging; now the merging considerations have been abandoned, e.g. WP:PAGEDECIDE is routinely ignored. PARAKANYAA (talk) 05:57, 14 August 2026 (UTC)
Yes. Harmless. Aligns MFD with other XFD processes. Useful. –Novem Linguae (talk) 03:52, 14 August 2026 (UTC)
Yes per my comments at the prior discussion. This fills a hole, and will make it easier to merge some of the many redundant pages we have in projectspace (which is absolutely something we should be doing to reduce the maintenance burden, but can struggle to do when vested parties are the !voters). Sdkbtalk 04:52, 14 August 2026 (UTC)
Yes, not because I think there are a huge number of stagnant merge proposals that need a venue right now, but because I don't want future editors hitting a wall when they can't get consensus on the talk page. With PAM gone, we need a place for formal merge discussions of pages not covered by other xfds, and this looks like the easiest way to get one. I'm not worried about expanding mfd's scope; it's already a wastebasket xfd whose scope is everything the others don't cover. I don't see how adding merge proposals to that scope will hurt it. Chessenjoyer (talk) 14:18, 14 August 2026 (UTC)
Yes. Can't hurt, and having a venue for this is better than not having one. I don't think that discussion about the AfD-PAM merger is relevant here; what's done is done unless we have a specific discussion about re-opening PAM or something similar. —Leaf.Sheap⇖ /.°°.\ ⇗ (They•Them) 19:30, 14 August 2026 (UTC)
Is there any reason why we can not have more than one “approved” venue for proposing and discussing mergers? I would have no problem saying that mergers can be proposed and discussed on talk pages AND at MFD (although not both at the same time). Blueboar (talk) 22:12, 14 August 2026 (UTC)
This proposal wouldn't stop editors from discussing merges on the talk page. Chessenjoyer (talk) 22:17, 14 August 2026 (UTC)
If this is approved, I hope any guidance is clear in not only allowing but encouraging talk page discussions. —Myceteae🍄🟫 (talk) 22:28, 14 August 2026 (UTC)
That's what they said about the PM-AfD merger and yet the merge police go around moving all the discussions to AfD. Katzrockso (talk) 22:32, 14 August 2026 (UTC)
I thought those are because the ones that started the discussion were trying to use PAM by using merge tags. Chessenjoyer (talk) 22:48, 14 August 2026 (UTC)
Whatever the reason, it would be nice to anticipate the problem and try to get ahead of it for project page mergers. Most if not all of these discussions are best handled on talk pages. If this proposal is approved, MFD should be reserved for cases where another approach has failed and more input is needed. —Myceteae🍄🟫 (talk) 23:18, 14 August 2026 (UTC)
No it shouldn't. It should be reserved for cases where the nominator believes the merge is controversial, just like at AfD. FaviFake (talk) 10:30, 15 August 2026 (UTC)
It should be reserved for cases where the nominator knows the merge is controversial, because it is opposed. Write the guideline in terms of evidence, not an editor’s beliefs. I.e., advice is: Try to fix things yourself before starting a community discussion. Cf WP:SOFIXIT. SmokeyJoe (talk) 11:30, 15 August 2026 (UTC)
I agree with FaviFake, the guidance should be the same for all merges regardless of what type of page it is. Thryduulf (talk) 12:17, 15 August 2026 (UTC)
Why is that? Katzrockso (talk) 02:56, 16 August 2026 (UTC)
Let me turn the question around: why should MfD have a completely different process and different rules for which pages are eligible for being nominated for merging compared to literally all other XfD processes? FaviFake (talk) 09:32, 16 August 2026 (UTC)
Because it has a completely different scope, different editors who regularly participate.
Lots of things are different - CfD and TfD allow non-admins to close discussions as delete, for example. All the forums have different levels of participation.
Your question here really highlights the point @Alalch E. has made several times in recent discussions - the urge for symmetry and order just for its own sake. Katzrockso (talk) 15:58, 16 August 2026 (UTC)
+1 The various XFD venues work best by bringing together editors with relevant knowledge and interest regarding the page type and its typical deletion and ATD considerations alongside editors with expertise and experience relevant to the specific page(s) or topic area in the nomination. If editors who are active on a Help page or two related WikiProjects can't agree on a merger then punting it to MFD is like trying to force a square peg into a round hole. —Myceteae🍄🟫 (talk) 23:43, 16 August 2026 (UTC)
To clarify for the 100th time, the "merge police" (a.k.a. yours truly) is only moving to AfD formal PAM discussions, not informal talk page discussions. I have explained this extensively at my talk page. FaviFake (talk) 15:40, 15 August 2026 (UTC)
What I see in that thread is editors who disagree about what constitutes a formal PAM discussion¯\_(ツ)_/¯ —Myceteae🍄🟫 (talk) 17:36, 15 August 2026 (UTC)
What do you think constitutes a formal PAM discussion? FaviFake (talk) 22:43, 15 August 2026 (UTC)
I think all of the discussions you listed here were appropriate to start on talk pages and I think this should be encouraged. It sounds like there's a lack of clarity as to the definition of a formal PAM discussion and that at least some editors don't think that using a {{merge}} tag and starting a local discussion on a talk page is equivalent to a PAM (or AFD) listing. —Myceteae🍄🟫 (talk) 23:33, 15 August 2026 (UTC)
How are we supposed to clear the PAM backlog to allow the PAM-AFD merge to continue without removing the {{PAM templates}}? I don't understand this reasoning; there was consensus to wound up PAM, but I shouldn't modify or move the new PAM discussions even if they use the {{PAM templates}}? How are we supposed to shut down the PAM process if editors can just keep using it as before? I'm genuinely confused. FaviFake (talk) 09:30, 16 August 2026 (UTC)
I don't know. The whole thing seems to be quite a mess and a source of ongoing confusion and recurring disputes well beyond project space mergers. —Myceteae🍄🟫 (talk) 15:51, 16 August 2026 (UTC)
Well, I'm not confused. If I see a PAM template, I move it to AfD. If i don't see a PAM template, i don't move it. As simple as that. FaviFake (talk) 15:52, 16 August 2026 (UTC)
The PAM process is the Wikipedia:PAM page which has already been marked historical. There's nothing more to do there. Katzrockso (talk) 15:59, 16 August 2026 (UTC)
So, if the page that describes the process is marked historical, editors can simply follow that historical process exactly as written? After there was consensus to shut down that process? FaviFake (talk) 16:07, 16 August 2026 (UTC)
As WhatamIdoing explained on the talk page discussion you linked above, many editors believed that it was listing a discussion at PAM that made something a PAM discussion. Katzrockso (talk) 17:40, 16 August 2026 (UTC)
As WhatamIdoing noted, a lack of shared understanding means the RfC failed. Katzrockso (talk) 18:49, 16 August 2026 (UTC)
Also, I don't know if you're misremembering or mischaracterizing, but the automated transclusion step didn't happen until after the RfC started (see here). Previously, you had to manually advertise the discussion at WP:PAM with an edit like this one. That was the step that made a talk page discussion into a PAM merger. Katzrockso (talk) 19:05, 16 August 2026 (UTC)
The transclusion was indeed added during the RfC, but in 2025, the year prior to the RfC, PAM was a list of links to every single open merge discussion, detected based solely on the {{PAM templates}}. So either the RfC was to shut down the list of wikilinks, or it was to shut down the entire process. FaviFake (talk) 19:13, 16 August 2026 (UTC)
Sure! But to initiate a review of the closure of an RfC, you need to go to WP:AN, not here. FaviFake (talk) 18:51, 16 August 2026 (UTC)
I'm not advocating any review of the closure, so I'm unsure where this is coming from. "Failed" doesn't mean the consensus was derived wrongly. Katzrockso (talk) 19:06, 16 August 2026 (UTC)
Then if consensus was derived correctly what's your point? FaviFake (talk) 19:09, 16 August 2026 (UTC)
a lack of shared understanding means the RfC failed. I took this to mean:
If editors who !voted the same way didn't actually agree on the meaning/scope/impact of their !votes, that is a type of RFC failure.
If editors thought they were !voting for one thing and their !vote ended up supporting a different outcome, that is a type of RFC failure.
If the closer accurately assessed consensus as written, but editors using the same words actually meant different things, that is a type of RFC failure.
Unintended consequences, collateral damage, and implementation challenges might also be considered a type of RFC failure. —Myceteae🍄🟫 (talk) 15:59, 17 August 2026 (UTC)
I agree with Myceteae. Anyone who frequents RFCs will have seen the occasional response that's mislabeled ("Shall we remove this?" "Oppose, because we should remove this!"). Those are usually easy to spot, but there are more complicated situations. If, for example, we have a consensus to ____, but when you start implementing (your idea of) ____, a supporter complains, that can be because you and the supporter have different ideas of what ____ looks like. WhatamIdoing (talk) 21:01, 17 August 2026 (UTC)
Allowed, but not encouraged. No examples have been offered where this would be a better venue. Projectspace merges, eg essays, might be desirable to tidy up “too many essays”, but there is little good reason to set a timeframe for the decision, it is not like the outward facing product is affected. Don’t encourage busywork nominations. Don’t encourage merging of drafts. I suggest that taking a merge to MfD should require that there is a noted objection to the merge being boldly done. MfD should not be used to advertise a merge that no one cares about. Where it is a matter of any importance, eg merging two guidelines, and with any disagreement, it should go to RfC, although maybe this should be a possible outcome of the MfD as opposed to a rule. SmokeyJoe (talk) 23:35, 14 August 2026 (UTC)
As previously, I think there is a danger of this confusing the scope of MfD. I see little advantages, and possible difficulties with more instructions to have to wade through. -SmokeyJoe (talk) 23:38, 14 August 2026 (UTC) (moved from almost empty discussion section. FaviFake (talk) 17:01, 4 September 2026 (UTC))
Allowed but put additional BEFORE breaks on with respect to actual sustained disagreement on merge, like insist on failure to fix through normal editing and sustained talk page effort to address or narrow the issues (should, this or that be the merge target, or should there be more than one target, in other words splitting the page, and then deciding on the correct redirect for the title, the narrowed issues on which disagreement remain then can go to MfD in a clearer state (As for other issues mentioned, length of MfD discussion and after the merge, those can also be addressed to ameliorate them but likely need another discussion.). Alanscottwalker (talk) 12:50, 15 August 2026 (UTC)
I don't believe this kind of restriction is needed. At other venues like TfD, editors are even obligated to use the full process even if the deletion is extremely uncontroversial. You can't require someone to try to boldly merge the pages even if they're convinced that their efforts will be reverted. That just encourages terrible cut-and-paste mergers just so that they can be reverted and the merge can be brought to MfD. It's ridiculous. FaviFake (talk) 15:16, 15 August 2026 (UTC)
Normal editing does not encourage "terrible" stuff, unless you believe all editing is terrible. We allow normal editing in moves even though it may cause problems, but we don't assume all normal editing causes problems. Ridiculous is your assumption that it does. Also ridiculous is your claim that I suggested doing so, when "they're convinced that their efforts will be reverted." I did not suggest that at all. Editing against even suspected opposition to a merge is not encouraged, in the least. You talk it out. I'm suggesting, we should list what editors should try to talk about before they arrive at MfD, narrowing issues, discarding alternatives, and process steps. Even if the rule would be you must still have an MfD, the MfD would benefit by that discussion ('Most everyone on the talk page supports merge for these reasons, so . . .'; 'Everyone on the talk agrees on merge but can't agree where'; 'We have a contested merge on the talk page, these are the issues that have been raised; etc.). -- Alanscottwalker (talk) 12:47, 16 August 2026 (UTC)
No... because it generally makes little sense in too many cases. There is no corresponding process for formally proposing that a draft be merged into an article, or even into another draft!—Any draft can be merged into an article through the normal editing process (a redirect may be left behind in some cases). If anyone objects, that is a matter for article talk or in extreme cases an RfC or another form of dispute resolution (regarding the content in question). MfD does not settle mainspace disagreements. Two drafts can easily be merged. If anyone objects, a draft can be created at a different title (draftspace) or a personal draft can be created (userspace) with one's preferred version. There can be many drafts covering the same potential topic. It would never be appropriate to discuss such things at MfD (attempting to do so would even result in a speedy redirect in certain instances). That aside—shifting content between policy, guideline, information, help, etc. pages should generally be hashed out on the respective talk pages; if more structure is needed for that, well... reopen PAM. Essays are a bit more complicated. Userspace pages should generally be left alone as a whole. When or when not a merge discussion is appropriate at MfD is not easily discerned (apparently). Merge is already a possible outcome at MfD, and anyone (likely seasoned) bringing a good case there (e.g. an information page that is truly redundant to a different help page) would already invite a good discussion (and likely not encounter any resistance). However, encouraging merge discussions there may lead to many poor nominations (such as the inappropriate ones I describe in the first half of my rationale). —Godsy(TALKCONT) 07:35, 17 August 2026 (UTC)
People misusing MfD to nominate drafts or userspace essays is a hypothetical problem. I don't foresee it happening, and if it did by some fluke editors could !vote it down and/or make the instructions clearer. Sdkbtalk 02:55, 14 September 2026 (UTC)
No because this sounds more like a solution to a problem that does not exist, with a solution that could cause additional problems. Skarmory(talk •contribs) 17:27, 24 August 2026 (UTC)
The problem is that, without this, the only venue to propose merges is at talk pages, and merges proposed at talk pages often fail when they ought to succeed because editors feel ownership over a page they created and the costs of having to collaborate with another editor who "owns" a redundant page with the same scope are borne individually whereas the benefits of eliminating redundancy are collective. Having a centralized venue means that it isn't just local editors weighing whether a merge is beneficial but a broader group. Sdkbtalk 02:23, 25 August 2026 (UTC)
Having to start a discussion at a talk page and then go through a publicizing/dispute resolution process once it becomes contentious, rather than just being able to start a discussion at a centralized venue directly, introduces another step to the process. The more annoying it is to try to merge redundant pages, the less it's going to happen. And we already don't have enough editors willing to propose merges in projectspace, which has led to the current proliferation of redundant essays. Sdkbtalk 02:32, 25 August 2026 (UTC)
But many such proposals get no response at all, even for fairly important pages, so going to MFD is more work than dropping a note on the talk page, seeing that nobody replies, and merging the pages. To give an example, in 2011, I tagged Wikipedia:Independent sources and Wikipedia:Third-party sources for merging. In 2012, someone removed the tags because there had been no objection. I actually didn't get around to doing the merge until 2016. Nobody objected. Nobody asserted ownership. Nobody complained. Going through MFD would have added unnecessary work to this process. WhatamIdoing (talk) 03:22, 25 August 2026 (UTC)
In the prior discussion, there was a lot of opposition to routinely bringing essay merge proposals to MFD. The general sentiment seemed to be that they are and should be rare. I don't mean to nitpick but this was a major sticking point early on in the attempt to characterize the scope of the purported problem and proposed solution. —Myceteae🍄🟫 (talk) 21:45, 25 August 2026 (UTC)
I can tell you from my general experience that those rarely work. For example, a WP:3O is not binding, so if two editors disagree strongly it's not going to lead to anything, and the "talk pages of relevant WikiProjects" almost never attract enough editors.Your same argument could be used to argue against the institution of any XfD venues. Article redirection discussions, template merging discussions, redirect target discussions... of course they can be publicised, but there's a reason why we have streamlined and centralised processes for these specific types of proposals. FaviFake (talk) 08:14, 25 August 2026 (UTC)
A Wikipedia:Third opinion isn't binding. Neither is an RFC, for that matter. But consensus is binding, no matter where or how you find it, and third opinions and RFCs are both good steps to take in the process of finding consensus. WhatamIdoing (talk) 18:06, 25 August 2026 (UTC)
No. As above commentators have noted, in the cases of desired merges on pages without other interested parties contributing to the talk page, the most appropriate response is to merge the page yourself. If the merge is controversial, someone will talk about it, at which point the above problem is solved. This rule change will encourage merging to become further abstracted from mainspace editing, implicitly discourage low-experience/non-hooked-in editors from merging themselves, and lead to a slew of merges that don't really make much sense. I agree very much with Voort's comment that we need an easier way to get folks involved in dormant talk pages (that's a bit less forbidding than existing channels), but I think this will create more problems than it solves. Pudelpointed (talk) 19:20, 24 August 2026 (UTC)
If the merge is controversial, someone will talk about it, at which point the above problem is solved. No it's not! That just means that 1 editor wants to merge the pages an another editor doesn't! They aren't going to magically produce a consensus amongst themselves, and at the same time more people are not going to chime in because the page is obscure and not watchlisted by enough people. That's why we have centralised XfD venues in the first place... FaviFake (talk) 08:18, 25 August 2026 (UTC)
How many of these non-article pages have you proposed for merging recently? It's my experience that the current system works fine. It appears to be yours that it doesn't. So: What have you tried to merge, and what problems have you run into? WhatamIdoing (talk) 18:04, 25 August 2026 (UTC)
Looking at my history, this is an example of a merge nomination I made that took more than a year to implement. Ridiculously long delays were one of the primary reasons we shut down WP:Proposed article mergers earlier this year and merged it into AfD. But you can't AfD a non-article, which has led to the process hole we're now trying to fill. If we don't, we're likely to end up with the same delays around merges of non-articles. Sdkbtalk 19:28, 25 August 2026 (UTC)
It's not clear that speeding it up would have produced a better outcome nor that MFD would have attracted better participation than, say, a Village Pump discussion. —Myceteae🍄🟫 (talk) 20:38, 25 August 2026 (UTC)
@Sdkb, would you say it's important to you that the decision for/against a merge be made quickly? WhatamIdoing (talk) 21:56, 4 September 2026 (UTC)
While I'm often of the view that there's no deadline, when we're talking about a scale of a year-plus, that's an extremely slow pace to be improving the encyclopedia that means many users are likely to encounter the confusion of duplicative pages before the issue is fixed. And that presumes discussions are resolved at all, rather than just dying because the nominator forgot about them or retired during that span. Sdkbtalk 22:19, 4 September 2026 (UTC)
No. My summary will be brief to save the closer some time. The reasons previously given (above) to make this change do not seem to outweigh the reasons given against, so far the proposal in not very compelling imho. Cheers. DN (talk) 19:10, 25 August 2026 (UTC)
Yes - Predictable processes are desirable, so absent any compelling reason not to (and I haven't seen any articulated here), yes they should be allowed to align it with other XfD. Also, it's not like MfD is drowning in nominations -- it could withstand more activity (not that this will even add that much activity). Obviously going to MfD is not required to merge something, just as it's not required to do so in articlespace. —Rhododendritestalk \\ 16:53, 3 September 2026 (UTC)
What is unpredictable about the status quo? Katzrockso (talk) 04:10, 4 September 2026 (UTC)
I feel like we just went through a round of "Oh, no, using AFD to merge articles won't be required", and that's not how it's worked out in practice. People had different ideas about what it meant to "use the WP:PAM system". WhatamIdoing (talk) 04:16, 4 September 2026 (UTC)
Without reiterating the same arguments as above, I do want to point out that very few PAM proposals would have to be moved to MfD, because miscellaneous pages are involved in far fewer PAM proposals compared to articles. FaviFake (talk) 07:53, 4 September 2026 (UTC)
It is a valid concern that every project space merge discussion will be shunted to MFD if this passes, given the experience with AFD. —Myceteae🍄🟫 (talk) 16:19, 4 September 2026 (UTC)
My point is that it would not be a concern because miscellaneous pages are involved in far fewer PAM proposals compared to articles. The "experience with AfD", whether you think of it as positive or negative, was due by the fact that PAM proposals were opened very often, which has never been the case for miscellaneous pages. FaviFake (talk) 16:27, 4 September 2026 (UTC)
You previously shared a list of merge proposals that you thought would have benefitted by going to MFD. I disagreed. Common or not, editors already disagree on when a "formal" process is needed and when it should take place on talk pages or be allowed to run longer than the typical 1–2 weeks. The experience with AFD is that it has flattened merge discussions so that they must all go to a single venue and wrap up fairly quickly, despite repeated assurances that it doesn't have to be that way. I think that is bad. And I don't think that should happen with project space mergers. —Myceteae🍄🟫 (talk) 16:53, 4 September 2026 (UTC)
I noticed that almost 60% of the comments in this RfC were posted by you, Katzrockso, and me (3 out of the 24 participants). I think this is a good time to stop reiterating each other's positions now:) FaviFake (talk) 17:06, 4 September 2026 (UTC)
I think both positions have some merit. It should be permitted to take mergers to MfD but explicitly not required to do so. Moving an ongoing discussion started on a talk page to XfD without the consent of discussion participants should be treated as disruptive editing. Objections to a merge discussion at XfD on the grounds that it should be on a talk page should be ignored as contrary to policy. i.e. allow the discussion initiator to pick the venue, and the discussion stays at that venue unless and until there is a consensus to move it. Thryduulf (talk) 20:58, 4 September 2026 (UTC)
Time for some math:
"This is a concern because 100% of the pages would end up at MFD"
"This is not a concern because only five pages would end up at MFD"
Both of these statements can be true at the same time, if there are only five pages being considered for merging. WhatamIdoing (talk) 21:55, 4 September 2026 (UTC)
No. The merge process being merged into AFD from my experience has been a success. Having too many routes to raise and discuss stuff is just to complicated for new users, and those who argue against are normally editors who dont want change because we have done it that way for years.Davidstewartharvey (talk) 05:20, 14 September 2026 (UTC)
... Why would new users need to propose controversial projectspace merges? And how is one route "too many routes" ...? FaviFake (talk) 05:40, 14 September 2026 (UTC)
Wikipedia has so many places you have to go to, fave or read as a new user it is totally confusing. We moan that we are not getting new editors involved with the project, but making it difficult and complicated. A one stop shop for raising issues such as deletion and mergers for "all" spaces would make it simpler and far less difficult to find.Davidstewartharvey (talk) 08:18, 14 September 2026 (UTC)
It sounds like you don't fully understand the current status of the XfD processes (which, as you say, is confusing ... difficult and complicated). Could you kindly describe your understanding of the current process for proposing merging misc pages and what you think this proposal is trying to do? The rationale you've given to oppose the proposal is the one we are using for supporting it, so there seems to be a disconnect. We are indeed trying to create a one stop shop for raising issues such as deletion and mergers of misc pages, as currently they can't be nominated anywhere. FaviFake (talk) 16:36, 23 September 2026 (UTC)
@Davidstewartharvey, the article merge process being merged into AfD was a success, but AfD will never accept non-article merges. This proposal is about applying the exact same thing to non-article merges, which we have every reason to believe will be successful for the exact same reason. It's not creating another redundant forum for such merges; it's designating such a forum when currently there is none. Newcomers absolutely won't be served by having to suggest/discuss merges on low-visibility talk pages where discussions can take more than a year to play out. Rather, they'll be best served by having the merge banner clearly point them toward the centralized MfD discussion. If that influences your thinking, feel free to adjust your !vote accordingly. Sdkbtalk 15:12, 14 September 2026 (UTC)
No. Solution in search of a problem. Stifle (talk) 08:47, 23 September 2026 (UTC)
If this proposal passes, how should new PAM discussions be handled?
This issue has been brought up above multiple times but I think it would benefit from a more focused discussion. If these three conditions are met:
this proposal passes
a user creates a new formal PAM for a miscellaneous page (defined as using one of the {{PAM templates}})
the TfD consensus that the PAM templates become wrappers of the AfD merging templates has not yet been implemented
... what should the editors that have been working on shutting down PAM (aka yours truly) do?
A) Remove the {{PAM templates}}, thereby effectively turning the proposal into an informal talk page discussion.
Neither. That was not specified in the RfC, which merely permits proposals being brought to MfD. The RfC doesn't specify anything about what to do with the former methods for miscellaneous pages. Katzrockso (talk) 08:56, 6 September 2026 (UTC)
Please, can we avoid re-litigating the result of the RfC again? The RfC specifies that PAM is merged into AfD. If we don't remove the PAM templates from misc pages, they will just end up in the AfD backlog once the TfD consensus is implemented, and then an AfD regular will likely wonder why there's an AfD template on a misc page and remove it anyway.Pick either A or B. Or another option that doesn't make it more complicated for us to implement the consensus. FaviFake (talk) 09:03, 6 September 2026 (UTC)
You can't force a false binary into this RfC. If this RfC closes with consensus in favor of the change specified, it makes no comment about what to do with existing talk page discussions. You can't interpret it like that and expand your talk page policing changes to more of the encyclopedia. Katzrockso (talk) 18:19, 6 September 2026 (UTC)
I never suggested moving existing talk page discussions, only those created after the closure. And of course I'm not touching informal talk page discussions.I specifically asked this question so that the closer can hopefully be a little more specific as to how exactly the result of the RfC should be implemented while we wind down PAM.From your previous comments, I'd say you seem more opposed to B rather than A. I'd also be interested to know if Thryduulf's opinion in this comment also refers to new formal PAM discussions rather than just informal talk discussions. FaviFake (talk) 22:00, 6 September 2026 (UTC)
It does apply. Thryduulf (talk) 22:44, 6 September 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.
RfC: Geographic disambiguation of school article titles in the United States
§Question 1: Should the name of the city be included when using geographic disambiguation for primary and secondary schools in the United States?
§Question 2: If yes, should the state also be included by default, or only under certain circumstances? If the state is not always included, when should it be?
§Question 3: Should we develop a naming convention covering all school articles?
§Question 4: Should we develop a naming convention that covers schools, museums, churches, libraries, and similar institutions and buildings?
00:00, 13 October 2026 (UTC)
Background
Recent RMs involving US secondary school articles have produced many different outcomes regarding how their titles should be geographically disuated. Assessment of actual practice in article titles reveals a lack of consistency. The issue has been whether it should be identified by its state, its city or other settlement, or both its city and state.
Some editors favor state-based disambiguation. Others favor city-based disambiguation. Always using '(City, State)' regardless of the need for further disambiguation would produce a consistent result but is less concise than state-only or city-only. Other suggestions have included considering whether the US city is the primary topic for its name or whether it is a major city as described at WP:USPLACE.
Should the name of the city be included when using geographic disambiguation for primary and secondary schools in the United States?
Yes. The name of the city should be included by default. This has been the trend in recent RMs, although these are not definitive given divergent outcomes in a number of ways, previous RMs, and overall variation in practice. It is natural and logical to localize schools, churches, bank buildings, and similar buildings and institutions to the city where they are located. Article titles should be recognizable to people familiar with the subject. Most people familiar with a school will know which city it is located in. The use of cities to disambiguate is the overwhelmingly common approach used in every other place we have looked during these RMs, including England and Wales, Ireland, Australia, New Zealand, India, and Hong Kong. This is true for obscure villages and major metropolises. We can use parenthetical disambiguation since that approach appears to be favored already, e.g. Wikipedia High School (Chicago). I don't have strong feelings about whether to always include the state or to take a different approach based on primary topic, WP:MAJOR city designation, or the need for more complete disambiguation. —Myceteae🍄🟫 (talk) 01:04, 13 October 2026 (UTC)
No, because most "cities" are small towns. Nobody has any idea where these little towns are. Give the name something that someone can recognize, whether that's a major city, a state, or a country. Wikipedia High School (Chicago) is fine, because Chicago is a major city, but let's not have Wikipedia High School (Smallville), and let's also not have the very long Wikipedia High School (Smallville, Massachusetts) when the WP:CONCISE option of Wikipedia High School (Massachusetts) is sufficient to differentiate it from all others. WhatamIdoing (talk) 01:14, 13 October 2026 (UTC)
And mostly: Let's not actually care so much about whether the article titles for schools in one country use the same dab format as the schools in another country. I think that a rule of "if it doesn't conflict with another, then leave it alone" would do. Or maybe we could set up a WP:QPQ-like system: Anyone who persists in suggesting this type of page move has to add or improve a paragraph in Hobgoblin first. I suggest the one about Emerson on foolish consistency as a starting point. WhatamIdoing (talk) 01:27, 13 October 2026 (UTC)
It seems the norm is what we did with the Connecticut and Illinois examples? — VPP (t/c) 01:30, 13 October 2026 (UTC)
There's no norm, as evidenced by the dozens of RMs and thousands of article titles we've looked at. See here and the various other discussions linked in the background for more info. —Myceteae🍄🟫 (talk) 01:39, 13 October 2026 (UTC)
At a glance, Independence, Oregon is too small to meet my compromise approach for kind-of-major cities, half are already at the state name, and all the others are already correct and consistent. WhatamIdoing (talk) 01:51, 13 October 2026 (UTC)
I've looked at dozens of lists of schools and they are all over the place. For example, for whatever reason, '(Cincinnati, Ohio)' is a more common disambiguator than '(Cincinnati)' for schools, buildings, etc. despite Cincinnati being WP:MAJOR. For your compromise, how are we determining kind-of-majorness? —Myceteae🍄🟫 (talk) 02:12, 13 October 2026 (UTC)
Well just MAJOR it, and only if there are two high schools in the same state, go to further disambiguation according to the standard practice, add 'community, state'. Alanscottwalker (talk) 13:19, 13 October 2026 (UTC)
Although that's true for Cincinnati schools, it's different for other institutions and other cities. Overall, there is a 51:43 split between articles using '(Cincinnati, Ohio)' versus '(Cincinnati)'. It's also very different for different cities. For Chicago, it's 1:314, and there is an open RM for the 1. For Detroit, it's 7:99, with an open RM for 1 (the same RM). — BarrelProof (talk) 14:36, 13 October 2026 (UTC)
In re "how are we determining kind-of-majorness": A kind-of-major city isn't in Wikipedia:List of U.S. cities with Wikipedia article names without state (because those would be WP:MAJOR instead), and editors form a consensus that it's still large/famous enough to be recognized by many Americans. I would predict that their decision would be correlated with state capitals (e.g., Providence, Jacksonville, Phoenix), being the biggest city in its state (e.g., Louisville), and – for better or worse – professional sports teams (e.g., Phoenix again). WhatamIdoing (talk) 17:38, 13 October 2026 (UTC)
Are there no similarly-named schools within a single state? CMD (talk) 02:54, 13 October 2026 (UTC)
There are. Currently these are either disambiguated as '(City)' or '(City, State)'. There are also similarly named schools in different states. These are currently disambiguated '(State)' or '(City, State)'. —Myceteae🍄🟫 (talk) 03:07, 13 October 2026 (UTC)
I tried to clarify the scope and intent of this RFC below. If we pick one default standard approach, there will inevitably be cases where a different title optimal in terms of particular considerations like the need for additional disambiguation. Using '(City, State)' for all would address most of this but some editors are (understandably) bothered by forcing a less WP:CONCISE title where it's not otherwise necessary. —Myceteae🍄🟫 (talk) 03:58, 13 October 2026 (UTC)
Yes. People primarily look up schools in terms of what city they are located in, not what state. If I were looking for my local school in Smallville, Mystate, I would be searching for "Wikipedia High School Smallville", not "Wikipedia High School Mystate". Schools are local institutions, not pertinent to an entire state. Wikipedia High School doesn't matter to most people outside of Smallville.Katzrockso (talk) 03:38, 13 October 2026 (UTC)
Except when the school that is physically located within the city boundaries also serves students who live in Neighborton and Tinyville, and now you're looking for the school in the wrong city.
This happens a lot in rural areas. Traveling 50 miles (an hour each way) to get to high school is not unheard of in rural areas. I learned recently of relatives who had to move to a different town so he could attend high school. There simply wasn't a high school within daily commuting distance of their home, so when you finished 8th grade, they sent you off to the nearest big town, where you rented a room and got an after-school job to pay for your room and board. WhatamIdoing (talk) 17:47, 13 October 2026 (UTC)
Wherever the school is actually located, even if it serves students from another area, the residents of Neighborton and Tinyville are still going to think of the school as "in Smallville". Katzrockso (talk) 21:32, 13 October 2026 (UTC)
Indeed. I don't think we make these considerations for churches or parks. I'm sure the following situation does arise: "I know my cousin lives in Smallville, and I know the name of her high school, but I don't know the names of any of the surrounding communities, and I'd like to read about her high school on Wikipedia". I'm just not convinced this should be the dominant consideration in naming articles about (hyper)local institutions. —Myceteae🍄🟫 (talk) 21:58, 13 October 2026 (UTC)
Yes, for exactly the reasons stated by Katzrockso. - Jmabel|Talk 06:47, 13 October 2026 (UTC)
Yes. Absolutely. City makes far more sense than state. -- Necrothesp (talk) 09:28, 13 October 2026 (UTC)
Probably for schools that are clearly in a city and not outside the settlement but within the municipality. Otherwise no, just the state should be used unless further disambiguation like the county etc is needed. Crouch, Swale (talk) 11:09, 13 October 2026 (UTC)
Very much Yes per taxonomic rank. There's no reason for us to be quirky or iconoclasts. We should be boring and procedural. — VPP (t/c) 12:37, 13 October 2026 (UTC)
Yes City is clearest and makes more sense per above. Timrollpickering (talk) 12:50, 13 October 2026 (UTC)
NoHometown High School (Hometown) is redundant. And Centerville High School (Centerville, State) is likely not concise. The usual disambiguation should be just state if needed, and 'city, state' if there is an in state conflict. Alanscottwalker (talk) 13:35, 13 October 2026 (UTC)
Yes per Katzrockso. Schools (typically) serve very local communities and should be titled to reflect that. I would be amenable to an exception for cases where the school's name is "TownName High School" (or Middle School, etc) verbatim, but otherwise I think the approach is sound. ModernDayTrilobite (talk • contribs) 13:59, 13 October 2026 (UTC)
No. The point of disambiguation is to distinguish titles, not to provide precise locations or make assumptions about what location a school is "associated with". As I've said on other discussions, WP:TITLEDAB: "According to the precision criterion, only as much detail as is necessary to distinguish one topic from another should be used." Since a standard title without disambiguation won't have a city or state (even when a high school is named after the town it's in), it seems odd to require "city, state" to disambiguate in all instances. States are well-enough known on their own to accomplish that and a natural way to distinguish between topics of the same name. When two or more of the same school names exist in the same state, then yes, you add the city since just the state in those cases isn't enough detail to distinguish. Also bear in mind that many rural high schools have a mailing address for a city they are not located in.
And yes, as others have said, using "city, state" across the board would make many titles both unnecessarily redundant and unnecessarily long, giving us something like "Salem High School (Salem, Massachusetts)" and "Salem High School (Salem, Ohio)", when in both cases (and as they currently stand) the state alone accomplishes the job of distinguishing between the two. -- JonRidinger (talk) 15:19, 13 October 2026 (UTC)
I believe that the point of this RFC is to declare that, if we have two "Central High Schools", the detail that is necessary to distinguish them is that one is Central High School (Smallville) and the other is Central High School (Neighborton), rather than by saying that one is Central High School (Florida) and the other is Central High School (New York). The "(City, State)" style would only come into play if there were two Central Highs with cities of the same name, e.g., Central High School (Smallville, Iowa) and Central High School (Smallville, Ohio). WhatamIdoing (talk) 17:57, 13 October 2026 (UTC)
The point of this RFC is to determine which approach we should use. —Myceteae🍄🟫 (talk) 18:38, 13 October 2026 (UTC)
No. Unless it is needed for precision to avoid conflict with other similarly named schools in the same state. Many schools provide services to multiple localities, not only to the city/town where it happens to be located. older ≠ wiser 17:13, 13 October 2026 (UTC)
No per Alanscottwalker and Whatamidoing. A sizable proportion of high schools are named after the city they are in; an article title like Smallville High School (Smallville, State) is redundant. If this proposal is passed, it should be with a clause that the city name need not be included as a disambiguator if the high school is already named after the city. Shocksingularity (talk) 20:47, 13 October 2026 (UTC)
A provision like this is reasonable. The question is whether the name of the city should generally be included. The main argument in favor is that primary and secondary schools are local, not statewide, institutions. Smallville High School (Nebraska) accomplishes this. We do have a pair of articles that satisfies this approach in Aiken High School (South Carolina) and Aiken High School (Cincinnati). I thought about this during the Cincinnati school's RM but didn't raise this point. —Myceteae🍄🟫 (talk) 21:26, 13 October 2026 (UTC)
No. I would argue that if a school is named after the city it resides in and/or is the only school going by a certain name, a disambiguator is unnecessary. In other cases, the state/province/region should be used. If the city it resides in is particularly large and widely known, the city may also be used, but not both. In solidarity, DollarStoreBa'al (Converse) 18:20, 14 October 2026 (UTC)
In the interests of gathering more evidence, disambiguation by state alone seems quite common for higher education institutions in the US, e.g.:
Should the style with the state only (with exceptions perhaps for WP:MAJOR cities – I think Cleveland and New York City are the only ones in these examples) be used for US educational institutions across the board, or should secondary (and lower) schools follow a more "localized" style? Ham II (talk) 18:54, 14 October 2026 (UTC)
A recent move that didn't go in this direction is University of St. Francis – which needed to be disambiguated from the University of Saint Francis (Indiana) – moving not to University of St. Francis (Illinois) but to University of St. Francis (Joliet). (Admittedly there was very minimal participation in the RM.) For what it's worth, the seal in the lede picture reads "UNIVERSITY OF ST. FRANCIS . JOLIET . 1920", and the logo on the official website reads "UNIVERSITY OF/ ST. FRANCIS/ JOLIET, ILLINOIS". Meanwhile, the university in Indiana has "UNIVERSITY OF SAINT FRANCIS/ FORT WAYNE, INDIANA" on its seal, but "UNIVERSITY OF/ SAINT FRANCIS/ INDIANA" on the logo on the official website. So, in official usage in those two examples there's a mix of every form of "disambiguation" under consideration here. Ham II (talk) 13:04, 25 October 2026 (UTC)
I get wanting to find the most fitting qualifier, but I'm not so sure looking to seals or logos is the the most consistent way of disambiguating schools, or necessarily reflective of what is most in common use, which would presumably be the better choice if we were to go that route. Οἶδα (talk) 16:40, 25 October 2026 (UTC)
We should look at usage in reliable sources, and/or follow any applicable naming convention (which we don't have currently). Seals, logos, and the school's own usage should be treated per WP:OFFICIALNAME and the usual approach when a corporation or organization's preferred name or styling conflicts or aligns with usage elsewhere. —Myceteae🍄🟫 (talk) 20:41, 26 October 2026 (UTC)
School and their alumni get rather protective of their school's name. However this RfC, is more to just distinguish a given school when it shares the same name with another school. Issac I Navarro (talk) 20:46, 26 October 2026 (UTC)
Indeed. Most of these considerations are beyond the scope of this RM and are covered by typical article titles conventions. —Myceteae🍄🟫 (talk) 21:11, 26 October 2026 (UTC)
I think colleges/universities are often different in this regard than elementary, middle and high schools, so that would make sense. They're often more associated with a larger area than just a city or even an entire state. Katzrockso (talk) 19:05, 14 October 2026 (UTC)
The scope of the RFC question is intentionally limited to primary and secondary schools—which is not to say we shouldn't discuss related cases and the extent to which they are or are not similar. I agree with @Katzrockso. Primary and secondary schools are local, often hyperlocal, institutions. Of course it's true that some students attend school in neighboring communities. College and universities have important similarities but I find the justification for a state or even national designation stronger there, depending on the institution. —Myceteae🍄🟫 (talk) 22:17, 14 October 2026 (UTC)
No with caveats Pretty much all the comments above sum up what I would have to say besides the fact that I think it might be possible with a particularly large city. A city like Baltimore could possibly be as good of a disambiguator as say Idaho or Nebraska. Possibly the 30 cities listed by the AP stylebook could be given an exception. ✶Quxyz✶ (talk) 23:53, 14 October 2026 (UTC)
No Not necessary unless there are two (or more schools) with the same name. --Enos733 (talk) 17:55, 15 October 2026 (UTC)
Yes the question asks if the city should be included when using geographic disambiguation. If the school's name is unique (unambiguous) then there would be not need. —Myceteae🍄🟫 (talk) 21:48, 15 October 2026 (UTC)
No, except for WP:MAJOR cities. WhatamIdoing's proposal here is the most workable solution I've seen, and it happens to match what is apparently the most common practice for higher education institutions in the US, as I've argued here. I'm happy to go with this and consider the more "localized" style to be more appropriate for single individual buildings, structures, etc., which schools often are not. There seems to be an aversion to disambiguation terms that diverge from the article titles for cities by shortening them to the "base name" of the city, minus the state. WhatamIdoing's proposal avoids ever doing that; instead, it achieves concision by having the state as the disambiguator, or because the article titles for WP:MAJOR cities are already concise, and sacrifices concision only if naming the non-"major" city is unavoidable. Ham II (talk) 07:56, 17 October 2026 (UTC)
No Having made thousands of edits to school articles and having done extensive research on the data from the National Center for Education Statistics, the overwhelming majority of such schools -- well more than 90-95% -- need no disambiguation at all, and forcing the addition of city and state means that the vast majority of readers will have to wade through multiple pages to find the article they're looking for. Sure, there will be an example of a Central High School or a Memorial High School, where there is occasionally a need for disambiguation, but even within those it's the exception, as most of the articles have a full name that disambiguates the Central / Memorial, as needed. Per Wikipedia:Disambiguation, we should be using city and state as disambiguators where it's needed, not for every single article for every single primary and secondary school. Alansohn (talk) 21:08, 18 October 2026 (UTC)
The question was posed in the context of "when using geographic disambiguation". It does not say that a geographic location identifier needs to be used all the time. It's only about ambiguous cases. — BarrelProof (talk) 22:56, 18 October 2026 (UTC)
Again, no. We should always be using the minimum disambiguation needed. Why use "(city, state)" when "(state)" is sufficient. Alansohn (talk) 01:57, 19 October 2026 (UTC)
Sorry for previously misunderstanding your comment. Now I see what you meant. — BarrelProof (talk) 03:32, 19 October 2026 (UTC)
No, except for WP:MAJOR cities. I think User:Very Polite Person (VPP) is correct. We should be boring and procedural. Country subdivisions are a form of taxonomy. And taxonomic rank is the boring and procedural way of distinguishing between similar things. And it tells us to start at the most specific rank when determining where two things differ. That would be the city/town/village level. However, as WhatamIdoing pointed out, we run into the problem that we can't actually disambiguate by "city" in most cases without being ambiguous and contradicting the title of the corresponding article for the place the school is located in. Forrest School (Chapel Hill, Tennessee) would be Forrest School (Chapel Hill), which sounds like it's in North Carolina because no one knows Chapel Hill, Tennessee. That town's article is not titled Chapel Hill. But neither is Chapel Hill, North Carolina. Whereas White County High School (Cleveland, Georgia) would be titled White County High School (Cleveland) which sounds like it's in the Ohio city of Cleveland, which is where that city's article is located. But if we conform to corresponding town article titles, we get Town High School (Town, State), which is not WP:CONCISE because it provides more detail than is necessary in cases where no other same-named schools exist in the state. Οἶδα (talk) 05:04, 19 October 2026 (UTC)
Question 2 responses
If yes (to Question 1), should the state also be included by default, or only under certain circumstances? If the state is not always included, when should it be?
I don't have strong feelings about whether to always include the state or to take a different approach based on primary topic, WP:MAJOR city designation, or the need for more complete disambiguation. —Myceteae🍄🟫 (talk) 01:05, 13 October 2026 (UTC) Will update my response below —Myceteae🍄🟫 (talk) 19:26, 20 October 2026 (UTC)
I think:
If it's a WP:MAJOR city, then we should use the major city (unless that's not sufficient): Wikipedia High School (Chicago) but never Wikipedia High School (Chestnut) for a school in Chestnut, Illinois, with its total population of just 220.
If it isn't a WP:MAJOR city, then we should use the state (unless that's not sufficient): Wikipedia High School (Illinois).
Only if it isn't a WP:MAJOR city and we need further disambiguation because there's more than one school with the same name in the same state should we use both the city and the state: Wikipedia High School (Chestnut, Illinois). WhatamIdoing (talk) 01:20, 13 October 2026 (UTC)
The list of small towns whose kids have to go to the neighboring town for high school is much larger. If you know your friend lives in Smallville, State you don't know whether the high school will be "Wikipedia High School (Smallville)" or "Wikipedia High School (Neighborton)". You'd still be able to find it if the article were titled "Wikipedia High School (State)", though. WhatamIdoing (talk) 01:34, 13 October 2026 (UTC)
I know you don't think we should care about consistency between countries, but I'm curious why you think the global recognizability of towns and cities should be a determining factor in the US but not elsewhere. Yorkshire and New South Wales are more recognizable than many of the tiny villages and hamlets within them. —Myceteae🍄🟫 (talk) 01:43, 13 October 2026 (UTC)
Because readership is likely to be within a single country (e.g., I want to know about my friend's kid's school), I think that we should do what makes sense within that country. This RFC asks about US schools, so my answers are oriented towards US schools. That said, if "St Wilfrid's Secondary School, Yorkshire" works for UK folks than "St Wilfrid's Secondary School, Skeffling", then I'd certainly prefer it. WhatamIdoing (talk) 18:04, 13 October 2026 (UTC)
Not in the case of Washington, as Washington is the state and Washington, D.C. is the capital. In the case of Georgia – are you aware of any schools in the US state of Georgia that have the same name as a school in the non-English-speaking country of Georgia? I'm not, and I think it's unlikely to be a problem. Therefore I consider that hypothetical conflict to be irrelevant. WhatamIdoing (talk) 18:07, 13 October 2026 (UTC)
I would have thought '(Washington)' always meant the state and was therefore to learn of Portrait of a Young Man (Botticelli, Washington) but maybe this is a different matter. I agree the Georgia situation will occur rarely. Just trying to understand not only what people are recommending but why. If we only care about people in-country and not globally, that's helpful to confirm. This did sort of come up in consideration of some of the Marist School titles. The schools are found all over the world, including in countries where English is not the primary language of instruction or everyday life. There's not one in Georgia so in actuality confusion is unlikely. —Myceteae🍄🟫 (talk) 18:38, 13 October 2026 (UTC)
In short, no. I've thought about that and honestly it seems like in most cases the title provides enough context that using a state even in those instances is sufficient. Again it's about distinguishing titles of the same name, not necessarily providing precise locations. For readers and editors looking for the article, these titles are either going to appear on search results with other high schools (and include the short description which also includes the city) or on a DAB page where the city is usually included.
Secondary schools in the country of Georgia don't use the "Name High School" format that North American schools do, so there aren't any overlaps with schools in the US state of Georgia or anywhere in the US that I'm aware of.
"Washington, DC" is the common name for the city and is already consistently used to disambiguate schools in the city. There doesn't seem to be any confusion about using "(Washington)" for schools in the state of Washington.
Schools in the city of New York seem to consistently use "New York City" and some use just the borough ("Queens" or "Bronx") to disambiguate. Like Washington, there doesn't appear to be any confusion using "(New York)" on other school articles. While we could try to be more consistent and only use "New York City" or add the state to the borough ("Queens, New York") for schools in NYC, it seems more like a case of "if it isn't broken, don't fix it" as there are only a handful of schools that use the borough, plus even the articles on each borough don't use the "city, state" or even "neighborhood, city" format.
I think that anyone concerned about confusion about using "(Washington)" for schools in the state of Washington should consider changing it "(Washington state)". "(Georgetown, Washington)" doesn't really help, as we have both Georgetown (Washington, D.C.) and Georgetown (Washington state). WhatamIdoing (talk) 18:19, 13 October 2026 (UTC)
It seems that it may be a special case. Thus, a specific rule just for that state may be useful, depending on the consensus on Question 1. Issac I Navarro (talk) 18:23, 13 October 2026 (UTC)
I think that anyone concerned about confusion about using "(Washington)" for schools in the state of Washington should consider changing it "(Washington state)" … or '(City, State)'! —Myceteae🍄🟫 (talk) 18:53, 13 October 2026 (UTC)
Yes. Anecdotally, in my cartography class, I teach that if you are going to show a local area (town, school, etc.), include enough context in the title so an international audience can locate it on a map. I believe this is the same situation. I would frame it as city & region so we can include schools in areas without States. For example, a school in a country with provinces would be consistent with the ones in the US. GeogSage (⚔Chat?⚔) 04:54, 13 October 2026 (UTC)
Yes, include it (except for certain large cities). Use exactly the place name used for the category for the place. - Jmabel|Talk 06:50, 13 October 2026 (UTC)
No. Not necessary unless needed for disambiguation purposes. -- Necrothesp (talk) 09:28, 13 October 2026 (UTC)
This seems to be the normal rule for most other building to include the state even when not needed but for WP:MAJOR cities then no unless still ambiguous. Crouch, Swale (talk) 11:09, 13 October 2026 (UTC)
@Very Polite Person, could you explain what you mean about Taxonomic rank? Are you recommending that since we normally write E. coli, we should always dab pages as (City, State)? WhatamIdoing (talk) 18:26, 13 October 2026 (UTC)
Not per se, just that there's no reason we can't do somethig simple and uniform akin to that for our URLs and page titles. Decide on what, how to implement, and then we can and should lock in something that can scale... as far as we need to. If some day we have Central High School (New San Diego, Moon) or whatever else, a format that anything can easily just plug into. — VPP (t/c) 22:15, 13 October 2026 (UTC)
The question here is "should the state also be included by default, or only under certain circumstances?"
No Only when disambiguation is needed, not as a default. Keep the disambiguation as short as necessary. Timrollpickering (talk) 12:52, 13 October 2026 (UTC)
No, unless necessary to distinguish from other similarly named schools in similarly named cities/towns. older ≠ wiser 17:15, 13 October 2026 (UTC)
I voted no for Q1, but if it passes anyway, then I vote yes for this one except in the case of WP:MAJOR cities. Shocksingularity (talk) 20:51, 13 October 2026 (UTC)
Weak yes. We should generally follow the convention at WP:USPLACE.Katzrockso (talk) 01:25, 14 October 2026 (UTC)
Yes with the exception of those in the AP styleguide allowed to be mentioned without states. ✶Quxyz✶ (talk) 23:54, 14 October 2026 (UTC)
No I still say no. In most cases, based on the data I've seen, the name is unique across states. We should be as concise as possible, and if the state adds sufficient disambiguation, then why should we add city? Sure, there are cases where the same school name exists within the same state, and that's where (city, state) should be used; otherwise (state) is sufficient. Alansohn (talk) 21:32, 18 October 2026 (UTC)
Yes, except for WP:MAJOR cities. And only the state name, unless two schools with the name exist in the same state, as laid out in WhatamIdoing's proposal above. Οἶδα (talk) 05:17, 19 October 2026 (UTC)
Yes, the city and state should both be included by default when geographic disambiguation is already necessary, with a WP:MAJOR cities exception. This approach best balances the various article title considerations:
It reduces astonishment in cases like Paris, Texas and London, Ontario (if the approach is to be extended to Canada).
It properly situates these local, often hyperlocal, institutions.
It provides a clear and WP:CONSISTENT framework that will reduce variability among US schools titles.
It addresses WP:NATURALNESS and WP:Recognizability for locals, who are the readers most likely to be familiar with the school, and for the global readership.
It achieves greater WP:CONSISTENCY with schools outside the US, which almost always use the city, while incorporating local conventions as described at WP:USPLACE.
It addresses some of the potential ambiguity with Georgia, New York, and Washington (however minor these concerns may be).
The tradeoff is over-precision/loss of concision for some articles. The Article titles policy allows for this when balancing other considerations and following subject-specific naming conventions.
Should we develop a naming convention covering all school articles?
As I am to draft up WP:NC(S) with the ideas from others at WT:WPSCH/AG, I think it could be helpful to point to when closing RMs. Issac I Navarro (talk) 01:11, 13 October 2026 (UTC)
Yes. Per my comment above. GeogSage (⚔Chat?⚔) 04:55, 13 October 2026 (UTC)
To anyone saying yes, here. If that page was to be developed, I would love some feedback on that page's talk. I think that page could greatly benefit from others' points of view. Issac I Navarro (talk) 05:14, 13 October 2026 (UTC)
Yes, folks may want to take look at the very rough draft proposal at WP:NC(S). It's somewhere between the brainstorming and draft proposal stage described at WP:PROPOSAL. It is mostly compiled from past failed proposals listed at Wikipedia:Schools §Article titles. It does not reflect any clear consensus. @Issac I Navarro has done a nice job pulling it together and cleaning up some portions. Per WP:MULTI, and for everyone's sanity, let's not start a parallel discussion about US schools or anything else within the scope of this RFC on the draft proposal's talk page—or anywhere else. —Myceteae🍄🟫 (talk) 05:32, 13 October 2026 (UTC)
No harm in trying. Not so sure it will work well for all countries, but we can at least develop standards for many countries. - Jmabel|Talk 06:51, 13 October 2026 (UTC)
Probably not necessary. Comma disambiguation needs to be used for all Commonwealth countries (except Canada) incidentally, which includes Australia, as is standard. -- Necrothesp (talk) 09:28, 13 October 2026 (UTC)
Yes although it might be better as part of a wide guideline for buildings etc although in America as least it seems that we often treat school as being organizations rather than buildings which I (in England) would normally consider them. Crouch, Swale (talk) 11:09, 13 October 2026 (UTC)
Possibly, for US only; absolutely not for a global attempt. Since I'm not in the US, I won't comment further on US schools. Johnbod (talk) 12:06, 13 October 2026 (UTC)
Yes but make clear it does not cover higher education even if a few countries call universities "schools". And all disambiguation should be brackets, not comma, to avoid giving the misleading impression the full article title is the institution's full name, regardless of country. Timrollpickering (talk) 12:53, 13 October 2026 (UTC)
No. Possibly ones per country will make sense, but there is too much variety in how the world organises its education system, how it names its educational institutions and how best to disambiguate places (e.g. "City, State" doesn't work for the majority of the world) for a single system to be practical. I'm also not convinced such a system would be desirable even if it was practical. Thryduulf (talk) 13:43, 13 October 2026 (UTC)
These are important concerns that would need to be addressed, and you may be right that it's too difficult to be helpful. A single guideline ≠ A single system. We have existing naming conventions like WP:PLACE, WP:NCEVENTS, and WP:NCSTATION that provide a general approach for the category and varying levels of region- or subtype-specific guidance. A guideline for schools might look similar. —Myceteae🍄🟫 (talk) 15:45, 13 October 2026 (UTC)
No. While it sounds nice, as long as articles are following the general rules and guidelines for titles and disambguation, which allows for multiple formats, I don't think we need a strict uniform format for all schools. As others have said, how we name schools and places differs, so it would be impractical, and I seriously doubt any consensus could even be reached. --JonRidinger (talk) 15:50, 13 October 2026 (UTC)
The general rules and guidelines for titles and disambiguation don't yet provide a clear answer to the problem at hand, which is how to disambiguate entities (other than populated places) by location in the United States. A naming conventions page doesn't mean a strict uniform format for all schools; the page can indicate what Myceteae has called varying levels of region- or subtype-specific guidance. Ham II (talk) 16:10, 13 October 2026 (UTC)
Meh, leaning towards No. Considering that many agree that the naming conventions for settlements needs to be changed, there has been no consensus about how to change it. Seems even less likely that any single convention would be applicable for schools (or other institutions) world-wide (and I suspect having a set of multiple conventions would likely create more confusion). older ≠ wiser 17:21, 13 October 2026 (UTC)
Yes, preferably as Wikipedia:Naming conventions (educational institutions) given that the convention I support (above) for US schools is also applicable to US colleges and universities, but Wikipedia:Naming conventions (schools) would have much the same effect as the US higher education naming convention seems mostly to have fallen into place already. NB also that there are differing interpretations of "school", although that doesn't necessarily rule out Wikipedia:Naming conventions (schools) as a title if the scope is clarified in the text. Ham II (talk) 08:40, 17 October 2026 (UTC)
NoWP:COMMONNAME does a fantastic job of giving us guidance on names, with disambiguation added when (and only when) needed. Alansohn (talk) 21:34, 18 October 2026 (UTC)
A wider guideline? Yes. A school-specific guideline? No. Taxonomic rank combined with existing WP:PLACENAME guidances should result in smooth application. But this should not disrupt WP:COMMONNAME in any way. But it's basic placename taxonomy, so it goes beyond the disambiguation of school articles... which is the next question. Οἶδα (talk) 05:30, 19 October 2026 (UTC)
Question 4 responses
Should we develop a naming convention that covers schools, museums, churches, libraries, and similar institutions and buildings?
Yes. Ideally, something like: institution name, city, region/state/province. GeogSage (⚔Chat?⚔) 04:56, 13 October 2026 (UTC)
I don't have any strong opinions on this one. Possibly, as since we are doing schools we could better check all similar type buildings and build off off of the consensus reached here. Issac I Navarro (talk) 05:05, 13 October 2026 (UTC)
Ambitious. Worth a try. If you do, consider that for many of these things you need to account for:
Sometimes a building and an institution should be "lumped," especially if the institution has always been associated with a single building or a series of buildings on a single site. However, this is not a given: museums, in particular, often move and often occupy buildings that are notable independent of the museum. Library systems often exist independent of particular library buildings. If universities are to be included, it gets even more complicated: the University of Washington, for example, has at least five present-day campuses, a former campus in Downtown Seattle, and numerous buildings elsewhere, including (for example) marine-oriented facilities in Friday Harbor, Washington. - Jmabel|Talk 06:58, 13 October 2026 (UTC)
Much to consider. If a more comprehensive guideline is developed, it would presumably default to WP:COMMONAME, WP:PRIMARYTOPIC for the common name, and other broad considerations in many cases. So the likes of University of Washington, Holworthy Hall, and Cincinnati and Hamilton County Public Library would not need to be changed. I don't want to digress too much into what exactly such a naming convention might say but it would be critical to define its scope. Another critical question would be whether the disambiguation considerations and outcomes should be the same for each type and, if not, what special rules or factors could be described for, say, libraries as distinct from high schools. —Myceteae🍄🟫 (talk) 07:19, 13 October 2026 (UTC)
I agree with Jmabel, point, that seems to make the most senes. Issac I Navarro (talk) 00:57, 14 October 2026 (UTC)
Probably not necessary. See above. -- Necrothesp (talk) 09:28, 13 October 2026 (UTC)
Yes as I said above. Crouch, Swale (talk) 11:09, 13 October 2026 (UTC)
Probably not, for US only; absolutely not for a global attemptJohnbod (talk) 12:08, 13 October 2026 (UTC)
Johnbod, why would one country get special handling versus everyone else? — VPP (t/c) 12:32, 13 October 2026 (UTC)
To avoid yet more cultural imperialism by guess who. If other countries want their own standard, fine. But a standard devised by and for the US should not be imposed globally, as too often happens here. Johnbod (talk) 13:13, 13 October 2026 (UTC)
There's no reason region-specific guidance and considerations should not be included in such a guideline. —Myceteae🍄🟫 (talk) 15:55, 13 October 2026 (UTC)
Agreed. I don't believe any country on Earth would feel like we're imposing US standards if we use their specific regional terms. For example, China has a different system of administrative divisions, and none are called "States," but are employed in a similar way to describe places in China. Each country has their own way of doing things, and we can respect that while still having some standard that is roughly consistent globally. GeogSage (⚔Chat?⚔) 03:54, 14 October 2026 (UTC)
As pointed out in the Article Advice Talk, UK schools use commas instead of parentheses. Issac I Navarro (talk) 04:01, 14 October 2026 (UTC)
The point is less what symbol goes where in the title as opposed to what level of place goes where in the title. — VPP (t/c) 06:24, 14 October 2026 (UTC)
To be clear what I mean is that anyone should be fine with if one country's norm is (this, then) vs this, then. THe point is the this and the then, not the other errata. — VPP (t/c) 06:25, 14 October 2026 (UTC)
This seems like an obvious yes.. I mean... this is all a solved problem: Taxonomic rank. — VPP (t/c) 12:32, 13 October 2026 (UTC)
I don't see a fundamental Wikipedia article titling difference between a school and a museum, church, library, or other institution or building. They fundamentally involve the same issues. — BarrelProof (talk) 12:57, 13 October 2026 (UTC)
No, per my answer to question 3 but this one has even more variables. Thryduulf (talk) 13:44, 13 October 2026 (UTC)
I've long intended to rework WP:CHURCH into a more fully developed Wikipedia:Naming conventions (church buildings). That would necessarily have different guidance for different parts of the world, as much of it would be about when to use English and when to use other languages. For the United States, article titles with disambiguation would follow the pattern "St. Foo's Church (Placename)" (which is the status quo). I don't think there'd be any circumstances in which "Placename" would be a US state. Whether "Placename" should be, e.g., "Chestnut, Illinois", or just "Chestnut", is another matter; see my comment below. Ham II (talk) 14:31, 13 October 2026 (UTC)
@Ham II, after consensus, if you would like, send me a ping. Maybe we can work/build off the school naming convention.Issac I Navarro (talk) 15:59, 13 October 2026 (UTC)
Aha, I wasn't aware of WP:CHURCH. This says to use the name of the settlement or administrative division in which the building is located and to use commas instead of brackets (parentheses). A quick look at Category:Churches in Chicago and Category:Churches in Nashville, Tennessee shows that we do use parentheses, use city only for the WP:MAJOR city Chicago, and we use a mixed approach for the 'kind-of-major' city Nashville. We do not use state alone, at least not in this small sample. —Myceteae🍄🟫 (talk) 16:31, 13 October 2026 (UTC)
Parenthetical disambiguation is the norm for articles on churches in North America, and WP:CHURCH not reflecting this is one reason I want to revise it. I think it's had very little attention and not much would be achieved by mass-messaging the relevant WikiProject(s). Ham II (talk) 16:54, 13 October 2026 (UTC)
Same as #3: Meh, leaning towards No. Considering that many agree that the naming conventions for settlements needs to be changed, there has been no consensus about how to change it. Seems even less likely that any single convention would be applicable for schools (or other institutions) world-wide (and I suspect having a set of multiple conventions would likely create more confusion). older ≠ wiser 17:23, 13 October 2026 (UTC)
No, see my answer on question 3. Most of these are already disambiguated with place names so an official guideline isn’t that useful. Shocksingularity (talk) 20:57, 13 October 2026 (UTC)
No, this is overstepping it. Proper names exist, we don't need to open up the doors even more. PARAKANYAA (talk) 00:55, 14 October 2026 (UTC)
No Sure, there are cases at WP:RM dealing with contested names coming up. But to imagine that we're going to develop and then impose an overall naming convention that is goung to cover all "schools, museums, churches, libraries, and similar institutions and buildings" is biting off far more than we can chew and will only be likely to create far, far more problems than could possibly be resolved. Alansohn (talk) 21:46, 18 October 2026 (UTC)
Yes, a basic guideline for disambiguation by placename. But not anything wider than that, and certainly not anything that steps on WP:COMMONNAME. As BarrelProof wrote, there isn't a fundamental difference between these institutions and what we must consider when disambiguating them. And as VPP wrote above, the point is less what symbol goes where in the title as opposed to what level of place goes where in the title. So it needn't be parenthetical disambiguation. Οἶδα (talk) 05:42, 19 October 2026 (UTC)
If I've understood your other posts correctly this guideline would start from the state and work down. First United Methodist Church (Laurel, Maryland) and First United Methodist Church (Nebraska City, Nebraska) are apparently the only churches of those names in those states with articles. Should they therefore have the article titles First United Methodist Church (Maryland) and First United Methodist Church (Nebraska)? Or would that be the point at which we're stepping on WP:COMMONNAME, as you put it? I think that disambiguation by US state would work for schools (and already does for colleges) but wouldn't for churches, and I would work from the assumption that the more "localized" style (localized to, e.g., a city, and using the format "City, State" for any non-WP:MAJOR city) would be best for any institutions/buildings other than schools, colleges and universities. Ham II (talk) 07:25, 19 October 2026 (UTC)
this guideline would start from the state and work down
And by "stepping on WP:COMMONNAME" I'm simply referring to a naming convention that somehow implies topics that do not require disambiguation should apply such disambiguation, instead of simply using the unambiguous expression WP:COMMONNAME tells us to use.
Is your suggestion that disambiguation (when used) always matches the name of the city article, or rather that we use the city for schools everywhere except the US? Or cities for England, states for the US, and perhaps separate rules for every other country? For schools located in cities in England where the city article requires disambiguation, would you then use 'School Name, City, County'? For example, should Queen Elizabeth Grammar School, Penrith be moved to Queen Elizabeth Grammar School, Penrith, Cumbria to match the title of the article Penrith, Cumbria?
What is the fundamental difference between these institutions that we must consider when approaching disambiguation by placename? I have the same question. Schools and churches are both local institutions, though they may serve members of neighboring communities. —Myceteae🍄🟫 (talk) 19:03, 19 October 2026 (UTC)
Only if there is more than one Queen Elizabeth Grammar School in Cumbria, which there does not appear to be. Applying the previous logic, Queen Elizabeth Grammar School, Cumbria would be my choice. Of course you could argue that because no other place named Penrith has a "Queen Elizabeth Grammar School" that Penrith alone is sufficient. That would be similar to how two television shows can have the same name--like Shameless (American TV series) and Shameless (British TV series)- but we don't disambiguate the episode titles with anything other (Shameless) because there isn't ambiguity between both shows' episode titles. Maybe I'm wrong, but I feel placenames are a different beast. If the wider community hasn't even agreed that a place is the primary topic for its name, meaning we consider it insufficiently distinctive to title its own article without qualification, I feel like we would be treating it as if it were if we departed from the established article title in our disambiguation. The fact that most placenames are not identifiable by their unqualified name alone + the fact that there are placenames that share the names of primary topic cities renders that distinction necessary in my view, even when there is no known ambiguity between shared placenames. I would say article titles should be understandable and appropriately disambiguated without relying on readers' knowledge of every possible place name. Do we really think St. Peter's Cathedral Basilica (London, Ontario) should be named St. Peter's Cathedral Basilica (London)? How about Zion Church (Rome, New York)? Should it be Zion Church (Rome)? I now realise that existing practice is inconsistent, as stated in the OP here, but I have always perceived disambiguation by placename as being downstream of the place's article title. Οἶδα (talk) 05:27, 20 October 2026 (UTC)
From, what I have seen, it seems other countries use a comma, while the US uses brackets. Issac I Navarro (talk) 05:34, 20 October 2026 (UTC)
I am aware. I wasn't making any point related to that. I did say above that such a guideline wouldn't be dependent on parenthetical disambiguation. Οἶδα (talk) 05:47, 20 October 2026 (UTC)
Thanks you, this is clarifying.
I would say article titles should be understandable and appropriately disambiguated without relying on readers' knowledge of every possible place name.
I tend to agree though there is tension between various editors' preference for and application of concision, precision, consistency, and other principles. Article titles should be recognizable to someone familiar with the topic. For local schools, the city is a basic piece of information and would cover this. Strictly speaking, the title doesn't need to make sense to or define the topic for readers unfamiliar with the school, but in practice we often include identifiers or descriptors beyond the absolute minimum that is required for disambiguation, in the name of both consistency and serving a global audience. —Myceteae🍄🟫 (talk) 18:57, 20 October 2026 (UTC)
That is interesting. If the consensus is that local institutions are foremost defined geographically by the city/town/village/etc they are in, then I suppose the argument becomes that (State) can sufficiently distinguish the topic but not appropriately define it for recognizability. I would tweak my opinion to account for that consensus, assuming it is reached. I would concur that a museum in the Chicago metro area is probably defined more by its locale than it is as an institution of Illinois. Or a high school in Western Mass by its town. I still wouldn't ever depart from established article names and get First United Methodist Church (Laurel), which vaguely suggests to me it has something to do with plants. Or Spring Hill Farm (Lebanon, New Hampshire) becoming Spring Hill Farm (Lebanon), which sounds like it is located in a certain Near East country. Οἶδα (talk) 03:40, 21 October 2026 (UTC)
On US schools, colleges and universities, I think the latter two are already most often disambiguated by state. Reading over the arguments again, I'm starting to waver somewhat in my support for doing the same for schools. But I was thinking of a distinction between institutions occupying multiple buildings with potentially sprawling or little-known catchment areas only recognizable from the state, versus individual buildings. One thinks of a building as being in a specific settlement; something further up in the taxonomy reduces WP:NATURALNESS and WP:RECOGNIZABILITY. One especially thinks of a cathedral (since you mention one) as being in a city. (That article's lede suggests it could be given a more concise base name, "St. Mary's Cathedral", which would make the length of the disambiguator less of an issue.) A settlement or populated place rather than anything larger is usually the best starting-off point for disambiguation of a building. Ham II (talk) 20:12, 19 October 2026 (UTC)
That sounds good, since only as much detail as is necessary to distinguish one topic from another should be used. But I'm not sure how we can simultaneously say via WP:PRECISION that exceptions exist because of how we factor other WP:CRITERIA into the equation and that as such Bothell, Washington is more natural and recognizable than Bothell. Why should we disregard those same conclusions of naturalness and recognizability when deciding how much geographic detail to include in a disambiguator? I wouldn't feel comfortable disregarding what has already been worked out (sometimes ad nauseam) at the main article. Why would First Church of Christ, Scientist (Paris) be more natural or recognizable than First Church of Christ, Scientist (Paris, Texas)? And why would the latter be more concise than First Church of Christ, Scientist (Texas) in defining the topic? Speaking for the articles that exist on Wikipedia, of course. Οἶδα (talk) 06:16, 20 October 2026 (UTC)
I agree with most of your reasoning but reach a different conclusion, which is that routine usage of '(City, State)' for geographic disambiguation of schools, churches, etc. in the United States is the best balance of the considerations, with a WP:MAJOR cities exception. —Myceteae🍄🟫 (talk) 19:24, 20 October 2026 (UTC)
Anecdotally, I have a Smallville High School (Smallville, Mystate) in my area that has only one doppelganger in the whole US. I checked Google Trends and it does appear people are searching the full "Smallville High School Smallville Mystate" just as frequently as "Smallville High School Mystate". Οἶδα (talk) 01:33, 21 October 2026 (UTC)
I could get behind an exception for cases like Smallville High School (State) where the name of city is reflected in the name of the school. —Myceteae🍄🟫 (talk) 13:27, 21 October 2026 (UTC)
To me the biggest difference between a school and a church is that it's actually far less common to have a high school name repeated in a given state vs. a church. That doesn't mean it's rare, but the vast majority of high school names aren't repeated within a state, so it's perfectly reasonable to see the list of identical names and separate them as "the one in Ohio, the one in Nebraska, and the one in Indiana" and then use the city in the exceptions to that. Churches, on the other hand, quite often have names that are quite ambiguous, such as "First United Methodist", so there will never really be a primary topic for "First United Methodist Church". Obviously not every church is notable (most aren't), but it's going to be far more common to have repeated names within a state, so the city may already be necessary or it could soon become necessary. And that's just for the ones with articles. Never mind that a web search for "First United Methodist Church" in a given state will probably list dozens of churches with that name. The same is true for NRHP listings like a "Masonic Temple" or "Franklin Hotel". So yes, that's why it seems natural to default to the "city, state" on things like churches. In most cases it already is.
For high schools, though, the state alone accomplishes the direct goal of distinguishing the topics with as little words as possible in most cases since quite a few are found only once in a given state. I see no evidence or general policy to indicate that including "city, state" in all instances of disambiguation will be more beneficial especially since quite a few high school articles don't need disambiguation at all and many high schools are not in a given city that they may have a mailing address for. Do we really think that if someone looks for "Myname High School" or "Myname High School in myname, homestate" that they won't know that "Myname High School (Homestate)" is the one they're looking for, especially since the short description will say "Public high school in Myname, Homestate" and the disambiguation page will also specify the town? I'm still not seeing the drawback to using a shorter title. -- JonRidinger (talk) 22:45, 21 October 2026 (UTC)
I tried to spell out my overall reasoning concisely but completely here. At the end of the day, I see several plausible, defensible approaches. If existing policy and practice made the optimal approach clear, we wouldn't be here. Obviously, if people know which city a school is in, I expect that they will most often know the state. I don't think using the state alone is wrong or likely to confuse, but including the city is better. I do see how other editors reach a different conclusion and it's been helpful to understand the reasoning and its application to different use cases, whether or not I agree. —Myceteae🍄🟫 (talk) 23:27, 21 October 2026 (UTC)
We don't disambiguate based on non-existent topics on Wikipedia, though it does appear to be common practice with regard to high school articles (sift through Category:Educational institution disambiguation pages). But it does seem a bit confusing to rename First United Methodist Church (Laurel, Maryland) as First United Methodist Church (Maryland) when there is at least one other church by that name in the state and it appears to be just as notable and/or searched for as a topic (but has no Wiki article). Whereas, as you state, most high schools in a given state do not share the same name. Οἶδα (talk) 04:09, 22 October 2026 (UTC)
Right, something technically doesn't need any disambiguation, or a specific level of disambiguation, if now competing article happens to exist at the moment. But editors might reasonably conclude that since "First Lutheran", "First United Methodist", and the like are so common, adding the extra detail is a helpful thing to do. Not to beat a dead horse but I think just treating these all as local institutions and naming these as such is sensible regardless. —Myceteae🍄🟫 (talk) 21:40, 26 October 2026 (UTC)
I think colleges and universities with sprawling campuses and satellite locations are a different matter (also touched on elsewhere in this discussion). This situation is far less common with grammar schools and high schools. And colleges and universities, which more often have significant state, national, even international prominence, may warrant distinct treatment overall. Many, probably the large majority, will have a unique common name like University of Washington that doesn't require disambiguation. The article properly covers the parent institution and main campus, with separate articles on Campus of the University of Washington (covering the main campus), University of Washington Bothell, and University of Washington Tacoma. —Myceteae🍄🟫 (talk) 19:19, 20 October 2026 (UTC)
Discussion (Geographic disambiguation)
I'm not sure at this time if we need a comprehensive naming convention for schools or for other, similar institutions. It is sensible to me that these would all follow similar principles. However, the major sticking point at RM, and the major point of variation across the project, is primary and (mostly) secondary schools in the US. —Myceteae🍄🟫 (talk) 01:06, 13 October 2026 (UTC)
Clarification/scope: The intent is to create a standard approach that will usually be used when disambiguation is needed, i.e., when two or more schools share the same name. As with other guidelines/naming conventions, this would not be required when the school has a unique WP:COMMONNAME that doesn't require disambiguation or when it is determined at RM that weighing other article title considerations occasionally warrant a different approach in a particular case. —Myceteae🍄🟫 (talk) 01:17, 13 October 2026 (UTC)
Isn’t all of this already covered by WP:USPLACES? That guideline tells us to include both town and state names except for a few designated large cities. Blueboar (talk) 12:42, 13 October 2026 (UTC)
I asked above, but why would the USA get it's own carve out on anything ever, or any other country? — VPP (t/c) 12:57, 13 October 2026 (UTC)
I’m not going to repeat all the reasons why WP:USPLACES says what it does. We have had multiple discussions about it, and we have repeatedly confirmed that it has consensus.
(edit conflict) It's basically a matter of MOS:TIES and WP:ENGVAR. The US has a large number of people who speak and read English, and it has somewhat different writing customs than other places. It would be rather odd to say that someone "went to Cleveland, United States", for example. — BarrelProof (talk) 13:38, 13 October 2026 (UTC)
My question is why it wouldn’t apply to these school disambiguations. Blueboar (talk) 13:28, 13 October 2026 (UTC)
Well, for one, it could often be a bit cumbersome– including extra state identifiers where they are not a natural part of the way people write. Also, it's not clear what kind of location identification is desirable for an institution that is located in Neighborhoodplace, Smallville, Cucumber County, SomestatethatshopefullynotGeorgiaorWashingtonorNewYork, when the institution is in the Bigcity metropolitan area. — BarrelProof (talk) 13:49, 13 October 2026 (UTC)
This seems to boil down to a disagreement over whether, e.g., Chestnut, Illinois, should be treated as a place name plus disambiguation or as a place name unto itself. If it's a place name unto itself, one can simply follow the article title for the place when disambiguating something that's located there. If it's a place name plus disambiguation, following the place's article title means there is arguably one disambiguator too many, so there is then a question of whether to disambiguate by city/town/etc. or by state.
As comma-separated disambiguation seems to be restricted to articles on populated places when it comes to American topics, with disambiguation otherwise being parenthetical for those topics, this probably encourages the view that an article title like "Wikipedia High School (Chestnut, Illinois)" doesn't contain "double disambiguation" (a term that's being used in this brand-new RM started today). Ham II (talk) 14:06, 13 October 2026 (UTC)
It’s not one or the other… it’s BOTH. Because sooo many towns in the US require disambiguation, it has become standard practice in US sources to include the state name when referring to the town - even when the town name is unique. The exceptions are a few large cities… and these are spelled out in the guideline. Blueboar (talk) 15:58, 13 October 2026 (UTC)
@Blueboar, USPLACES is about how to title articles about cities, counties, etc. in the US. It doesn't say anything about whether a non-geographical thing should be disambiguated as Thing (City, State), Thing (City), or Thing (State).
This is a nice framing of the issue. We already have a standard for US places, and a mountain of other region-specific guidance, that essentially says ambiguity and concision are not the top priorities. We have other naming conventions like WP:NOYEAR and WP:TVSEASON that prioritize consistency and providing more identifying information in the title over selecting the shortest possible title. —Myceteae🍄🟫 (talk) 16:24, 13 October 2026 (UTC)
My question is why [WP:USPLACE]wouldn’t apply to these school disambiguations. It could. And this could be extended to other countries by saying that the general approach described at WP:PLACE is used for disambiguating schools, churches, museums, etc. It's a tradeoff between WP:CONSISTENCY and simplicity vs. WP:CONCISE. This would produce a fair number of article titles that are longer than absolutely necessary but the determination would more often be straightforward and less reliant on case-by-case assessments and the randomness of who happens to show up at RM. —Myceteae🍄🟫 (talk) 16:10, 13 October 2026 (UTC)
Perhaps the number of separate elements in a disambiguator should be limited to two; I wouldn't want Portrait of a Young Man (Botticelli, Washington) further extended to "Portrait of a Young Man (Botticelli, Washington, D.C.)", even though the article title for the city is Washington, D.C.Ham II (talk) 16:42, 13 October 2026 (UTC)
Hmm. See, I find the title of Portrait of a Young Man (Botticelli, Washington) rather surprising. At first glance I'd assume it refers to some place called Botticelli, Washington. Washington, D.C. is a special case that should probably be treated uniformly regardless of the approach used for other US cities. Puerto Rico, Guam, etc. may also warrant special treatment. —Myceteae🍄🟫 (talk) 17:24, 13 October 2026 (UTC)
The WP:CRITERION of Recognizability is that "The title is a name or description of the subject that would be recognized by someone familiar with, although not necessarily an expert in, the subject area." I think someone of that description would recognize that Botticelli is the name of the painting's artist. Ham II (talk) 17:42, 13 October 2026 (UTC)
I think so, too. But again we often use additional considerations and conventions to places. It's interesting to see what the actual practices are and how they are rationalized. —Myceteae🍄🟫 (talk) 18:40, 13 October 2026 (UTC)
I should clarify: I agree with the application of WP:Recognizability in a vacuum. But I also find Washington, D.C. better here even if not strictly necessary. Several other editors throughout this discussion have asserted that we always or usually write out Washington, D.C. for disambiguation. —Myceteae🍄🟫 (talk) 19:31, 13 October 2026 (UTC)
AFAIK, WP:USPLACES focuses on articles about populated places, not articles about institutions. It doesn't say what to do when a place name is part of some title about something else. — BarrelProof (talk) 13:17, 13 October 2026 (UTC)
I also suspect that people may not understand just how many articles are using "(Primarytopicville)" instead of "(Primarytopicville, Statename)" in disambiguation terms, and similar unqualified phrases in WP:NATURALly disambiguated article titles. I suspect the number is very large. One related RM was Talk:Herbert Hoover High School (Glendale)#Requested move 20 November 2023. — BarrelProof (talk) 22:17, 13 October 2026 (UTC)
That one was mentioned in the RM discussion. Someone had boldly moved it from just "(San Diego)" in 2020, and the same thing had happened for Fresno in 2011. San Diego is one of the WP:MAJOR cities. Fresno is not, but it's a Primarytopicville. — BarrelProof (talk) 00:27, 14 October 2026 (UTC)
After this is over, I hope many of us can organise, to clean things up. We may need to boldly move many pages in accordance with the consensus reached here. @BarrelProof, I would like your thoughts on this: Should we add a template, similar to those at Wikipedia:WikiProject Schools/Templates#Article maintenance templates, to the talk pages of articles we move saying that it was boldy done in accordance with the consensus reached here? And if you would like to request it being moved to a back or a different title use subst:Merge school? For a lack of better words, is this a dumb idea? Issac I Navarro (talk) 01:46, 14 October 2026 (UTC)
I wouldn't think we need a template. For a bold move, an edit summary that links to the declared consensus seems like it would suffice, and perhaps trying not to move too fast. The closer of the discussion may suggest an appropriate way forward. I'm more wondering whether we can expect to reach a clear consensus to do something. — BarrelProof (talk) 02:27, 14 October 2026 (UTC)
I would hope so, after this RfC. I am okay whatever the consensus is. Issac I Navarro (talk) 02:28, 14 October 2026 (UTC)
Yeah, the practice is common and also variable. For (Nashville, Tennessee) vs. (Nashville) it's 51 vs. 23 but for (Jacksonville, Florida) to (Jacksonville) it's 8 vs. 51. I'v not looked at all the talk pages for RMs but I wonder if one form or another just takes hold first for some cities and other articles follow suit. As I've mentioned elsewhere, I've also looked at quite a few neighborhood articles and RMs and the practice there is even more varied than for high schools. —Myceteae🍄🟫 (talk) 22:30, 13 October 2026 (UTC)
Some people even seem to believe we shouldn't disambiguate city identifiers even in cases where the city is not the primary topic for its name– e.g., see the ongoing discussion at Talk:Alhóndiga (Toledo)#Requested move 13 October 2026. — BarrelProof (talk) 15:40, 14 October 2026 (UTC)
Interesting tensions between concision, clarity, recognizability, and other principles. The arguments on both sides make sense and are defensible but I don't think there's an obvious right answer. Some view WP:CONCISE and WP:PRECISE as always favoring the shortest possible title. This can be persuasive but we often go the other way. —Myceteae🍄🟫 (talk) 16:27, 14 October 2026 (UTC)
I see it covers Museums, and that is in the scope of this RfC in question 4.
Courtesy ping:162 etc., I have yet, to see you in this RfC, and you may be interested. Issac I Navarro (talk) 16:33, 14 October 2026 (UTC)
As I said elsewhere in this discussion, I think schools aren't fundamentally different from other institutions, buildings, churches, etc. They all have the same issues. — BarrelProof (talk) 17:24, 14 October 2026 (UTC)
I agree on that point, hopefully, we can get some consensus on Question 4 responses: Should we develop a naming convention that covers schools, museums, churches, libraries, and similar institutions and buildings?Issac I Navarro (talk) 17:31, 14 October 2026 (UTC)
My perspective is that whatever consensus we can get would be helpful. Either way, consistency should be one of the main goals that comes out of this. Issac I Navarro (talk) 16:27, 13 October 2026 (UTC)
There are different ways to understand consistency. "Everything visibly the same" is consistent. "Everything using the shortest feasible name" is also consistent. "Everything uses the article title for the city" is also consistent. "Everything includes at least a state name, except for WP:MAJOR cities" is consistent, too. Which kind of consistency are you advocating for? WhatamIdoing (talk) 19:00, 13 October 2026 (UTC)
I don't have a strong preference for anything we use. There has already been four failed attempts to gain any consensus. And I don’t wish for this to be a fifth or a waste of anyones time for that matter.
I have the perspective of just having something to point to so we can stop having unproductive RM that go in either direction. I am okay with whatever the outcome is.
That being said, as I mentioned in Question 1, that I have a preference towards state. To have something akin to: Example High School (California) vs Example High School (Alabama). Then if we had two schools with exactly the same name in the same state, then we will use city: Example High School (made up1, California) vs Example High School (made up town2, California). Thus, not haveing unnecessary detail in their disambiguation terms. Trying to make the disambiguation aspect as brief and simple as possible. Additionally, for the US, there are only 50 states, having the additional benefit of being more uniformed. Issac I Navarro (talk) 19:32, 13 October 2026 (UTC)
Remind
Of course, to be clear, if a school is Exaaammmple Skooool High School with its own unique name, there would be no need to add any of the three options being discussed above: (city, state)/(state)/(city) Issac I Navarro (talk) 19:37, 13 October 2026 (UTC)
Yes, I think it goes without saying, but should be clarified in the RFC outcome and any written guideline, that first we look at general principles like WP:COMMONNAME and WP:PRIMARYTOPIC. These will often produce a suitable, unambiguous name and no further analysis is needed. When geographic disambiguation is needed, the question is which consistent approach we should follow. —Myceteae🍄🟫 (talk) 19:47, 13 October 2026 (UTC)
Yep, I only brought the unique name up, as it seemed some may have brought it up in Question 1. I am leaving this more as a note to the one that closes this RfC; to keep in mind, this is not to change those schools' titles.Issac I Navarro (talk) 19:56, 13 October 2026 (UTC)
I agree with Issac I Navarro: If the name is unique, nothing needs to be done. If it isn't and the two schools are in different states, then use "Example High School (California) vs Example High School (Alabama). Then if we had two schools with exactly the same name in the same state, then we will use city: Example High School (made up1, California) vs Example High School (made up town2, California)". That's what's needed here. Yes, the 1% of cases where there are duplicated names causes confusion, but why needlessly confuse things for the other 99%? Alansohn (talk) 21:52, 18 October 2026 (UTC)
Question 1 ambiguity Looking at some of Q1's responses, it seems some are confused whether Q1 is the scenario described in #Background regarding Always using '(City, State)' regardless of the need for further disambiguation would produce a consistent result but is less concise than state-only or city-only—Bagumba (talk) 08:01, 19 October 2026 (UTC)
I see. By further disambiguation what is meant is that this applies in a situation where some disambiguation is already required, and city-only or state-only provides incomplete disambiguation. Q1 is asking whether the city should be included in some way when geographic disambiguation is required. This could be in any form, e.g. High School (City) or High School (City, State). Q2 is asking which form is preferred or under which circumstances the state should also be included. I'm not sure how to make this more clear at this point in the discussion. —Myceteae🍄🟫 (talk) 19:38, 19 October 2026 (UTC)
@Myceteae, that may be best; to point to this thread down here. I been keeping, my eye on this RfC, and for the most part it seems pretty smooth. Issac I Navarro (talk) 19:42, 19 October 2026 (UTC)
@Issac I Navarro Yeah, I'm conflicted about meddling with the wording. It seems most people do understand what's being asked but some are confused. —Myceteae🍄🟫 (talk) 22:17, 19 October 2026 (UTC)
@Myceteae, I suggest to leave it the way it is. I been trying to keep an eye on this. If I see any that may be confused, I will try and step in. However, the rfc seems quite smooth given the amount of participants. Issac I Navarro (talk) 22:35, 19 October 2026 (UTC)
Agreed, it's going well and changes to the RFC questions or background section may actually cause more confusion. Most participants seem to understand what's being asked or are receiving clarification in the replies. —Myceteae🍄🟫 (talk) 00:29, 20 October 2026 (UTC)
An attempt to prevent autoconfirmation gaming and other issues
Should requirements to autoconfirmation be changed to prevent gaming, particularly of LTAs? This conversation started here as a result of actions taken by a likely D86 sock. Socks of this behavior edit once to get the day counter going and then make several dummy edits to their userspace (example). I see two ways of counteracting this, which I have listed below. Both methods should increase visibility of socks gaming the system and allow for more reaction time on our end. I am aware of this discussion; a previous attempt to get this implemented was rolled into that discussion at the tail end of it, not allowing much time for it to be discussed. The following proposals also take a different approach to much of what was suggested at that previous discussion: it changes the system instead of just creating a new arbitrary number to reach. This also should not significantly impact new editors. @Finfixer noted that Option 2 below could prevent some new editors who make edit suggestions or participate in discussions from becoming autoconfirmed, but that cannot be a significant amount of editors impacted nor that hard to solve. A reasonably knowledgeable editor should be able to click random article enough times while making minor edits to reach the new requirements. Pinging @Hurricanehink as a conominator and @Wizzito for starting the first discussion.
Option 1: Status quo, none of the following is to be implemented
Option 2: Make it so that the 10 edits to become autoconfirmed must come from the mainspace in order to increase the visibility of gamey edits. This would be similar to what WP:WPAFC uses for its reviewers.
Option 3: Make it so that the edits must come from four separate days instead of a simple timer until the first edit reaches four days old. This would force those gaming the system to be somewhat persistent.
Option 4: Both 2 and 3.
There may be some nuance possible within the options, but that could be resolved in a later discussion if not implemented here. ✶Quxyz✶ (talk) 23:43, 14 October 2026 (UTC)
Option 4 as nom. My rationale is largely above. ✶Quxyz✶ (talk) 23:44, 14 October 2026 (UTC)
I'm not sure Option 2 would increase the visibility of gamey edits – if anything, it will make them a lot less obvious and harder to spot. Being wary of WP:BEANS, we don't want to force some LTAs to do their gaming in mainspace either... nilnz 23:53, 14 October 2026 (UTC)
In general, a mainspace article is going to have more people watching it than a random userspace article of a new editor. Also, while this might be reasonable to see in the userspace where new editors are likely to be testing what they can do, it would be glaringly obvious to anyone who happens upon it in the mainspace. It is also not like the LTAs are not vandalizing the mainspace anyway.
Also, this proposal could have the indirect effect of increasing competency among autoconfirmed editors, which I did not discuss because that is not my main goal (and, if anything, some of the proposals are meant to be discrete). Someone who prioritizes that may take that into consideration. ✶Quxyz✶ (talk) 00:02, 15 October 2026 (UTC)
It is also not like the LTAs are not vandalizing the mainspace anyway – agree, but what this proposal will do is ensure that all LTAs game in the mainspace, and every other disruptive editor (socks/UPEs/ctop pov-pushers/meats etc.) as well. I still disagree it will be more glaringly obvious to spot in mainspace. Someone gaming outside of mainspace sticks out like a sore thumb to recent changes patrollers, and was a reliable method in the past to spot the likes of SB1 before they hit mainspace. I'd say that the majority of disruption is caught via RCP rather than watchlists, and it's worth remembering that there are probably millions of mainspace pages that aren't reliably watchlisted by active editors. Non-mainspace gaming is also more obvious when you look back through an editor's revision history, and will be one less tell available to us at noticeboards that rely on behavioural analysis, including WP:SPI, WP:COIN, WP:AE etc. For those reasons, Option 1. nilnz 01:31, 15 October 2026 (UTC)
There are lots of dark corners of mainspace with very few pagewatchers where even outright vandalism can go unnoticed for a long time, so I also doubt that minor gaming edits would be noticed any quicker in such corners. I doubt if anybody would notice some minor superfluous edits made to Çeralan, Saimbeyli (which I got by clicking the 'random page' button) Athanelar (talk) 07:24, 20 October 2026 (UTC)
Option 4, anything to make it harder to game AC is a good thing. BilledMammal (talk) 00:13, 15 October 2026 (UTC)
Option 1 - Neither Option 2 or 3 will help. We have issues with users using mainspace WikiGnoming to game extended-confirmed as it is (and thus they could just resort to using it for autoconfirmed as well), and making it go across four separate days would only do a lot better job of disguising what would otherwise be obvious autocon-buster accounts. —Jéské Courianov^_^vThrillerNight! 00:18, 15 October 2026 (UTC)
Comment Note either of these changes would require changes to MediaWiki, i.e. development work processed through Phabricator. Anomie⚔ 02:26, 15 October 2026 (UTC)
We could build a bot to grant confirmed instead. BilledMammal (talk) 04:37, 15 October 2026 (UTC)
That would not be autoconfirmation. That would be a proposal to disable MediaWiki's autoconfirmation feature in favor of manual confirmation via adminbot. Anomie⚔ 11:26, 15 October 2026 (UTC)
Please, we already deal with enough mainspace gaming; let's not incentivize it further. Take it from somebody who, in her youth, actually ran her own sock accounts (on non-Wikipedia websites, we all have a past): @Nil NZ is right, the gaming will still happen, it will just be a)a lot less obvious and b) a lot harder to clean up. This is a well meaning proposal, but completely lacks any sense of the consequences. GreenLipstickLesbian💌🧸 05:48, 15 October 2026 (UTC)
A reasonably knowledgeable editor should be able to click random article enough times while making minor edits to reach the new requirements. - your solution to normal editors being hurt by this proposed restriction is to say that any reasonably knowledgeable one will know to game it in the exact way that you say this proposal will make obvious enough to warrant a block. Is that right? 1brianm7 (talk) 06:07, 15 October 2026 (UTC)
I won't spell them out here, but there are many fast and easy ways to make ten constructive edits without arousing suspicion. Certes (talk) 15:02, 15 October 2026 (UTC)
RC patrollers won't tell you this one trick! Admins hate him! Athanelar (talk) 07:26, 20 October 2026 (UTC)
Option 1 per Nil, Jéské Couriano and GLL. Thryduulf (talk) 09:59, 15 October 2026 (UTC)
Option 1, with regret. Options 2–4 might be justified to combat casual vandals and spammers. However, the question relates specifically to LTAs who will soon learn how to work around any changes, while genuine new editors might be deterred. Perhaps the solution is better detection of potential LTA socks. I expect this is already happening quietly off-wiki. If so then I thank the editors who generously donate time to it, but won't encourage them to spill the beans here. Certes (talk) 10:25, 15 October 2026 (UTC)
I mean, if the proposal would be effective at deterring other vandals, I think it could be worth considering. I also doubt that any legitimate editor would be significantly affected by these changes. The one case I have seen even brought up is an editor who exclusively works in the backside of the encyclopedia, which I imagine to be rather rare for a newer editor. It may also delay someone from becoming autoconfirmed, but not by any significant measure. I do see the merit in other's comments that LTAs would just change their behaviors to meet the new requirements, though I still believe one or both of these would be a net positive (I am a bit less certain on the mainspace requirement). ✶Quxyz✶ (talk) 11:21, 15 October 2026 (UTC)
Option 1 per Jéské Couriano and 1brianm7. More likely to deter innocent newcomers than LTAs committed to the bit. mdm.bla 14:20, 15 October 2026 (UTC)
I think we need to think of the casual autoconfirmed editor as well. By making it harder to achieve also by just normal editing we'd be discouraging a lot of potential users from starting to edit (more). While socking and gaming is a problem, the project overall works well and is not sinking into chaos. Also think of the additional pressure on WP:AFC by less AC editors. squawk7700 (talk) 15:06, 15 October 2026 (UTC)
Alternate option: Create an abuse filter that will revoke or delay the user's promotion to autoconfirmed if it detects possible gaming. This can be achieved by setting the filter to block autopromote. The option does exist, however there doesn't appear to be any filters that are set to block autopromote. The last two options would make it more difficult for legitimate users to also become autoconfirmed. --Prothe1st (leave me a message)-- 22:14, 15 October 2026 (UTC)
Option 1 per Jeske Couriano and others, who persuasively argue that these changes would make gaming harder to detect but not meaningfully harder to perpetrate. I'm also an adherent of AC's restrictions being lightweight in general; it's meant to be a deterrent for drive-by trolls who lose interest when they see they can't sneak the word "poop" into articles, not an affirmative indicator that a user is likely to be knowledgeable or trusted. ModernDayTrilobite (talk • contribs) 19:18, 16 October 2026 (UTC)
Option 4. The notion that any of these will deter actual newcomers is misplaced, since newcomers don't even know what it means to be "autoconfirmed" and are not actively seeking this status. BD2412T 00:45, 19 October 2026 (UTC)
Option 1 Per many others who have already commented on this, it might make things worse, not to mention how it would make it more complicated to get a relatively simple permission. Theeverywherepersontalk hereIn solidarity! 12:03, 19 October 2026 (UTC)
Option 1 per all above. By no means is the current user rights regime perfect, but the suggestions here do not make it substantially more difficult for the vandals doing their thing. In particular, option 2 would already be moot for many of our returning vandals. Best, Staraction (talk·contribs) 05:21, 22 October 2026 (UTC)
Option 1 I get where this is coming from, but option two is just not going to accomplish the intended goal here, and may well make things worse. NIL NZ and Athanelar have already said more or less what I would have said here, so I won't belabor that point.Now option 3 might have some minor positive effect. Not on true LTAs, who will adjust quickly and are already quite determined, but plausibly might catch the VOAs that only make one or two edits before disappearing only to pop up again days or weeks later though that isn't all that common. Perhaps might cross the too-much hassle threshold for more casual types that are following off-wiki vandalism primers, or at least a few of them anyway the range of exertion tolerance being targeted is really quite narrow. Overall though I don't think the juice is worth the squeeze here. ~2026-46960-97 (talk) 01:50, 25 October 2026 (UTC)
Potential WP:BLP violations arising from "Suggested links"
I am concerned that the suggested links feature is apparently capable of introducing WP:BLP violations by proposing links from fictional characters to unrelated living people who happen to share the same name.
In particular, in this August 11, 2026 edit to Truth or Dare (2012 film), the Suggested links feature recommended linking the name of a fictional character in the movie, "Luke Wilson", to the article on the living person, actor Luke Wilson. The fictional "Luke" in the film (I don't actually see a source supporting the fictional character being surnamed "Wilson") is a drug dealer who flippantly kills another character, and is himself subsequently killed. The real Luke Wilson is, of course, neither a drug dealer, nor a killer, nor deceased. The edit was tagged " Newcomer task" and "Suggested: add links" and described in the edit summary as "Link suggestions feature: 1 link added."
This is an order of magnitude more serious than an ordinary erroneous wikilink. Linking the name of a fictional character involved in criminal activity to the biography of a real living person creates a misleading association, in Wikipedia's voice, between that person and the conduct described in the article. I am aware that machine-generated link suggestions are not guaranteed to be accurate, and that editors are expected to review them before accepting them, and that sometimes these kinds of errors are made even without machine intervention. Nevertheless, the feature is specifically intended to facilitate relatively easy edits by newcomers, who are likely to be particularly inclined to trust its recommendations. Furthermore, erroneous links involving living people can be substantially more consequential than other incorrect links, which do not invoke WP:BLP.
Does the suggested links algorithm have any safeguards against suggesting links from the names of fictional characters to biographies of real people, living or dead? Can such safeguards be implemented to prevent, or at least flag, potentially problematic links involving living people, particularly in articles discussing fictional characters engaging in unsavory conduct? Is there any mechanism for identifying existing edits made through this feature that might have introduced similar BLP concerns? BD2412T 01:07, 19 October 2026 (UTC)
I think that it's up to the editor to double check the link. None of these tools are perfect. Besides, I highly doubt that this would even constitute a BLP violation in the first place. Gaismagorm(talk) 11:36, 19 October 2026 (UTC)
@Gaismagorm: It is a common practice in articles on films to link names of characters in the cast list for the film who happen to have articles because they represent real people. For example, I.Q. (film) links Albert Einstein, Kurt Gödel, and Boris Podolsky in the cast list of that article. Although these are fictional representations of these individuals, they are not defamatory. A reader could readily assume, however, that a link to Luke Wilson means that the fictional drug-dealing killer in this film is meant to represent, well, Luke Wilson. Whether that is actually a BLP violation is up to the community to decide, but it sure as hell isn't a good thing. BD2412T 12:25, 19 October 2026 (UTC)
I don't see this as a particular problem for cast lists (I assume it can happen anywhere where we're dealing with two people of similar names), nor, honestly, that much of a prolem. I think people reaching a page aout an actor insead of a drug dealer will be more likely to think Wikipedia is imperfect than to assume those are the same people.... just as your linking to WP:BPL in your first sentence above leads to me thinking you typoed a link, and not assuming that you're accusing Luke Wilson of being an Asian cricketeer. --- Nat Gertler (talk) 12:54, 19 October 2026 (UTC)
Typo fixed, but that link should never have been suggested, and the fact that living people can be the target of bad links bodes ill. BD2412T 13:00, 19 October 2026 (UTC)
once again the solution to this and related problems is staring us all in the face but will not happen: get rid of newcomer tasks Gnomingstuff (talk) 13:52, 19 October 2026 (UTC)
Link suggestions (and newcomer tasks more broadly as GS has said, but especially link suggestions) is just a godawful feature. Expecting new editors who have no Wikipedia experience and may not even be particularly proficient in English to be able to "verify" anything is a recipe for disaster. Someone would need to run the data, but I would bet that for every example of a genuinely helpful wikilink being added by this feature you could find at least two which are misleading at best. The tasks like "revise tone" are even worse. I have to agree with GS that we should really just drop the ill-conceived idea that gamification is the best way to onboard new editors. Athanelar (talk) 06:55, 20 October 2026 (UTC)
Sadly, stating the obvious seldom achieves much on Wikipedia, where 'this would be a good idea if it worked' magically becomes 'this is a good idea' if its proposed purpose is to attract new contributors. AndyTheGrump (talk) 07:00, 20 October 2026 (UTC)
Is disabling newcomer tasks not something that could be achieved through Wiki-side consensus, or is it purely up to our overlords at the WMF? Athanelar (talk) 07:12, 20 October 2026 (UTC)
I'm not sure whether the overlords obtained any consent from the community for this, or whether they even tried. From past experience, getting the WMF to admit something isn't working is practically impossible. AndyTheGrump (talk) 07:59, 20 October 2026 (UTC)
I did a really painful AINB case with an inexperienced good-faith editor who got a lot of "add sources" newcomer tasks, and decided the only way to do that (honestly, it is hard!) was to ask an LLM. They would have been much better off picking an article and working on it, not trying to add sources to fifty random articles. That person hasn't edited since. No part of this is what we would want from a Newcomer Task: this one cost us a good faith newcomer IMO.
My own experience as a newcomer (6 months ago) is that I did a couple link suggestions (about 1/3 of which I could see were bad), got an "update this article" suggestion and refused it because it looked like hours of work, and then got a "copyedit" suggestion that...was an LLM article, took me a month to fix, learned about AfD merge proposals, learned all sorts of things, but that was so not a newcomer task. It was asking me to copyedit a table that was made up from whole cloth.
I think they should be replaced with "How to find an article that needs help" and "How to go about helping an article" pages, with a solid checklist in the second one. M kuhner (talk) 19:30, 21 October 2026 (UTC)
As far as I know, there is no way to make these "newcomer tasks" know that one of their suggestions is unwanted, so chances are another newbie will soon receive the same suggestion. I have encountered this with "revise tone" (or whatever it is called), where reverting an unwanted tone change just lead to another newbie getting offered the same issue. Is there some magic word to disable newcomer tasks from some pages or sections? Fram (talk) 09:43, 20 October 2026 (UTC)
Oh, and if enwiki wants to change these newcomer tasks, we (well, admins) can edit this special page. Fram (talk) 09:47, 20 October 2026 (UTC)
Well, great. If we want to shut the whole thing down we don't need the WMF on board. Athanelar (talk) 10:31, 20 October 2026 (UTC)
If you have a page where you want to disable all newcomer tasks, you can add Template:No newcomer task to it. Fram (talk) 09:49, 20 October 2026 (UTC)
That's the best tool we have and it should be used. It's using a whole-article sledgehammer to crack a one-link nut, but cracking all the nuts may not be a bad thing. Certes (talk) 10:25, 20 October 2026 (UTC)
We would need to add it to every page that has a name that could potentially be linked to a living person. BD2412T 22:08, 20 October 2026 (UTC)
The suggested links may cause occasional errors, but the "revise tone" is a lot worse. Not only is it rather unclear what it is based on (we are now letting an AI decide which "tone" is acceptable and which isn't?), it also is a poor choice for a newcomer task. Edits like this don't really revise the tone, but they do incorrectly change the meaning. Wich is probably unavoidable if you drop newbies in the middle of an article and tell them to change the tone of a sentence or at best a paragraph, instead of reading the whole article. This is less neutral and general than the previous version.This also changed the meaning. In many cases, the new version reads like AI slop. Fram (talk) 14:31, 20 October 2026 (UTC)
Most likely because in many cases the newbie in question is just prompting an AI to revise the tone for them. Athanelar (talk) 15:43, 20 October 2026 (UTC)
phab:T405185 for named entity recognition was opened in September 2025. I later raised there the issue of people with similar names being linked, but those with the same name is a similar problem. CMD (talk) 22:31, 20 October 2026 (UTC)
Where you live, in some jurisdictions, is a factor in where you can be elected or serve. Knowing what community (obviously not address) an elected official lives in also a public interest matter. So if you live in New York, and you're governor, you "live" in Albany at the mansion, but that's not your "residency". Your residency is where you vote and pay taxes.
Kathy Hochul, the New York Governor, from looking up her history, appears to have been initially in her political career a resident of Hamburg, NY; then Buffalo, NY, and now she lives in Manhattan, NYC.
So if this Infobox had a residency value, we could list the residency location (if known) of the office holder.
A terribly easy set of examples:
Donald Trump: residency 2026 = Palm Beach, Florida
NOTE: That seems to be the only semi-relevant discussion. I'm proposing this ONLY for the officeholder template. This seems like it should really be a thing. — VPP (t/c) 18:30, 20 October 2026 (UTC)
I'm inclined to oppose. In cases where it's a subject of controversy, potentially confusing, or otherwise requires explanation, inclusion in the infobox is contrary to MOS:INFOBOXPURPOSE. In the case of Trump and Hochul, at a minimum, there is a need to distinguish between their "residency" and their "residence". For former office holders, the public interest argument doesn't carry as much weight. This raises the question of whether the infobox should reflect their current residence or residency or at the time they held office. If it's really important, widely covered in reliable sources, and the value surpasses any BLP concerns, where they live or pay taxes during or after holding office can be described, and given context, in the article body. —Myceteae🍄🟫 (talk) 21:09, 20 October 2026 (UTC)
I agree with Myceteae: If it's important, write a paragraph about it. WhatamIdoing (talk) 06:41, 25 October 2026 (UTC)
CSD G7 on rejected drafts
At AfC, it's reasonably common for editors whose drafts have been rejected and who have been unsuccessful in appealing that rejection to suddenly change tack and instead request that the draft be deleted as soon as possible, which makes it eligible for WP:G7. Often they then proceed to recreate the draft, and resubmit it for review, essentially using this as a means to evade the rejection. This can work, because the next reviewer might not know the history, and it is not easy for non-admins to recover that history. The best we get is a heads up from the AFC helper that the article has been previously deleted, but I'm not sure if that even shows you times that the draft hss been deleted or only the same name in mainspace.
Does anybody have any suggestions on how we might be able to curb this? An obvious thought would be to add a caveat G7 stating that it does not apply to pages in draftspace that have been rejected at AfC. After all, I can't really conceive of a legitimate reason why an author should speedily delete their draft after it's rejected. It'll be deleted under G13 after 6 months anyway, and if in the meantime somebody else wants to create a draft at the same name, they can easily appeal the rejection or it could then probably be speedied under G6 at the new author's request to give them a blank slate. Athanelar (talk) 12:15, 21 October 2026 (UTC)
I see the problem and agree that it would be nice to block this pathway to resubmission of rejected articles. However, I'm trying to imagine explaining the new rule to a newcomer, and failing. Your draft was rejected, you aren't supposed to resubmit it, but you can't delete it? The explanation, while it makes sense, is very much inside baseball.
And while it's not useful per se, I think blanking your rejected draft (which can trigger G7) is a very understandable response to a rejection.
I think the problem here is not G7, it's the resubmission of a rejected article. I admit I don't know how to tackle that, though, given that even barring re-use of the article name is not robust.
They don't need to understand, they just need to be told they can't. Like I said, I can't see (and please do tell me one if you can) a compelling reason why a rejected draft should be speedily deleted at the author's request? Other than the loophole I'm talking about the only other reason I can see is that it would be out of an embarrassed desire to not have the rejected draft floating in their contribs, but that's not something we need to accommodate.
As for blanking, I agree; but the same caveat could apply there. Blank drafts that have been rejected before they were blanks are not subject to G7. I think "to prevent tendentious resubmission" is a plenty robust enough justification, my only doubt would be if someone else can see a reason G7 should apply. Athanelar (talk) 19:28, 21 October 2026 (UTC)
@Athanelar If somebody creates an AUTOBIO before knowing much about Wikipedia, then gets directed to the WP:An article about yourself isn't necessarily a good thing, or realizes how hostile some editors can be about subjects trying to correct BLPVIOs, it is perfectly reasonable that they might not want that draft to remain live. Or they're embarrassed of their work, they don't want it to be picked up by other people, they don't want the fact that they tried to create their own wikipedia article to accidentally mess with their real life, ect.
(Personally, I believe any AFC reviewer should be skilled enough to check a talk page or the editor's logs for other drafts on a subject if they're worried about gaming. I don't think that's an unreasonable thing to do?)GreenLipstickLesbian💌🧸 19:00, 23 October 2026 (UTC)
Hypotheticals aside, if you're got evidence that the draft author is doing this to avoid scrutiny (like this is their second time G7-ing a rejected draft, then G7 already doesn't apply. GreenLipstickLesbian💌🧸 19:03, 23 October 2026 (UTC)
MFD is generally pretty hostile when this is discovered (recent example), but the problem is discovery. Even training reviewers to check the logs doesn't help much if it's being created at slightly different titles. So yeah, I can see making a carveout in G7 for this; maybe standardize blanking everything except for the rejection template if deletion is requested. —Cryptic 23:11, 22 October 2026 (UTC)
We, as AFC reviewers, got a notice when a submitted draft has the same title as a previously deleted article. I don't see why we couldn't get a similar notice that the draft itself was previously deleted. BD2412T 00:18, 25 October 2026 (UTC)
This RfC seeks to resolve a discrepancy between the WP:Template namespace guideline, which historically advised that Templates should not normally be used to store article text, as this makes it more difficult to edit the content, and the longstanding status quo practice of having such prose templates (see the 54 entries and 6 subcategories of Category:Article shared content templates, which was created in 2008). Editors have disagreed over how to interpret "normally" in the guideline, particularly during a long-running dispute over the existence of the {{Rotten Tomatoes prose}} and {{Metacritic film prose}} templates, with a December 2023 RfC and June 2026 TfD reaching different conclusions. A recent attempt to adjust the guideline text did not garner significant engagement due to participant confusion. Editors suggested instead asking directly about the permissibility of prose templates, which has led to this discussion. Sdkbtalk 16:05, 22 October 2026 (UTC)
Survey (shared content templates)
Option 2A. This RfC speaks to the heart of why templates exist. They exist because, when information is used in multiple places, we want to centralize it rather than copying it so that we can maintain, optimize, and standardize it in a single place. This principle (expressed in the software world as don't repeat yourself) is as fundamental to reducing the workload needed to make Wikipedia as the content scope limitations imposed by our notability requirements. It is obvious for templates like infoboxes — imagine what a disaster it would be if we tried to design an infobox from scratch for every article, debating which fields to include and how to order them — but it applies equally well to some instances of text that is reused between articles. This includes A-Z series of articles that should have the same introduction (e.g. {{List of post offices in Colorado header}}) as well as sections/paragraphs that may be reused with only a few changes that can be captured by parameters (e.g. {{Year article header}} and {{Rotten Tomatoes prose}}).
Prose templates with thousands of transclusions have been used for years, with good reason:
Templated text is standardized, which is often good. Readers become accustomed to certain aspects of Wikipedia style over time, and when articles are similar, it makes it easier to navigate unfamiliar pages because they know what to look for.
Templating allows for optimization. When a format is applied over hundreds of pages, it becomes worthwhile to refine small details that probably would never have been considered at the level of an individual page. Disputes can be resolved at centralized discussion rather than playing out diffusely on thousands of low-visibility pages.
Templates can be improved over time. When circumstances or best practices change (such as Rotten Tomatoes deprecating the average score metric), we can easily make edits to templates that improve all their transclusions at once. That's a lot easier than trying to update individual articles.
The main downside of putting article text in templates, of course, is that doing so makes it harder to adjust the text (particularly since we don't yet have visual editing within template fields). Given this, we don't want to do it for articles where the text may need to be changed frequently or customized between articles. However, this RfC asks when prose templates should be allowed, not when they should be required, so editors can always just decide not to use them where they don't fit. And for pages where no frequent changes are needed, the stability of prose templates becomes a feature rather than a bug. It means that an individual editor's unconsidered personal preference won't override the standardized version collectively optimized by all the editors who contributed to the template — unless their preference is truly superior, in which case they'll be able to get consensus to change the template and improve many articles with it instead of just one.
I support Option 2A over 2B because whether or not content may need to be edited in the future is often unclear. 2A allows editors to take individual circumstances into account when deciding whether the benefits of templatization are worthwhile for a given piece of content. But most of all I strongly oppose Option 1, which would disastrously splinter our content into fragments, hampering our ability to maintain, optimize, and standardize it. Sdkbtalk 16:05, 22 October 2026 (UTC)
I agree with this analysis. In the medical and anatomy space I commonly see this used where text in one or two closely related articles is intended to be standardised (keeping both article in sync, up to date, and saving editor time), or to store complex content (such as a complex table or image with mapped links) which would visually or technically overwhelm the average editor of the wiki text. In those limited cases I think it would be better for the quality of our encyclopedic content to have them discussed on an individual basis e.g. at TfD rather than have a blanket rule. Tom (LT) (talk) 08:13, 24 October 2026 (UTC)
2A, policies and guidelines should be descriptive, and there seems to be no argument that the de facto status quo is problematic. Thryduulf (talk) 16:52, 22 October 2026 (UTC)
A well-regulated set of articles being necessary to the consistency of a free encyclopedia, my 2A right to bear content templates shall not be infringed. More seriously, pretty much per nom. I'll add that this, in a way, makes it easier to edit the text in some ways, as editing one source of information is easier than keeping many pages in sync and fixing discrepancies on each individually. Chaotic Enby (in solidarity · talk · contribs) 17:43, 22 October 2026 (UTC)
One problem with templated text is locating where to edit when editing is desired. Blueboar (talk) 18:03, 22 October 2026 (UTC)
Of the options presented, I would lean towards 2B… allowed but rare. Blueboar (talk) 11:52, 23 October 2026 (UTC)
Something that would be amazing would be a script/gadget that allows you to click on a template and move to that template's editing window, if anyone is in the mood for coding this! Chaotic Enby (in solidarity · talk · contribs) 18:14, 22 October 2026 (UTC)
Template:Excerpt actually shows an edit link in the section hatnote that will take you straight to the page being transcluded from the page it's on, so there is precedent for this functionality. Choucas🐦⬛ 22:46, 22 October 2026 (UTC)
I would love that!!!! JuxtaposedJacob (talk) |:) | he/him | 03:51, 26 October 2026 (UTC)
@Chaotic Enby I think a drawback of this is that most newbies/casual editors will not install scripts or gadgets. Power editors like us do -- but I feel that our overreliance on scripts leads to us making processes which are too technically complex for the average editor to actually use. Like this one -- heck, if we're even having you, somebody who I consider highly skilled at template editing saying that we need to simplify our system with add-ons to make things easier for the elite users... a newbie or a casual editor is just going to see the error, the awkward wording, the vandalism, struggle trying to fix it, and (because they have no emotional investment in this platform yet, like we do)... leave. Again, see my comment below about actually walking a person, in real life, through editing a template transcluded on an article.GreenLipstickLesbian💌🧸 03:57, 26 October 2026 (UTC)
Very good point. I know that editing transcluded pages in situ is technically possible (DiscussionTools, which is installed by default, manages to do it), but very costly to implement – to go back to DiscussionTools, it parses the entire HTML content of the page, finds an editing context, and converts it back to wikitext! Building a gadget that does it on any page in the Visual Editor, reliably enough to be turned on by default, will be quite a technical ordeal, and probably not one whose cost would be justified here. I'm still convinced that 2C is preferable to 1 for the only reason that editing a page under option 1 won't fix the issue on all affected pages, but just put them out of sync, which will add more maintenance costs. Still, the situation is far from obvious, and I understand both positions here. Chaotic Enby (in solidarity · talk · contribs) 17:43, 27 October 2026 (UTC)
Good, because I definitely don't understand option 2. I think it's going to cause us to loose new editors, so power editors can... have a slightly easier time of it and not have their own writing altered? Speaking as an editor, I'd rather have a mistake fixed on one page than a mistake fixed on zero pages because we have protected it because we don't think it's going to be edited. It flies in the face of WP:PREEMPTIVE and WP:5P3 -- namely, that anybody can edit and article and nobody owns anything. This is de-facto ownership, even if it's not called that. GreenLipstickLesbian💌🧸 18:56, 27 October 2026 (UTC)
Per my comment below, suggesting option 2C: "Option 2A but only when there is an expectation that the template will be used uniformly in a series of articles sharing a common structure".To take concrete examples, a common header for year articles or tropical storm lists would fit, while a background section excerpted in several Gaza war-related articles would not, as the surrounding article context and what is WP:DUE would vary from one to another. Chaotic Enby (in solidarity · talk · contribs) 19:17, 23 October 2026 (UTC)
Option 2B I am not a fan of how "templates" such as {{2026 Iran war infobox}}, {{Gaza war casualties}} (and formerly {{Gaza war infobox}}, which I merged back in to Gaza war) are being used in practice. These pages store large-scale and controversial article content separately from the main article(s): this encourages a lack of correlation between infobox and body or between lead and body, contrary to WP:INFOBOXPURPOSE and MOS:LEADFOLLOWSBODY. The Gaza war casualties template is also transcluded at Casualties of Israeli attacks on the Gaza Strip and Killing of health workers in the Gaza war, so any change to the main template has to be assessed for WP:NPOV concerns at these sub-articles. (The infobox templates also serve(d) as magnets for WP:INDISCRIMINATE material and cruft.)On the other hand, I can see how templates such as {{Named storms intro}} make life easier for editors: they standardise non-controversial information which does not have to vary across articles. The key point is that they will not have to be edited that much. For that reason I must separate the two use-cases and !vote for 2B. ~~ AirshipJungleman29 (talk) 11:40, 23 October 2026 (UTC)
I very much agree that anything that touches on WP:DUE depending on its transclusions, or is transcluded in different contexts, will be a problem. I don't think the expectation of edits is necessarily the best line to draw here: the same issue could pop up in historical CTOPs. A better line might be "consistent use in a well-defined series of articles" versus "context-dependent use in related articles". Chaotic Enby (in solidarity · talk · contribs) 13:18, 23 October 2026 (UTC)
1, a longstanding believe of mine: these templates may be nice for power editors, but they're confusing, hard to understand, hard to edit, and poorly explaining for casual editors or newbies. If there's no expectation that the text will need to be edited regularly, then a substitution should be fine. Right now, it feels like we're inadvertently using these templates to psueodo- protect certain sections of text to all but a few power editors, most interested in the topic. I'm sure that's not the intention, but that's how it works. GreenLipstickLesbian💌🧸 18:16, 23 October 2026 (UTC)
I was to to explain to a friend this RFC/template editing as it intersects with articles as his response was "As an objective observer, what the fuck does that mean?". So yeah -- the casual editors might struggle with this. GreenLipstickLesbian💌🧸 01:09, 24 October 2026 (UTC)
Option 1. It appears we're doing this again so I'll post for the third time what I last posted at Wikipedia_talk:Template_namespace#RfC:_Prose_templates: Option 2A and Option 2B create a distinction between "stable" and editable article text that is not supported in the longstanding wording or history of WP:TG and turns the expectation that article text will largely remain unchanged into a justification for storing it in a template. We are here once again to discuss Sdkb's mission to establish an exception for supposedly "stable" article text. I see no basis for treating one particular wording in articles as fixed boilerplate that ought to be protected from normal article-level editing. Certainly not at the level that would require us to alter the existing guideline. If such text is deemed "boilerplate" then that also applies to just about an endless amount of article text across Wikipedia that could be templated on the same basis. But the perceived convenience of using a template to deal with such repetition is not sufficient reason to hide article text behind a template. Nor is the notion that no particular editor sees an actual reason to change the text. Article text doesn't require evidence of a need for future edits to justify its continued existence at the article level. And, to echo the point made by GreenLipstickLesbian above, all these prose templates do is protect a class of text to a coterie of power editors rather than to editors at the article level, which is where the text is actually seen by readers and which is actually watched by the relevant editors. Οἶδα (talk) 07:04, 24 October 2026 (UTC)
Weak Option 2A I don't see a problem in limited situations. I'm not a fan of {{Rotten Tomatoes prose}} but I can see the reason for it's usage. However something like {{Gaza war casualties}} that has extensive content shouldn't be allowed. If it's necessary it can always be part of one article, and transcluded to another. Hiding so much content inside a template isn't helpful, templates shouldn't replace sections of an article. -- LCU ActivelyDisinterested«@» °∆t° 15:34, 24 October 2026 (UTC)
Option 1 by simply removing the word "normally" from the current guideline text. That word is so weaselly as to continue to cause confusion. Where sufficient strong consensus exists, -any- guideline can have an exception, and that's where the current instances need to be examined for their individual worthiness. That doesn't mean to water down the guideline itself. -- Netoholic@ 17:11, 24 October 2026 (UTC)
Option 1 per GLL and Οἶδα. Templates should not be used for this, this creates more problems than it solves, it creates problems for actually managing this content, for little no benefit. PARAKANYAA (talk) 19:55, 24 October 2026 (UTC)
Option 2A, perhaps with limitations on the size or types of text for which this can be used. I have created a number of lists that transclude sections from sublists, which should be permissible, but text for text itself should not be. BD2412T 23:14, 24 October 2026 (UTC)
Option 1 per Οἶδα. Each article should be standalone and easy to edit. Having text transcluded from other templates is confusing and unnecessary, and risks applying nuance from one topic to areas where a different nuance applies. Likening it to a software project is a red herring. Wikipedian is not code or software, it's human-generated prose on particular topics, and a certain amount of redundancy is expected. Cheers —Amakuru (talk) 23:26, 24 October 2026 (UTC)
Restrictive Option 2A – For cases like the list of named storms, where we are dealing with significant chunks of text – not bits and pieces here and there that are inserted amidst prose that editors are expected to edit – for sets of clearly delineated articles for which it would be verging on unencyclopedic to have minor style differences between, I think there is a very good argument for ensuring that the leads remain consistent. This also extends to the example for years and Colorado post offices. I oppose 2B as "expected to edit the template" is vague and also overly restrictive – an edit here and there is alright, the point is just that any edit should be made to all members of the set of articles in question. The reason we even split lists into A–Z is entirely for practical reasons, not to let them have different leads.
I do not view this as extending to small bits of prose such as the Rotten Tomatoes example. That is the sort of thing that can often be better off being woven into other text and is placed in the middle of articles, as opposed to being whole sections, and readers are unlikely to find inconsistency particularly jarring, unlike with sets of clearly connected articles that are clearly intended to have shared formatting for some sections. –Maltazarianᚾparleyinvestigateᛅ 00:12, 25 October 2026 (UTC)
Option 1 per Amakuru and GreenLipstickLesbian. Every article should be standalone, and this makes it more confusing for new editors. Ealdgyth (talk) 21:59, 25 October 2026 (UTC)
Option 1 - Very confusing for new editors. The benefits are not worth the potential loss. InfernoHues (talk) 00:35, 26 October 2026 (UTC)
Option 2a As Wikipedia loses editor count, we need to use the technology at our disposal to simplify editing the encyclopedia. Further, it is nice to see similar articles have the same text, rather than figure out how to say the same thing x number of different ways or do the messy solution of copying and pasting. Also, "templating" article prose can be a cool way to teach new editors a different part of the wiki-tech-ecosystem, to respond to the above comment by InfernoHues. JuxtaposedJacob (talk) |:) | he/him | 03:50, 26 October 2026 (UTC)
Option 2A I believe there are legitimate uses for these to provide consistency in certain cases and there is no need to ban them altogether. Reywas92Talk 03:51, 26 October 2026 (UTC)
Option 2C per Chaotic Enby. It won’t always be appropriate to duplicate prose between articles as surrounding context and due weight need to be taken into account, but when a large set of articles are going to have an identical structure, we might as well avoid duplication of effort by putting that structure in a template. I’m not convinced by the argument “it makes it hard to edit” - any editor can always just replace the template with raw prose in any specific article if warranted. -- LWGtalk(VOPOV) 07:14, 26 October 2026 (UTC)
Given the difficulty in maintaining a shared block of content in isolation from all the contexts in which it is used, I do not feel the conditions in proposals 2A and 2B are sufficient. Before explicitly endorsing a best practice, I think we need to further discuss what situations might be tenable for re-use. For example, an entire logical section of text with a starting header might contain sufficient context to be effectively maintained on its own. isaacl (talk) 16:25, 26 October 2026 (UTC)
Option 2A. It's easier to learn how to edit templates than to learn how to efficiently find and mass update every article that needs the same change. Mass updates also cause problems for watchlists (when they aren't done by trusted bots). Jruderman (talk) 01:59, 27 October 2026 (UTC)
Option 3: actually apply existing guidelines and best practices. I will explain what I mean by that, and why I am dissatisfied with the three options proposed. First, as it has been pointed multiple times in the discussion section, the way this RfC defines the current status quo is innacurate if not misleading. Neither 2A nor 2B are the norm, de jure or de facto: templates are very rarely used to store article text, and there is no such thing as a threshold where it can be expected that a piece of prose would benefit from being frozen in place. This is for all the good reasons pointed out by people !voting for option 1, and per WP:TG: hiding content within templates makes it harder to edit, hard to track down, and overall less accessible. However, framing option 1 as "substitute everything" is just downright problematic. There is a huge difference between a paragraph of plain text, and a complex table with embedded images. Moreover, I agree with many supporters of options 2 that transclusion is a useful tool, because sometimes the same quality content actually can and should be used in multiple places, both to make its maintenance easier, improve collaboration and just efficiency in general. Having said that, to me, the core issue here is storing article text, and especially simple prose/simple tables, in template space. The good news is, we have already figured out the better way to do that, and it is conveniently indicated at the top of Category:Article shared content templates: Templates which contain material which would otherwise be in main space encyclopedic articles. Please be aware of Wikipedia:Template namespace#Guidelines on this topic; consider using a template such as the ones in Category:Transclude page content templates that keep shared content in main space, making it easier to find and edit.. There are several of those, but as far as I have looked Template:Excerpt would do the job very well in almost all cases: bring back the content in main space, and provide direct editing links from wherever it is transcluded. Let's apply common sense, substitute and excerpt the simple prose and tables, and keep the things that actually benefit from being templates (e.g. clickable diagrams) as templates. We already have all the tools needed to improve things here, we just have to use them. Choucas🐦⬛ 09:34, 27 October 2026 (UTC)
Discussion (shared content templates)
Notified: Wikipedia:CENT. Reason: Wide-scale potential impact and past disputes in this area regarding breadth of participation.. Sdkbtalk 16:06, 22 October 2026 (UTC)
I know that complaining about RFC phrasing is de rigeuer, but @Sdkb:, I disagree with portraying 2 as the "Status quo". You've picked rare exceptions that likely squeaked by due to not being noticed; we wouldn't consider these strong indicators of a status quo elsewhere, where a few exceptions to a guideline (either on IAR grounds or just due to being missed) wouldn't signify a guideline doesn't mean what it says. The status quo is 1, never do this, due to the very longstanding rule in our template guidelines. If you disagree, then at least don't portray any option as a status quo and say that the matter is simply inconsistent. I also think that if you're going to mention the RFC that found a weak consensus to allow these, you should also mention the later 2025 RFC that found a consensus against them. SnowFire (talk) 20:32, 22 October 2026 (UTC)
Looking more closely, this RFC is also missing a key option between 1 and 2B, and seems to be phrased looking as a reason to remove the prohibition on prose templates. But that is separate from substing everything in Category:Article shared content templates, which is way over the top and not what people who voted to subst & delete the Rotten Tomatoes prose template are talking about. Template:Patrilineal descent of the High Priests of Israel and Template:Religions by country table Asia are clearly not really prose, but just a table, a normal use of templates. Template:Three pillars of sustainability is a fancy image. Template:Transclude DYK is Wikipedia-internal. None of these are prohibited by the guideline that is really under contest here. It's fine to challenge the Template Guidelines but this phrasing is inventing a position for the "other side" that doesn't exist. My suggestion would be to make this RFC be about removing the line from WP:TG that Templates should not normally be used to store article text that may need to edited, as this makes it more difficult to do so. They should also not be used to "collapse" or "hide" content from the reader. Based on the above !vote rationales provided for 2A, that is clearly what is actually at contest. Keeping this line in the template guidelines would not imply deleting this entire category, just making anything prose-only subst-only. (Failing that, at least rephrase option 1 to remove the claim it would mandate emptying that category, because it doesn't.) SnowFire (talk) 20:59, 22 October 2026 (UTC)
I completely agree, the options presented as alternatives to the status quo miss the mark of what the discussions at play have actually been about. I was strongly in favor of mass substuting the Rotten Tomatoes template, yet I believe we should be transcluding way more article content, not less. There is a big difference between templates that allow sharing quality content in all places it can be needed, and templates that uselessly freeze a specific phrasing for three sentences for the sake of pointless standardization. Choucas🐦⬛ 23:08, 22 October 2026 (UTC)
Exactly. I do not find that this RfC fairly portrays the status quo or appropriately captures the landscape of recent discussions. It feeds a bit of context and encourages answers that fit a specific mold. Οἶδα (talk) 03:42, 24 October 2026 (UTC)
I understand the intention here, but I believe this is completely overbroad. If you include all the pages in all the subcats of Category:Article shared content templates, that means lumping together very, very different templates. If this RfC included only the many problematic prose templates that have all the issues WP:TG warns against, because they're basically a paragraph or simple small table that stealthily obscure article content and make it actually harder to edit pages they are on, that would be one thing. But thrown in here is also Category:Transclude page content templates, including the ultra powerful Template:Excerpt, which allows you to precisely fine tune every detail of the transclusion while keeping the content itself in mainspace. I personally consistently !vote at WP:TfD for the substitution of the first kind; at the same time I think Template:Excerpt is very underappreciated and could be used much more to immense benefit. Because of this, I just don't see how I can respond to the survey, as this position is just not represented. Choucas🐦⬛ 23:00, 22 October 2026 (UTC)
Focusing on Wikipedia:Template namespace feels like a bit of a red herring here. Excerpts are not limited to template namespace. The question is, more broadly, what sort of content should be duplicated across articles from a single point of origin. CMD (talk) 12:25, 23 October 2026 (UTC)
I'd also prefer a discussion on this. GreenLipstickLesbian💌🧸 18:43, 23 October 2026 (UTC)
I agree that when considering guidance on re-use of text and wikitext, other approaches such as labeled section transclusion should also be considered.
In my opinion, a key consideration in the feasibility of including content from another page is how to maintain that content in a way that is independent of the surrounding context. This is generally straightforward for navigation boxes and certain types of tables, which is why having them in templates is commonly done. It often is harder to maintain shared prose content in an isolated manner. One has to search for all the uses and double check how the shared content fits within the contexts in which it is used, and make appropriate adjustments simultaneously. This is even harder with labeled section transclusion, as I think source text searches have to be used. While it is true that Ted Nelson's original concept of hypertext included weaving together documents from parts of others, there's a reason why it wasn't realized on a large scale: it's hard to manage coherency when the surrounding context for a piece of content isn't readily apparent. isaacl (talk) 18:44, 23 October 2026 (UTC)
The rather inflated framing of Category:Article shared content templates here as proving "longstanding status quo practice" is specious at best. As I posted previously at Wikipedia_talk:Template_namespace#RfC:_Prose_templates: The largest prose templates include {{Aired episodes}}, which is used in 485 articles, but I cannot find any past discussions at TfD or elsewhere determining its acceptability as a template on Wikipedia or compliance with WP:TG. {{Television franchise episode count}} is only used in 24 articles and likewise has no discussions about it beyond a few merges of duplicate templates. I also cannot find meaningful discussion about {{Year article header}} despite its use in roughly 500 year articles. If these are the only examples, essentially 2 across all of Wikipedia, and there has been no actual discussion regarding the appropriateness of their function in the template namespace then it is dubious to claim that they somehow establish why WP:TG specifically includes the word "normally" or that they serve as proof that such "exceptions are allowed" to the top-level guideline that "Templates should not normally be used to store article text. Such content belongs in the article pages themselves." Especially when we're talking about templates used to store text in the ordinary running text of articles rather than templates with some ancillary article text function that might plausibly justify an exception. The 2014 RfC that introduced "normally" to WP:TG was also rather brief and unimpressive. Either way, "exceptions are allowed" is not, by itself, an argument that a particular exception is warranted. If anything these few examples would indicate how rare exceptions are here on Wikipedia, not that such exceptions should be expanded. And as Netoholic stated in that 2014 RfC, such exceptions would have to maintain their status as exceptions which "break" this particular rule by way of strong consensus. And as Netoholic wrote in their endorsement there: Ever since 2005, its been the intent of the community that the Template namespace not be used to store encyclopedic content. Templates are used to maintain formatting of that content (such as {{cite web}} calls), alert messages to readers ({{citation needed}}), and to provide navigation, but the main "meat" of an article, its information and data that we want editors to freely and easily be able to update, should be in the article namespace itself. Wikipedia:What is an article? describes what counts as encyclopedic content. Sdkb's counter to that was that it's not just two examples. There are more than 50 templates in Category:Article shared content templates, including very clear-cut use cases like {{Named storms intro}}. As I responded, those are very different templates contained there. Nearly all of those templates are not comparable to the kinds we have been discussing both in terms of content and in the frequency of their use throughout Wikipedia. They're basically all data tables. And as with the others, I cannot find any actual discussion regarding the appropriateness of their function in the template namespace. They're WP:OTHERSTUFF that could just as likely be subst'd for the same reason. Or perhaps retained by way of consensus, which is why I would prefer not to settle for Option 1 because I fundamentally reject the options we're being presented here. But consensus has not occurred. And consensus through editing is no longer presumed when disagreement becomes apparent. Well... disagreement has become apparent. And, again, as SnowFire observed above, those kinds of templates are not what is really under contest here. This second RfC specifically announces itself in its prompt as being focused on "templates containing article body text"? Indeed, this entire debacle has been centered on chunks of prose in running article text being templated. As SnowFire also said, there's a false binary between Options 1 and 2B. A 'Never' vote to this RfC's prompt is not necessarily a vote to subst everything in Category:Article shared content templates. Though it could be. That remains to be seen. But after the recent WP:TMPRfC and the recent RT/MC prose template TfD, this RfC here appears rather meticulously phrased so as to more easily push through a change to the prohibition on prose templates that has so far failed. And because Sdkb deems this a disaster, we must continue to bang on about it. Cheers! Οἶδα (talk) 07:27, 24 October 2026 (UTC)
Also:
A recent attempt to adjust the guideline text did not garner significant engagement due to participant confusion.
I'm not so sure about that conclusion. Either way, I merely chanced upon this RfC here despite participating in the first. The other participants of that first RfC could do with a notification, without prejudice of course. Οἶδα (talk) 07:37, 24 October 2026 (UTC)
So you've forum shopped this to a third venue after not getting the desired outcome at the previous two. I'm not impressed. * Pppery *it has begun... 06:29, 26 October 2026 (UTC)
Are we making it clear to new editors what our policies surrounding AI use are?
Hi all. From my experience in recent weeks at AfD, and in the past couple of days at the Teahouse, it seems as though a great number of editors appear to be entirely unaware of our AI usage policies. Though it can't be said for certain whether they're being entirely honest in this regard, I'm wondering if it might be prudent to offer a notice in the draft space for new users that simply indicates this fact, given that many go to AfC as a preliminary step without reaching autoconfirmed status first. Even then, is it unreasonable to suggest offering a similar notice for autoconfirmed users on publishing pages until their first (completed) page creation? Just think it might help us to cut down on good faith actors at AfC and AfD, and reduce the extent to which feigned ignorance can be used as a justification for LLM use in such cases.
I think there's a note on the AfC wizard that AI-generated content is not allowed, but iirc it's rather low down in a list of other points; I went looking for it recently and only saw it because I was looking. I would definitely support making this information more visible somehow! I think this is a good idea: a similar notice for autoconfirmed users on publishing pages until their first (completed) page creation. Suðurhafsljósæta (talk) 14:02, 24 October 2026 (UTC)
LLM Paste Check, if it's triggered, also pops up a notification telling you not to use AI (although, confusingly, it does offer an option to keep the text, kind of a mixed message). Gnomingstuff (talk) 22:37, 24 October 2026 (UTC)
I'd say it'd be a better use of screenspace than either the licensing notice below the edit box or the copyright infringement one above it, or both put together for that matter, but there isn't anything equivalent in the visual editor. —Cryptic 22:48, 24 October 2026 (UTC)
We can change the notice. On Spanish Wikipedia iirc correctly, they warn much more for copyright violtions. I'd say it needs a pretty clear discussion given the wide reach. In solidarity, —Femke (talk) 🐦 03:44, 25 October 2026 (UTC)
I don't think our policies on AI are clear to ourselves. BD2412T 23:09, 24 October 2026 (UTC)
I spent the day yesterday adding our LLM policies to various templates facing new users (AfC presubmission template), and making it clearer in others (G15 user talk message, Article Wizard). I also added it to our many WP:simplified ruleset-like pages. @Mathglot added something friendly (but maybe a bit cryptic) to our welcome templates. The big missing one is the edit window, but that would need clear prior consensus. In solidarity, —Femke (talk) 🐦 03:49, 25 October 2026 (UTC)
Looked at Help:Introduction, assuming I am a good-faith user who actually is going to try to look at this stuff, and, well.
The "Policies and guidelines" button is small, right below a big glowing blue button to "Get started." The UI is telling me that this is fine print I don't have to click.
If you click that, the "Policies and guidelines" button becomes blue, but it's still small and shunted off into the corner; meanwhile; beneath the welcome paragraph are two sandbox edit buttons and a list of links that take editors directly to possible tasks, both of which seem likely to become offramps away from the policies.
3 clicks in, we finally get something about AI. Unfortunately, it doesn't link to NOLLM and instead links to "basic copyediting," which is more permissive than what NOLLM allows. It also doesn't actually say what AI tools include (since this is often a point of confusion for people). The Neutrality section does have a quiz, so a quiz for AI use might be helpful for the 5 people who end up seeing it. (Questions like "which one of these edits is not basic copyediting?" and "which one of these is not an AI tool?")
The restriction on AI completely disappears in the "summary of policies" at the end.
That being said I don't know how many people are actually using this stuff. I certainly didn't. Gnomingstuff (talk) 07:02, 25 October 2026 (UTC)
That's a good find! The main Help:Introduction gets viewed more than 100,000 times a month. I've added a friendly "Just make sure it is you, not an AI improving Wikipedia." Does that work well as wording?
When we go down the policy and guidelines pages, the pageviews drop to about 2000 a month. I've removed the link to basic copyediting, and changed the wording to be in line with NOLLM. In the summary (only 1200 views), I've removed the explanation of the difference between policies and guidelines and have added some text about AI. In solidarity, —Femke (talk) 🐦 07:38, 25 October 2026 (UTC)
we may wish to put them on welcome templates. Tankishguy 17:49, 27 October 2026 (UTC)
This vas already been done to a certain extent, I know that Template:Welcoming that I like to use was tweaked months ago for example. Choucas🐦⬛ 20:15, 27 October 2026 (UTC)
Reopening the Discussion on Restaurant Notability
After many years of no consensus, I'd like to re-open the discussion on having a specific policy within WP:NORG for restaurants and like establishments. Why? A few reasons.
Over the years, Wikipedia has attracted a great number of articles on non-notable businesses that wish to use inclusion in Wikipedia for SEO - and now, for increased attention from LLMs. This problem only accelerates over time.
The discussion of exactly which sources and circumstances are just barely enough to establish notability tend to come up, and a lack of documented consensus makes AfD needlessly complex.
There is a type of news coverage endemic to just these businesses, and it would be helpful to delineate that it usually doesn't establish significant coverage. Like tech companies have a proclivity to generate massive numbers of corporate and founder profiles despite non-notability, restaurants generate restaurant reviews. These are published in local newspapers, and in local newspapers that also act as national newspapers like the New York Times; they also sometimes appear as human interest articles in publications like The Economist. But these reviews are fundamentally routine announcements or occasionally advertising; the role of a newspaper while it is reviewing a local restaurant is characteristically not the same as its role when it is reporting major current events. A restaurant review in the NYT is not the same as an NYT news article about some event concerning the establishment.
Fourth, the treatment of lists and awards remains ambiguous. In general we accept winning significant awards for artists, since this comes with significant biographical coverage. We accept it for academics, because the contributions of such academics are inherently significant and generate biographical information of wide interest. We do not accept it for businesses generally, because the awards have a proclivity to be commercially motivated and usually do not attract a celebrity or landmark level of focused news coverage. In general we want articles to be able to say something beyond that a place exists and that it has been mentioned here and there; articles on restaurants who have Michelin stars, whose chefs have James Beard awards, or which have been opened by a celebrity chef tend to lack much detail (because they are often not really notable).
For this reason I spruced up the old failed policy proposal at WP:REST. What are people's thoughts? Is it worth saying something? Can we come to any consensus on these points?
So basically, if we don't like something, like a tech company or restaurant, we can disregard all media coverage about it as "routine" and deem it non-notable? Got it. Jessintime (talk) 03:32, 25 October 2026 (UTC)
If you think these sources are WP:SIGCOV and that articles on these restaurants are useful, feel free to say why. It's not whether I like it; the WP:GNG exists for a reason. FalconK (talk) 03:39, 25 October 2026 (UTC)
This is precisely my point. Despite the trigger word "useful", I am not suggesting the utility of the article itself is a criterion. Rather, if our goal is to write an encyclopedia, is it a useful activity in service of that goal to write such articles as these? FalconK (talk) 21:56, 25 October 2026 (UTC)
If our goal is to write an encyclopedia that informs people, why would it not be appropriate to write an encyclopedia that informs people about restaurants? WhatamIdoing (talk) 22:24, 25 October 2026 (UTC)
Sure! You can also do the same thing with "significant", "independent", and especially "secondary" (which is why some have shoved "secondary" into all sorts of places). Anomie⚔ 13:15, 25 October 2026 (UTC)
These are published in local newspapers, and in local newspapers that also act as national newspapers like the New York Times; they also sometimes appear as human interest articles in publications like The Economist. But these reviews are fundamentally routine announcements or occasionally advertising
Given that The New York Times employs a total of two restaurant reviewers -- which is the most it has ever employed -- and that there are tens of thousands of restaurants in New York City, it is impossible for the Times to run "routine announcements" about every restaurant that opens, let alone advertise for them. You seem to be living in a made-up mental world where everyone who opens a bodega gets a profile in the paper about it.
We accept it for academics, because the contributions of such academics are inherently significant and generate biographical information of wide interest.
No, it's the literal opposite. We accept it for academics because they don't readily generate biographical information, as WP:NACADEMIC states: "Many scientists, researchers, philosophers, and other scholars (collectively referred to as "academics" for convenience) are notably influential in the world of ideas without their biographies being the subject of secondary sources." Gnomingstuff (talk) 05:21, 25 October 2026 (UTC)
What do you write in an article where one of the two NYT reviewers has reviewed it? That the food was good? I don't think they review every bodega in the city, obviously, but there are a lot of non-notable things reviewed in newspapers because it's useful for the people reading the newspaper to know what to eat rather than because the eatery is newsworthy. FalconK (talk) 05:30, 25 October 2026 (UTC)
What do you write in an article where one of the two NYT reviewers has reviewed it? Based on a quick glance at this weeks’ NYT food reviews, I see encyclopedic info such as the neighborhood in which a restaurant is located, the cultural and professional backgrounds of the owners/chefs, the date the restaurant opened, the circumstances that led to the restaurant becoming successful, etc. It’s not necessarily just “eat here, the pho is to die for”. If the newspaper thinks its readers might want to know the history and context of a restaurant, why shouldn’t we also think our readers might want to know that information? -- LWGtalk(VOPOV) 08:29, 25 October 2026 (UTC)
I'll concede there are some restaurant reviews that definitely go far enough to become significant independent coverage. However, the Times also publishes the ones from their newsletter alongside, and those that I have seen (such as ) very clearly do not. Their recent review of Corima is much longer, but I'm still not sure it fits; the Times' readers benefit greatly from Mishan's vivid descriptions, but those and the small amount of illustrative context given make awkward material for an encyclopedia article. FalconK (talk) 08:55, 25 October 2026 (UTC)
How are you defining "notable" in the sentence "there are a lot of non-notable things reviewed in newspapers"? If "notable" doesn't mean "written about in newspapers," then what does it mean? Levivich (talk) 14:14, 25 October 2026 (UTC)
I tie it back to WP:WHYN, particularly the bit about wanting the article to be more than a few perfunctory sentences. If a business is given a review that makes you want to go there, but contains only practical ephemera, is it useful to repeat the ephemera here? Many of the Times reviews do just this: lots of people will know there is a restaurant called Andamiro in Brooklyn. It looks really good; I might even go there next time I am in that part of the world. But from the review, all we know is that it's there, the name of their chef, how it is furnished, part of the menu and prices, how expensive it is, whether it's accessible, how loud it is, and whether it was to Mahira's liking. Great information if I want to know if I will like it for lunch, but this does not fill an encyclopedia article. FalconK (talk) 16:08, 25 October 2026 (UTC)
Lots of plainly non-notable material gets written up in newspapers, and I'm going to have to say that restaurant reviews generally fall into that category. They are written as guidance to prospective customers, and particularly as an introduction to new places, but they tend to be ephemeral and wouldn't in my mind count as sustained coverage. Mangoe (talk) 17:13, 25 October 2026 (UTC)
No single article can count as "sustained" coverage. WP:SUSTAINED means that the subject gets attention over and over again. One article a year for several years might be sustained, even if the article is short. WhatamIdoing (talk) 19:36, 25 October 2026 (UTC)
Levivich, have you ever flipped through an ordinary daily newspaper (e.g., The Wichita Eagle, not The New York Times local edition), and counted up all the sources? Especially if ignore the copies of articles from the wire services, there are often a large number of short articles that say things like "Wreck caused traffic jam" or "Police responded to a call" or "Organization hosting event". We want to write about Traffic jam, but not about Traffic jam outside Lake Wobegone fire station on 32 Octember 2026. WhatamIdoing (talk) 20:12, 25 October 2026 (UTC)
I see the tenor of discussion over there is about the same as here: the reason I want to put a finer point on this is definitely because I personally do not like restaurants or tech companies, rather than the contents of WP:MILL. FalconK (talk) 07:30, 25 October 2026 (UTC)
Meh… there is a HUGE difference between a review in a small town newspaper and one in a regional/national paper. The difference is in audience size, and how that impacts notability. A review appearing in the Smallville Gazette will be read by a few hundred people, while the exact same review appearing in the NYT will be read by thousands (millions?). Thus, more people will be aware of a restaurant that gets a review in the NYT. That awareness is a factor when determining how notable the restaurant is. Blueboar (talk) 13:40, 25 October 2026 (UTC)
The contents of a remarkably unclear essay? PARAKANYAA (talk) 15:43, 25 October 2026 (UTC)
The problem with WP:MILL is that it's meant to apply to cookie-cutter articles about nearly identical, closely related subjects, and not to those that gain individual attention. The meaning of MILL is "Please, please, don't create separate articles about each of the individual 40,000 Starbucks locations in the world, especially if 99% of the content will be the same in all of them. We need an article whole chain, and maybe there could be a couple of extras if one of the locations turns out to be historic or something, but seriously: not 40,000 nearly identical articles."
However, it gets interpreted by some editors as something like "Eh, restaurants are common; practically every town has one. WP:ITSNOTIMPORTANT. Therefore restaurants are run-of-the-mill, and we shouldn't have articles on restaurants, even if we have a dozen sources and could write a long, well-sourced Wikipedia article about it." WhatamIdoing (talk) 19:09, 25 October 2026 (UTC)
There is a type of news coverage endemic to just these businesses - This is true of all sorts of subjects. Music, art, film, video games... we rely on reviews for all of them. There are some genres and subgenres that have blogs that seem to review basically every release that comes out (horror movies, heavy metal, and Christian music come to mind), and we accept those reviews as contributing the same to notability as a major newspaper/magazine feature. So why not restaurant reviews? I'm not sure if there's a good way to raise that bar, or even if it should be raised, but at minimum yes, subjects that have publishing infrastructures erected around them are disproportionately represented on Wikipedia given how we evaluate notability. Perhaps we could require that at least one source comes from a publication that shows a broader audience than e.g. a local restaurant review site, or a niche genre review site. But that sounds awfully hard to articulate and enforce... Adding: there is at least one important difference between restaurants and those other types of subjects. An album or movie that gets a flurry of reviews on release is still available to be listened to or watched. A restaurant that gets a flurry of reviews and then closes is just gone. Maybe implications for lasting significance. —Rhododendritestalk \\ 13:29, 25 October 2026 (UTC)
A notable restaurant that closes is still a historically notable restaurant. Examples: Chumley's and the 21 Club in NYC. Blueboar (talk) 15:29, 25 October 2026 (UTC)
These generate coverage like , providing a very effective contrast to a restaurant that is covered only in reviews. FalconK (talk) 16:19, 25 October 2026 (UTC)
Subjects (restaurants or otherwise) don't have to have "lasting significance". They only need to "have attracted attention over a sufficiently significant period of time". Ten years of attention that says "This is an unimportant subject" is "attention over a sufficiently significant period of time".
Remember, "significant coverage" is significant amount of coverage; it is not coverage that says the subject is significant. WhatamIdoing (talk) 19:19, 25 October 2026 (UTC)
I agree with @Rhododendrites that subjects that have publishing infrastructures erected around them are disproportionately represented on Wikipedia given how we evaluate notability. We have chosen to not require the subject to be "significant" or "important" (in editors' opinions, or even in sources' opinions). We have chosen to write about whatever we have enough sources for. This means we will write a lot more about certain subjects than others. See, e.g., Wikipedia:Village pump (miscellaneous)#Why are nerds under-represented vs. jocks?: We write less about "nerds" because there are fewer sources about academics. We write more about "jocks" because there are more sources about athletes. The same is true for pop musicians vs classical musicians, film actors vs stage actors, restaurants vs gas stations, and so on. WhatamIdoing (talk) 19:53, 25 October 2026 (UTC)
Generally, if there are significant reviews of a creative work like films and books from established reliable sources, there's also likely been interest in the creation aspects of the work (for films, production elements, for example). I would argue that if you have a film that the only sourcing that can be identified are reviews and these not from major sources, the film likely isn't really notable (but we don't have anything really set up for this outside of the rebuttable presumption of notability that applies to all topics).
I say that because a restaurant where the only independent sourcing are reviews from local sources and with no other discussion of the origins of the restaurant, that likely does not make the restaurant notable. We want more than just reviews about the food but about its history and impact within its local or regional area. Masem (t) 23:04, 25 October 2026 (UTC)
I agree with Cbl62’s comment in that discussion: the current notability guidelines seem to be working to weed out non-notable restaurants and keep notable ones. If anyone disagrees, please share some examples of AFDs that closed keep which should have closed delete. -- LWGtalk(VOPOV) 21:25, 25 October 2026 (UTC)
Oh man, how did I miss that? But I think the outcome leaves us in a not great place. The debate continues over whether, for example, getting a Michelin star makes a place inherently notable. So we end up with articles like Nico (restaurant), which epitomize what I am saying here: it checks all the boxes. Lots of reviews and awards. But all we can say about it is 6 sentences. There are many, many other restaurants also called Nico, but this one, we deem, is the one that will be important for all time. Does this really make sense? FalconK (talk) 21:41, 25 October 2026 (UTC)
Like Californios (restaurant), the Nico restaurant should be more detailed with especially history and menus. George Ho (talk) 22:04, 25 October 2026 (UTC)
(edit conflict) It was at least open for several years. We also have e.g. Heartbreak (restaurant), which was open for less than one year, but happened to get a Michelin star in that one year, and nobody appears to have talked about it since. Ukiyo (restaurant) open for two years. Betony (restaurant) open for three. These are just from clicking around the NYC Michelin list, but even within that list there are others open for just 2-3 years. IMO these sorts of articles, where nothing is said other than that they exist and that they received a Michelin star, should just be redirected into the Michelin lists (or any notable chef/restaurateur involved). That said, we don't need new rules for that given WP:NOPAGE. But I do think restaurants are an interesting topic to talk about notability, because of a way that they, and many companies that do not produce artifacts, are fundamentally different from articles about art forms in that they leave nothing behind to talk about. Their food is served until they close, and only in very rare cases will anyone write about it well after closing. I don't know that there would be support for such a thing, but it would be interesting to come up with a rule like "for companies that last less than 10 years, we need coverage that extends beyond the time of its closing". Yes, 10 is arbitrary and it is a higher standard than what we currently have, but seems worth a conversation anyway... —Rhododendritestalk \\ 22:11, 25 October 2026 (UTC)
Winning a Michelin star produces sources, and since the existence of sources is what we care about, having a star = extremely high likelihood that sources exist. I think that in all of Wikipedia's history, only one Michelin-starred restaurant has been deleted, and that one was in a smaller, non-English-speaking country where most enwiki editors struggle to find any sources, which causes me to doubt that we made the right decision. WhatamIdoing (talk) 22:33, 25 October 2026 (UTC)
It sometimes produces sources. But since the awarding of a star doesn't come with in-depth coverage on its own, we probably shouldn't let Michelin nominate restaurants into notability. If depth of coverage comes after the star, it would deserve an article, but it's not the star doing that. We have hundreds of articles on Michelin-starred establishments about which there is little more to say than that. FalconK (talk) 01:44, 26 October 2026 (UTC)
The election of a US president comes with no coverage whatsoever "on its own", and yet we never have any problems with deciding whether a newly sworn-in US president is notable. The star is a marker or indicator of separate coverage to be searched for, rather than coverage "on its own" (though the Michellin Guide does provide some information along with the star itself). WhatamIdoing (talk) 01:59, 26 October 2026 (UTC)
This is the problem with the restaurant article argument that it has a Michelin star therefore it must be notable. It's hard for the US president to avoid media coverage, but it seems pretty easy for a Michelin starred restaurant. FalconK (talk) 03:16, 26 October 2026 (UTC)
It seems to me that it is very difficult for a Michelin-starred restaurant to "avoid media coverage". WhatamIdoing (talk) 03:58, 26 October 2026 (UTC)
As a counterpoint, the only Michelin-starred eatery I’ve personally eaten at appears to have virtually no information online beyond the Michelin listing itself, some reviews from customers on social media, and one food blog of questionable reliability. Even if we assumed all available sources were acceptable, an article about it would read X is an eatery selling [FOOD GENRE] owned and operated by [NAME] since [DATE] located in [CITY]. It received a Michelin star in [YEAR]. It is popular with both local and out-of-town people. -- LWGtalk(VOPOV) 04:22, 26 October 2026 (UTC)
This is why I would like to be explicit that the award doesn't make it notable. There are tons of such cases. The ones that have coverage are notable without needing to rely on the award, so it hurts nothing to explicitly spell out that "but it won an award" arguments don't contradict a lack of notability. FalconK (talk) 07:45, 26 October 2026 (UTC)
"It won an award" is often a short way of saying "It did something that is strongly correlated with independent sources existing". I can see how it might be irritating, but I don't see how it changes the facts. We could tell people "Don't say 'It won an award'; instead say 'Here are several independent sources that were published because it won the award'," but I think the difference is largely cosmetic: The sources existed no matter how the editor phrased their response; the restaurant was notable no matter how the editor phrased their response.
It reminds me of people saying that 'per nom' is an invalid response at an AFD, but 'I agree with the reasons given by the nom' is okay with them. (Sometimes it turns out that they don't know what "per" means). WhatamIdoing (talk) 20:40, 26 October 2026 (UTC)
It seems to me that it is very difficult for a Michelin-starred restaurant to "avoid media coverage". It is. And if the only coverage it gets is within a month or two of that announcement, then it closes and nobody ever mentions it again, is that sufficient for a stand-alone Wikipedia article. I know well enough that by our current standards the answer is yes. I don't see a problem with discussing changing that, though. —Rhododendritestalk \\ 12:18, 26 October 2026 (UTC)
It could be. But per WP:PAGEDECIDE and other guidelines, editors can always choose to cover notable topics at another page. I don't see why we need to change the guideline for the few odd cases here and there. Katzrockso (talk) 12:37, 26 October 2026 (UTC)
Because otherwise we argue endlessly at AfD about whether a Michelin star settles the question, with inconsistent outcomes. FalconK (talk) 02:15, 27 October 2026 (UTC)
How do we know that all we can say about it is 6 sentences? All I can tell is that all we currently say about it is 6 sentences, but I think it could be expanded. WhatamIdoing (talk) 22:27, 25 October 2026 (UTC)
Nico (restaurant) is an interesting example of a larger problem, which is that it's easy to overlook the possibilities for expansion. There are three possible "subjects" for this article:
Nico, a French bistro that was open from 2013 to 2019.
Maison Nico, a French café.
Nico Delroque, the French chef behind both of them.
IMO all three of these should be expanded upon in a single article, even though the title needs to name just one of them. WhatamIdoing (talk) 22:49, 25 October 2026 (UTC)
With what would one expand them? FalconK (talk) 01:45, 26 October 2026 (UTC)
At best these would support an article on Nico Delroque, mentioning his restaurants. Why do you think they support the notability of the closed restaurant with the 6 sentences article? FalconK (talk) 03:18, 26 October 2026 (UTC)
There are already 16 sources cited about the closed restaurant in the article, so I didn't think it would be pointful to suggest any additional ones for that. The article about the open restaurant has some history of both closed and open versions in it. So does this source.
But I think you've missed the point. Imagine an article that doesn't just say something like:
"Nico was a French restaurant that won an award."
Imagine instead one that says something like:
"Nico was a French restaurant that won an award. It closed during the pandemic lockdowns, and its successor, Maison Nico, opened at a time when take-out menus were important. The founder and chef is Nicholas Delaroque, who trained in France and always dreamed about opening a French-style épicerie[fr]..."
In this merged-up model, we get three subjects for the price of one article. WhatamIdoing (talk) 03:54, 26 October 2026 (UTC)
This would be a better article, but I wonder if the better article would be one on Nicholas Delaroque discussing all his restaurants, and maybe some redirects. FalconK (talk) 02:25, 27 October 2026 (UTC)
I don't think it matters what the article title is. WhatamIdoing (talk) 17:56, 27 October 2026 (UTC)
This draws a false equivalence between "tech companies" and "restaurants". In practice, we don't have a restaurant spam problem the way we have a company spam problem, either by quantity in the queues or by difficulty of review (company articles have churnalism and related-party-coverage problems, while restaurant sourcing is extremely straightforward). We accept, across a multitude of topic areas, that reviews can demonstrate notability, and absent any demonstrated evidence that notability criteria as currently applied are problematic, besides FalconK's opinion they personally do not like restaurants, I see no need for a change in the criteria. ~ A412talk! 21:39, 25 October 2026 (UTC)
Haha, I really liked Wild Ginger (restaurant) each time I have gone there, and I can see why it wins awards. But it didn't seem to have a lot of history or significance to it, you know? It's just one of several really good eateries up the street. If it closes, I won't likely think about it again. FalconK (talk) 21:52, 25 October 2026 (UTC)
@Falcon Kirtaran I think you might enjoy WP:PAGEDECIDE and lists. If you truly can't say more that about X words on a restaurant in Seattle, then discussing a merge to List of restaurants in Seattle is reasonable No, it's not rewriting the notability criteria (sorry!) but it's a reasonable compromise. GreenLipstickLesbian💌🧸 02:34, 26 October 2026 (UTC)
I have pointed this section out before in several contexts, but those who think an award or a review automatically confers notability do not seem to credit it much. This is why I am raising this at all. FalconK (talk) 03:22, 26 October 2026 (UTC)
Yes, that is major drawback of a Wiki-model which emphasizes collaborative editing. GreenLipstickLesbian💌🧸 03:45, 26 October 2026 (UTC)
There is some value in trying to build consensus on whether awards alone render a restaurant notable. We go around in circles about this otherwise. If it's silly to try and arrive at (and document) that type of consensus, why bother having a notability guideline at all? FalconK (talk) 07:51, 26 October 2026 (UTC)
I don't think that we have a consensus on:
Award → therefore notable.
I think we have a consensus on:
Award → therefore coverage → therefore notable (→ therefore if you are trying to delete this, you're probably screwing up).
Award → therefore coverage is false. There are a ton of cases of award and coverage, but there are also counterexamples. Therefore, if one is trying to argue that the award settles the debate on the subject's notability, a fallacy is committed. But it's a completely needless fallacy, because if there is coverage, you can just point to the coverage. Mentioning the award in AfD is pointless. FalconK (talk) 02:22, 27 October 2026 (UTC)
It depends on the award, no?
Mentioning the award at AFD is helpful in that it tells people what the editor's thought process is.
A sensible response to such a comment might sound like "Well, of course, we do expect to find sources for restaurants that earned their third star, but it's the sources rather than the award that matters for Wikipedia. Which sources have you found that you think would be helpful for this article?" WhatamIdoing (talk) 18:00, 27 October 2026 (UTC)
We have two types of notability policy: coverage-based notability (WP:GNG, WP:NCORP) and areas that attempt to have objective notability standards (WP:NPROF, WP:NPOL, etc.) Restaurants are under the former, so by default nothing, including awards, confers automatic notability to restaurants. We don't need to write an exception to the rule, because this case is not exceptional. ~ A412talk! 18:56, 27 October 2026 (UTC)
Where this breaks down is when different editors in the same deletion discussion view the relevant notability policy differently. This happens in both directions:
"this restaurant is objectively unimportant" (typically citing WP:ROUTINE, WP:ROTM, WP:10YT) vs "this restaurant has coverage, so it doesn't matter if we think it's important"
"this restaurant lacks sufficient coverage to write a useful article" vs "this restaurant won an award so it must be notable"
The Wild Ginger article seems entirely unproblematic (well, the article could speak more to the food they serve, but reading the sources, that's just editors not including that information from the sources), unless you have the prior that we should not have an article for this restaraunt. Is this the best example you have of a systemic problem? ~ A412talk! 07:29, 26 October 2026 (UTC)
There are so, so many others. Consider Cinnamon Works, which really ought to be merged into Pike Place Market, but its existence has been documented in some guides and mentioned in a few RS talking about the market more generally, so obviously we need to have a standalone article on this one stall. FalconK (talk) 07:54, 26 October 2026 (UTC)
I love a good merge, but I wonder if you are hoping for a standard that requires the subject to be the main topic of the source material? A few RS talking about the subject as part of a larger subject is generally a good thing when it comes to writing an encyclopedia article (provides context, might do have compare-and-contrast secondary source material, etc.). WhatamIdoing (talk) 20:32, 26 October 2026 (UTC)
No, I am not one of those who think the subject has to be the primary subject of RS to be notable, I just think it needs more than a passing mention. The principle underlying this is, substantial coverage implies there's something to say about the topic. FalconK (talk) 02:19, 27 October 2026 (UTC)
I agree. It's why I wrote WP:WHYN all those years ago. IMO if you can cobble together a decent article with a series of short/partial sources, then great! And if you can't create a decent article from a stack of sources, then it doesn't matter how long the source is. A single dense, factual paragraph outweighs a ten-page funny anecdote.
For reference wrt "decent article", the median Wikipedia article has 350 words (13 sentences) and just four cited sources – including primary and non-independent sources. We should not expect all the articles to be above average, but I would like to see Nico (restaurant) expanded so that it's closer to the median. WhatamIdoing (talk) 18:10, 27 October 2026 (UTC)
I would not want to reopen the discussion on restaurant notability, largely because I feel this is a larger issue that the community may want to grapple with. Our project is much more expansive than any paper encyclopedia could ever be, but at the same time we collectively have a tendency to lose the forest for the trees. Notability is frequently met with winning/earning a single award or coverage in two or three sources. While we have some essays that editors should consider (such as WP:10Y and WP:PAGEDECIDE (which asks editors tho think about whether a stand alone page provides readers the clearest explaination of a topic), there is a tendency to create pages on current events and biographies; subjects that may not be covered in secondary sources and in a significant way. So, the question here about restaurant notability, and the question I asked earlier this year about NPOL, need to be addressed at the root level. --Enos733 (talk) 05:48, 26 October 2026 (UTC)
Merge template applied without initiating an AfD−What should occur next?
I count (at least) approximately 75 instances this past month of individuals applying a {{merge}}, {{merge to}}, {{merge from}} etc. to an article (and perhaps leaving a note on the talk page) which were subsequently converted (procedurally 'moved'; e.g. Wikipedia:Articles for deletion/Muzan Kibutsuji just today) by others to an AfD discussion. The recent applicable RfC explicitly states that editors can establish consensus for merging through other means of consensus forming other than AFD. There is seemingly no longer an option to simply indicate something is due for an uncontroversial merge with a template (as has traditionally been the case), a concept aptly described by Certes in this post. In theory there could be somewhere to list such pages, i.e. a requested clearly uncontroversial move one does not wish to carry out but wishes to point out needs done; ironically, we traditionally use maintenance templates for such things (which have largely been recently deprecated through interpretations of the aforementioned RfC). Deletion venues should not be used as a space to shunt things that do not necessarily need discussed. There seems to be a tenuous status quo of handling things in this manner, upon which some change is perhaps due. Of course, simply removing such templates may not be an ideal solution either. Some of the suggestions made in this TfD (viz. the creation of e.g. {{merge maybe}} and {{merge obvious}} maintenance templates) seem due to fill the perceived gap; then 'mis'-applications of said templates could simply be converted to the appropriate ones. Does anyone else have any thoughts on the matter? —Godsy(TALKCONT) 05:00, 25 October 2026 (UTC)
IMO they should be left alone to discuss whatever they want; however, the proponents of this new AFD-to-merge system say they should all be converted to AFDs.
The problem in the RFC is that it asked "Should the proposed article merge process be merged into Wikipedia:Articles for deletion?" and did not define what "the proposed article merge process" was. Some people thought that using these maintenance tags was being abolished, and only discussions without any notifications posted on affected articles could be permitted. Others thought that these maintenance tags were being permitted as per usual, and only the centralized Wikipedia:Proposed article mergers noticeboard was being shut down. Repeated attempts to clarify this were not effective, as different editors asserted opposite answers. WhatamIdoing (talk) 06:52, 25 October 2026 (UTC)
The note on the talkpage seems a key difference. A tag applied without a discussion might be hard to understand. I never found the merge/splits formerly hanging around on the article alerts to be always obvious, many simply hang around because things hang around. Templates for suggestions is an interesting idea, although those would also benefit from being linked to a talk page. CMD (talk) 07:19, 25 October 2026 (UTC)
Thanks for raising this point, Godsy. I've nominated a few pairs unofficially where FaviFake and others have kindly done the work of merging. Fixing them could be smoother and better documented if a new tag template added candidates to a relevant category. For visibility, this might be a subcat of an existing merge category or its sibling under a new parent. As for tags being hard to understand, I was thinking of obvious pairs like Akuaba and Akuaba (Adinkra symbol), or Alegrías and Alegrías (flamenco), where the article content speaks for itself, though a |reason= parameter could be useful in some cases. Certes (talk) 09:38, 25 October 2026 (UTC)
I think about half the merges I've tagged over the years are variants on "these two people are unquestionably the same, but I don't have the fifteen minutes to fix it right now, tagging it so it doesn't get forgotten".
It seems a bit unfortunate if we don't currently have a set of templates to mark those, without initiating a formal merge discussion - even though just going ahead and doing it would be uncontroversial. Andrew Gray (talk) 10:00, 25 October 2026 (UTC)
I agree. Uncontroversial 'merges' just need someone with time and energy to do the merge, and now there's no way to tag those. WhatamIdoing (talk) 19:01, 25 October 2026 (UTC)
Take it to AfD. Deletion venues should not be used as a space to shunt things that do not necessarily need discussed. Well, now it is. PARAKANYAA (talk) 15:34, 25 October 2026 (UTC)
Just after the system changed, I took a couple of obvious merges to AfD and was understandably criticised for wasting their time with needless discussion. We may need either a new system, which could be as simple as a {{merge us}} tag, or a WP:SNOW-like protocol for speedy closure at AfD as "merge is obvious". Certes (talk) 20:35, 26 October 2026 (UTC)
...or perhaps we need the old system, with {{merge from}} and {{merge to}}, only for cases which the tagger considers obvious. Any editor who agrees may then boldly merge without further discussion. Any editor who disagrees may remove the tags and start an AfD discussion proposing another outcome (which may be "keep separate; no action"). Certes (talk) 09:13, 27 October 2026 (UTC)
I do not see why Template:Merge would not be the correct alternative. I have taken a look at it and it seems fitting. If someone removes it and files an AfD, then that is de facto them disputing the merge or saying it is controversial and in need of an AfD discussion. If necessary I suppose you could add a disclaimer at the end of the template that tells editors not to remove it unless they are actually disputing the merge. –Maltazarianᚾparleyinvestigateᛅ 19:33, 26 October 2026 (UTC)
FaviFake is removing every single use of the templates and moving the articles to AfD. Katzrockso (talk) 20:36, 26 October 2026 (UTC)
Yes, right now the accepted practice is to not use Template:Merge like that, it seems, but I don't see why we wouldn't just be able to not continue doing so. –Maltazarianᚾparleyinvestigateᛅ 21:44, 26 October 2026 (UTC)
I don't know that I'd call it "accepted practice" rather than "the practice FaviFake permits" Thryduulf (talk) 22:11, 26 October 2026 (UTC)
Funny. Regardless, I'm sure FaviFake would be okay not removing those if we were to decide the best way of dealing with this is to allow Template:Merge to be used without needing an AfD. –Maltazarianᚾparleyinvestigateᛅ 23:27, 26 October 2026 (UTC)
According to FaviFake, the RfC concluded the templates had to be deprecated. Katzrockso (talk) 23:54, 26 October 2026 (UTC)
That's a reasonable solution but just seems like {{Merge to}} without the benefit of categorisation or the drawback that someone will remove the tag because they deprecate {{Merge to}}. Why not just bring back {{Merge to}} and {{Merge from}} for obvious cases only, with anyone who feels they need discussion being free to convert them to an AfD, but without the suggestion that the tags are intrinsically wrong and must be removed even if the merger is obvious? Certes (talk) 09:00, 29 October 2026 (UTC)
@Certes: I agree that would be the optimal solution. On an aside, I did not bother with categorization infastructure because I only intended it as a rough example.—Godsy(TALKCONT) 09:29, 29 October 2026 (UTC)
It might be fine? Still a small sample size but I came back from Wikibreak to see merge requests added AfD and I'm not sure it's working. SportingFlyerT·C 09:07, 29 October 2026 (UTC)
Phrasing of a notice concerning copyrights
Villarceau circles on a torus. For the bottom picture, the projection is orthogonal onto the section plane, hence the true shape of the circles appear.
This illustration was created by user:Ag2gaeh. I downloaded it, cropped it so that it shows only the second of three objects, changed it to a mirror image reversing left and right, and edited out the labels and the coordinate axes. So what I have is what is in copyright law sometimes called a derivative work. The purpose is to use it in a publication. How should I phrase the notice crediting the author and explaining the nature of the copyright license? Michael Hardy (talk) 19:13, 25 October 2026 (UTC)
True, but that page describes a variety of different situations in which one would proceed in different ways. I thought maybe someone with experience in these things would immediately know what the proper phrasing is in the particular situation that I described above. Michael Hardy (talk) 23:02, 25 October 2026 (UTC)
The journal/publication is also going to have its own rules. Have you tried https://lizenzhinweisgenerator.de/?lang=en which is linked on the Commons page? Going through its checklist and guessing a few things, it suggested something like this:
but this is not the only way to go about it (also, I might have guessed wrong about what you're doing and you're using it). Attribution is one of those 'multiple correct answers' situations: what's needed for a print publication is not the same as for a website, etc. WhatamIdoing (talk) 23:55, 25 October 2026 (UTC)
This RfC will not include a proposal to abolish ITN. Instead, if any reforms pass, a second RfC will be held on only that question three months after all questions in that RfC have closed, allowing the impact of any reforms agreed to in this RfC to be observed before that is discussed. If no reforms pass, the second RfC discussing the abolishment of ITN may commence anytime after that one closes. Please do not use any of the proposals to argue for that at this time. The workshop for the RfC can be found here.
FYI: For best results preview the Main Page sandbox in wide view (on Vector 2022), since that's what the actual Main Page is displayed in. In any case, happy we all worked on putting this together!:) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 06:25, 16 October 2026 (UTC)
Interesting. It looks good, but as an ITN editor it does make me sad to see the section be pushed down “below the fold”, so to speak. On a similar note, how will this affect MPBALANCE? It seems like we’d need to either expand TFA and DYK, or cut down on entries in ITN and OTD. I certainly hope it’s not the latter. Chorchapu (talk|edits) 11:55, 16 October 2026 (UTC)
That's kind of an unanswered question at the moment. I believe there were discussions at ITN and DYK related to this. The DYK one especially said they didn't have the ability to do more daily hooks than are already done. I think for now we should just have an imbalance, and if all goes well with the new section different ideas to fix it can be discussed. InfernoHues (talk) 13:30, 16 October 2026 (UTC)
That's a shame. At ITN we've always wanted to have more room to be able to run either more detailed RDs, more Ongoings, or something like that. If TWAFI had gone on the other side, that could have been possible while still following MPBALANCE. But with it being on the right, we are left with no opportunity to expand other sections, and an ugly, off-balance Main Page. Chorchapu (talk|edits) 13:33, 16 October 2026 (UTC)
Nothing is set in stone yet. We need to add the TWAFI to the main page, and for that we're using the placement chosen at the RfC, but its position can always be changed in a future discussion. As is often the case with new proposals, not everything is perfect in the first attempt. FaviFake (talk) 14:29, 16 October 2026 (UTC)
Also noting that the Main Page is historically skewed in terms of section widths (with the left side being 55% of the width, and the right side being 45%), and this offers us an opportunity to rebalance it. If there's support to move TWAFI on the left side after seeing how it performs in practice, it can absolutely be reconsidered! Chaotic Enby (in solidarity · talk · contribs) 15:07, 16 October 2026 (UTC)
That's good to hear. We'll just have to see how it turns out in practice. Chorchapu (talk|edits) 15:21, 16 October 2026 (UTC)
I want to make sure it's on someone's radar to also add this to Wikipedia:Main Page/Tomorrow and similar pages (e.g. the queue) given that this is week-based and not day like everything else? I think it would be good to do it before it "tomorrow" as staging.
I bring this up because /Tomorrow is used to implement cascading protection 1-day ahead of time (including for Commons images) so people can't e.g. sneak in vandalism right before midnight. Legoktm (talk) 18:03, 16 October 2026 (UTC)
@Chaotic Enby If Sunday is the start date the template should go up on the Main Page at about 00:00 18 October UTC. So you or another administrator will need to add it then. NewAccount7295 (talk) 22:52, 16 October 2026 (UTC)
Well if the goal is to have it go live at exactly midnight UTC I would suggest putting in the code ahead of time, just conditionally wrapped by a parser function. But it wasn't clear to me that was what was desired. Legoktm (talk) 23:28, 16 October 2026 (UTC)
I've added it to Wikipedia:Main Page/Tomorrow. I'm okay with putting in the code ahead of time (the condition can then safely be removed tomorrow), although it won't be in sync with the width rebalancing (a minor issue all things considered). Chaotic Enby (in solidarity · talk · contribs) 23:29, 16 October 2026 (UTC)
Pardon if this is an ignorant question, but isn't Main Page/Tomorrow the 17 Oct edition? I thought the intention was for it to go live on 18 Oct. Chorchapu (talk|edits) 23:33, 16 October 2026 (UTC)
Main Page/Tomorrow is mostly there to cascade-protect things in advance (meaning, everything transcluded on it gets automatically protected before it moves on to the Main Page). However, content on that page doesn't automatically replace the current Main Page at midnight, so there isn't a risk of AFI going live one day too soon because it was placed there before midnight UTC. In a few minutes, both the Main Page and Wikipedia:Main Page/Tomorrow will be updated automatically thanks to the templates they invoke, and the latter will have AFI alongside the rest of the 18 Oct content. Chaotic Enby (in solidarity · talk · contribs) 23:44, 16 October 2026 (UTC)
Ah, thank you very much for the explanation. I see, that it is just to preempt its posting and to protect it early. Chorchapu (talk|edits) 23:53, 16 October 2026 (UTC)
And also, the AFI article isn't the one that is protected, because that would defeat the purpose of AFI. WP:AGF is really showing here. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:26, 17 October 2026 (UTC)
Yeah. The technical reason for why it's not protected is because it will not be transcluded into the main page. FaviFake (talk) 01:27, 17 October 2026 (UTC)
AIUI {{#time:W}} will change on Mondays and not Sundays; is that what y'all want?
I checked the sandbox on as many devices/browsers as I have access to and it looks reasonable enough. This is exciting:) Legoktm (talk) 05:40, 17 October 2026 (UTC)
Great catch! I did not realize that, but yes, ISO 8601's weeks start on Monday. I think this would be fine (we might want to push back deployment by a day then?), but pinging @Chaotic Enby for their thoughts. Axolitl(talk|contribs) 05:45, 17 October 2026 (UTC)
I can't find any documentation about if {{CURRENTWEEK}} (which TWAFI currently uses for its automation) follows ISO 6801 at all. Axolitl(talk|contribs) 05:54, 17 October 2026 (UTC)
{{CURRENTWEEK}} seems to be implemented as $ts->format('W') so it would follow the same ISO 8601 week logic unless I am misreading something. taavi (talk!) 07:25, 17 October 2026 (UTC)
Nice catch! I assumed that it worked the same way as {{CURRENTDOW}} (which starts anew on Sunday and not Monday). The discrepancy is surprisingly resolved by looking at #time, which output the ISO 8601 week (W) and weekday (N), cycling from 1 to 7, alongside the {{CURRENTDOW}} weekday (w), cycling from 0 to 6.Note that these only update alongside the page cache, with a maximum interval of 3600 seconds (one hour) between updates, so they might not make for the smoothest of transitions. Not sure how often the Main Page's cache is purged? Chaotic Enby (in solidarity · talk · contribs) 14:12, 17 October 2026 (UTC)
My understanding is that there are bots/scripts that'll purge the main page at midnight, in addition to the normal cache purges that come with DYK rotation. If that was what you were asking. Legoktm (talk) 14:37, 17 October 2026 (UTC)
Where is all this information about changing the Main Page documented? FaviFake (talk) 14:39, 17 October 2026 (UTC)
@Chaotic Enby Is it specifically set to go up on the Main Page at the beginning of tomorrow? NewAccount7295 (talk) 15:08, 17 October 2026 (UTC)
For now, it's not set up to go anywhere as far as I know, but the plan is to set it up on the Main Page itself Sunday in the evening with code that activates to display it at midnight on Monday. Chaotic Enby (in solidarity · talk · contribs) 16:49, 17 October 2026 (UTC)
I think it would be best to actually delay the deployment until Monday. Looking at the AFI pages, it looks like it also starts weeks on Monday, so I think that instead of starting AFI on Sunday we should start it on Monday. Axolitl(talk|contribs) 16:20, 17 October 2026 (UTC)
(commment moved at 14:53, 19 October 2026 (UTC))
Can we please keep this thread focused on the technical implementation and instead make comments about (lack of) notification elsewhere? Legoktm (talk) 14:46, 19 October 2026 (UTC)
I just want to add my support for TWAFI being added to the Main Page. I somehow missed the RfC, but I think this is a great idea and an easy way to get casual readers interested in editing Wikipedia. The implementation might need some UI tweaks but overall congrats to the editors involved for changing such an important part of the site for the better qcne(talk) 10:35, 29 October 2026 (UTC)
I love that this is coming to the main page. However, even as a long-time editor, I think the main page should be oriented to readers more than us editors. The encyclopedia here is for the readership, after all. So, I would suggest putting this block beneath "In the news" and "On this day". the Stefen 𝕋ower 05:02, 16 October 2026 (UTC)
The position seems to be pretty set-in-stone per the RfC linked above, as that position had the most support. That isn't to say that it can't be changed, but doing so would likely involve more discussion. Axolitl(talk|contribs) 05:24, 16 October 2026 (UTC)
Hmmm, then my next suggestion is for Wikipedians to be better informed about current RfCs, but I'm not the first to whine about that.:) At any rate, I'm glad to see this coming to the main page. the Stefen 𝕋ower 05:27, 16 October 2026 (UTC)
You can subscribe to the Feedback request service to receive a notification when a new RfC about a topic you are interested is created. Alternatively, you can add {{cent}} to your watchlist. FaviFake (talk) 12:06, 16 October 2026 (UTC)
On further consideration, having read much of the RfC, and realizing a lot of nominated articles (including one I nominated) have been summarily removed from consideration, I am withdrawing my above support for this effort. Slapping the faces of many editors to build this new feature is frankly repulsive. the Stefen 𝕋ower 08:01, 16 October 2026 (UTC)
If TWAFI isn’t performing well on the main page (e.g. few new accounts are actually editing the week’s article) then its placement could always be reconsidered at a later date. Maybe after 10 weeks? Some1 (talk) 09:33, 16 October 2026 (UTC)
As the person who implemented that change, I'd like to point out that the project has few active participants, so I made practically all my changes under WP:BOLD. If anyone wants to WP:BRD my changes, feel free - we do have more than a week before we need another article. 7amiþ = reform(solidarity).__init__(t, c) 15:46, 16 October 2026 (UTC)
The issue is that the criteria is getting stricter and stricter. I understand how you feel, but the entire project shouldn't have to go because of that. This does need to be resolved though. NewAccount7295 (talk) 16:05, 16 October 2026 (UTC)
Two questions: where was the width rebalancing discussed? And, on this confectionary TWAFI specifically, why do we have a bullet point for re-ordering the already chronological history section to be chronological? Putting an encouragement at useless edits to 6 million people (I would have put the latter at errors but there is no section for TWAFI). 1brianm7 (talk) 03:04, 17 October 2026 (UTC)
For your first question: It is true that changing the balancing percentages wasn't discussed, although I think it was necessary to resolve the imbalance at least partially. Compare the current imbalance to how it looks with the old percentages, and it won't look very good.
For your second question: Good idea to add a section at Errors for this. I'm not a sysop so I can't change the wording. Axolitl(talk|contribs) 03:12, 17 October 2026 (UTC)
Whose idea even was this? I use wikipedia fairly regularly and this came out of nowhere; if there was some sort of comment period, it wasn't well displayed to the average user. Also, I have some reservations about it displacing ITN and OTD to explicitly show off a less-than-perfect article on the main page. Joseph Zadeh (talk) 02:05, 19 October 2026 (UTC)
The discussion is very, very scant in comparison to a major change on the front page visited millions of times a day. wound theology◈ 05:35, 19 October 2026 (UTC)
This was overall a bad idea. Not that creating an AFI box was a bad idea, but implementing it with very little input from the userbase in proportion to the importance of the article was a bad idea. We get notifications and such for admin requests, so why not a major change to the front page? I for one do not like that the news has been pushed down for what is ostensibly a reverse featured article. I and many other people read the news blurbs when I first log on to Wikipedia. This sort of action is why new editors feel like there is a WP:CABAL. wound theology◈ 05:39, 19 October 2026 (UTC)
We tried to implement it as close as possible to the RfC result. The closer found that consensus was to place it above ITN, so that's where we placed it. Axolitl(talk|contribs) 05:50, 19 October 2026 (UTC)
Of course, the consensus was weak for that spot. However, it seemed most logical to put it in the place that the RfC had the most support for, and then once it was there for a bit and people gave feedback, we could revisit it. Axolitl(talk|contribs) 05:53, 19 October 2026 (UTC)
There were what, 100 people or so who participated in the RfC, which includes B votes and non-voters? To change a page which receives 6 million views daily, and has 130,193 page watchers? It's just insane to me that so little input could so drastically change the very face of our project. wound theology◈ 06:46, 19 October 2026 (UTC)
The discussion was open for more than a month, and advertised on channels such as {{centralized discussion}}. However, the low participation in the discussion was acknowledged, with the closing statement specifying that the decisions reached in this RfC may be ripe for revisiting in a few months for that reason.At some point, when there just isn't as much input as we'd like in a widely advertised discussion, we have to bite the bullet and make a first change, which in turn may attract more people into a follow-up discussion on how to reposition ourselves and make adjustments to the original findings. Chaotic Enby (in solidarity · talk · contribs) 07:50, 19 October 2026 (UTC)
Again, I get a notification for administrator elections and proposals all the time, which are a routine and necessary part of the wiki's function. The fact that we can't do something similar for something far more impactful to everyday editors and daily readers is insane. wound theology◈ 08:00, 19 October 2026 (UTC)
But it did send centralized discussion notifications (not sure about watchlist notifications though)? However, these notifications were sent back in July, when the change was discussed, and the implementation lagged by a few months. Chaotic Enby (in solidarity · talk · contribs) 08:27, 19 October 2026 (UTC)
There were no watchlist notices. But TBH, would using that be overkill? Then again we are making changes to the very visible Main Page, so... Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 12:36, 19 October 2026 (UTC)
There are dozens of similarly significant changes being proposed every month. For the TWAFI proposal, every possible venue was used (including RFC, CENT, VPP, and WT:MAIN). If you are not set up to receive notifications from any of these, then we can't really do anything about it. FaviFake (talk) 08:44, 19 October 2026 (UTC)
If that is the case, then it shows a major problem with the way that editors are informed of significant changes. Clearly we have the infrastructure to do better than this. wound theology◈ 09:22, 19 October 2026 (UTC)
> every possible venue was used
The editor in question mentioned getting pings for administration elections. Clearly, not every venue was used if they didn't receive a ping for this. ~2026-55973-77 (talk) 10:28, 19 October 2026 (UTC)
They did not receive a talk page message because they were likely not subscribed to the Feedback request service for Wikipedia proposals. 99% of registered accounts couldn't care less about these changes, that's why interested editors need to opt in.
And you don't even need to subscribe to anything in order to view CENT. FaviFake (talk) 11:45, 19 October 2026 (UTC)
I was not aware the FFS even existed and I've been editing Wikipedia most of my life. Again, this just shows a major problem with the way editors are informed of significant changes. wound theology◈ 19:05, 19 October 2026 (UTC)
Thanks! Where could we have advertised it in a way that you would've noticed? FaviFake (talk) 19:13, 19 October 2026 (UTC)
When I check my watchlist, I see the following:
I don't vote in administrator elections nor do I read The Signpost, so I haven't opted-in to either of these. If there were a similar notification, something like "There is a RfC discussing a major change to the Main Page" would have caught my eye and I would have certainly participated. wound theology◈ 19:32, 19 October 2026 (UTC)
I never check my watchlist, so I never knew that there were watchlist notifications myself... 7amiþ = reform(solidarity).__init__(t, c) 19:45, 19 October 2026 (UTC)
Fascinating. I’ve never seen those - from looking, it seems like that’s because I have my language set to EN-GB instead of just EN. I should probably change that . Chorchapu (talk|edits) 19:58, 19 October 2026 (UTC)
Yes, this has been an issue for several years. FaviFake (talk) 19:58, 19 October 2026 (UTC)
Here's the problem, as I see it. A major change should be advertised in a place that gets at least about as many views as the place to be changed, so that (ideally) everyone seeing the place to be changed sees the proposed change. So... what page on Wikipedia has as many views as the Main Page (and is in scope)? 7amiþ = reform(solidarity).__init__(t, c) 19:18, 19 October 2026 (UTC)
I like being able to edit CENT too much, but, honestly, some form of curated CENT/newsletter might be nice in the "other areas of Wikipedia" section.
Certainly more useful than portals, and now there's a very prominent link to the Teahouse in the AFI section, we could remove it from that section there as well to make more space. GreenLipstickLesbian💌🧸 20:14, 19 October 2026 (UTC)
Yep, I was being a bit hyperbolic but a version of it adapted for newcomers would be best. In general, we don't want to limit the ability of editors to update CENT, but having a protected "Main Page-friendly" version of it (that admins update once the main CENT is updated, while taking care to make the descriptions more accessible to newcomers) would be a good stopgap to keep the current fluidity while preventing vandalism on the Main Page. Chaotic Enby (in solidarity · talk · contribs) 20:46, 19 October 2026 (UTC)
Really, wound theology? You started editing Wikipedia when you were nine (or younger)? —JohnFromPinckney (talk / edits) 22:45, 19 October 2026 (UTC)
Yes. I am 27 years old and made my first edits on the account Runestatue(talk·contribs) in 2008, 18 years ago, when I had just turned 9. My edits were deleted as a WP:HOAX (talking about my micronation at the time), but in reality they were actually in good faith and I just lacked WP:COMPETENCY. I have edited on various accounts since then, I stuck with this one since it was the one I was using when I turned 18 and started taking Wikipedia more seriously. wound theology◈ 23:20, 19 October 2026 (UTC)
What was your micronation called? FaviFake (talk) 23:22, 19 October 2026 (UTC)
You can find it if you dig, but I'd prefer you didn't. It's a little bit like naked baby pictures for me. I was a very weird child (and a weird teenager, and a weird adult) and most of it is supremely embarrassing to me. wound theology◈ 23:29, 19 October 2026 (UTC)
Wound theology: when visiting somebody else's user talk page, have you noticed messages like this? That's the feedback request service in action. There are two links to it in the edit summary, and two more in the text of the message, four in all - some might say that's three too many. --Redrose64🌹 (talk) 07:50, 20 October 2026 (UTC)
Nope, I have not noticed it. wound theology◈ 09:35, 20 October 2026 (UTC)
Should we take another page from our beloved explainxkcd.com and put a notice on top of the Main Page when major discussions are underway? Chaotic Enby (in solidarity · talk · contribs) 12:11, 19 October 2026 (UTC)
That would certainly have helped. Chorchapu (talk|edits) 14:38, 19 October 2026 (UTC)
Perhaps, but that banner idea itself would be a major change to the Main Page and where would you advertise its RfC? Truly a chicken and egg type of situation.Rjjiii (talk) 16:32, 19 October 2026 (UTC)
Agreed. This re-design significantly reduces my (and many others?) use of the main page. At work I could very quickly load the main page (despite work VPN servers being on the other side of the world) and right at the top see links to ongoing wars or significant events I need to have overview on. Now I have to scroll down and find links in a sea of links. But I guess for the diehard wiki editors this AFI section is important song congrats on your victory and making it worse for everyone else.Oathed (talk) 08:34, 24 October 2026 (UTC)
It's surprising that Oathed and others get so much out of ITN when it posts so little, ITN seems to average about one new blurb every other day and often goes for days without posting anything new. And many of these items are routine WP:ITN/R events while much of the novel news doesn't get covered. That's fine by several of the ITN regulars who keep asserting that ITN is not a news ticker and that reporting the news is not its function.
To keep up with the news, you'd get a lot more out of Portal:Current events. That posts about 20 news items per day which is about 40 times more than ITN. And it lists all the ongoing conflicts, elections, sporting events, etc. in a more comprehensive and systematic way than ITN.
ITN (was) the first thing that readers saw on Wikipedia, on the top right corner of the page. Many readers, like it or not from us at the project, use ITN to get their news and read more about these topics. P:CE is not as prominently displayed, being located on a different page, and is less well-known to readers. I myself didn't know about it until after I started contributing to ITN. Chorchapu (talk|edits) 19:51, 24 October 2026 (UTC)
The daily readership of Portal:Current events is about 50K. It's not clear what the readership of ITN as it's part of the main page rather than being separate. The number that glance at it after loading the main page is uncertain. But the number that engage with it by clicking through to its articles seems to be of the order of 10K, which is comparable. For example, the readership of 2026 Bangkok floods jumped from about 5K to 20K when it was posted to ITN. The readership then fell away to about 1500 before it scrolled off. ITN doesn't lead millions of readers to articles -- just a few thousand. Andrew🐉(talk) 22:22, 24 October 2026 (UTC)
Yes, even if there are some people who click through to the articles, as a comprehensive source of news it's utterly subpar,and I can't imagine very many people rely on it as their main window on the world. Not to mention that it's in contradiction to WP:NOTNEWS, which is supposed to he one our guiding principles in how to build the encyclopedia. I will probably vote to abolish ITN in the upcoming RFC, it generates far more heat than light, is a waste of editor time and resources, and won't be missed if it goes. Cheers —Amakuru (talk) 22:34, 24 October 2026 (UTC)
I completely agree. There appears to be a dividing line in Wikipedia, where people who know a lot of the inside baseball say that ITN sucks and AFI is better, while the less-engaged reader likes seeing the news and is completely blind to things like P:CE. Joseph Zadeh (talk) 05:19, 26 October 2026 (UTC)
Never saw this RfC advertised. My 2 cents is to move the ITN back to its original position. A reverse featured article taking up that much space on the Main Page is far less valuable than providing brief, informative news blurbs for readers. Spy-cicle💥Talk? 00:33, 28 October 2026 (UTC)
An RfC is likely coming at some point in the future. I suppose the biggest lesson is to advertise it more widely. Axolitl(talk|contribs) 00:42, 28 October 2026 (UTC)
When there's a TfD, we put a little notice in small print at the top of the template advertising the TfD. What if we did this with the Main Page templates when they have RfCs? It could just be a little grey note at the top or bottom linkng to the RfC, without being too obtrusive. It would allow readers to be aware of ongoing discussions affecting the Main Page, and it would also serve to advertise it to editors who don't check the likes of CENT and the FRS. Chorchapu (talk|edits) 00:49, 28 October 2026 (UTC)
I can see some advantages to doing that. GreenLipstickLesbian💌🧸 00:52, 28 October 2026 (UTC)
There's also an ITN RfC coming up, so if this sort of notice were to happen it could be used there as well. Chorchapu (talk|edits) 01:01, 28 October 2026 (UTC)
Oh, and mark my words, the RfC for ITN has just started. Chorchapu (talk|edits) 02:17, 28 October 2026 (UTC)
Also agree with a TfD-like notice on ITN for the ongoing RfC. Really like your mockup of the notice! Chaotic Enby (in solidarity · talk · contribs) 04:36, 28 October 2026 (UTC)
Ah, now I can see it! Looks good for me, too. Good solution to the "I wasn't informed" problem. BTW, anyone else getting 503s left and right? I tried to thank CE but couldn't.nvm there's a topic right at the bottom of the page. Self-trout7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 04:44, 28 October 2026 (UTC)
I messed with it a bit to make it a bit more similar to TfD notices. Axolitl(talk|contribs) 04:54, 28 October 2026 (UTC)
Yes, that looks great! Do we want to deploy it, for both the ITN mega-RfC right now and the AFI RfC in a few weeks? Chorchapu (talk|edits) 11:51, 28 October 2026 (UTC)
I think we should deploy it for the AFI RfC. NewAccount7295 (talk) 14:20, 28 October 2026 (UTC)
Why AFI but not ITN? The ITN reform RfC will (hopefully) have effects visible to the Main Page and could benefit from the input of readers. If not for this reform RfC, I think we should definitely use it for the abolition RfC in a few months if that ends up happening. Chorchapu (talk|edits) 14:24, 28 October 2026 (UTC)
If you want it can be used for the ITN RfC as well. I was just saying we should at least deploy it on the AFI one. NewAccount7295 (talk) 14:26, 28 October 2026 (UTC)
Oh yes, sorry. I misunderstood. Chorchapu (talk|edits) 14:28, 28 October 2026 (UTC)
Probably both! The change is relatively minor, and serves to get more input for broader changes, so I don't think we should be bogged down into a whole discussion to deploy it. Chaotic Enby (in solidarity · talk · contribs) 14:58, 28 October 2026 (UTC)
@Chaotic Enby Do you want to add it? There seems to be a consensus here to do so. NewAccount7295 (talk) 18:12, 28 October 2026 (UTC)
Since it appears uncontroversial, I'm willing to do it after a bit more feedback. I'm going to put a note at the RfC itself (which is also valid here) that I am operating on unopposed consensus – namely, if anyone voices opposition, they are free to ping me and I will self-revert, after which we can lead to the downfall of the Polish–Lithuanian Commonwealth hold a regular consensus discussion over it. Chaotic Enby (in solidarity · talk · contribs) 18:17, 28 October 2026 (UTC)
When comparing page views for the Main Page with even the TFA average, the clear conclusion is that if readers have been telling us anything for many years now, it's that they'd be perfectly happy if we replaced the entirety of the Main Page with a simple search box.
But a lot of contributors are here primarily for Main Page activities, and again the overwhelming number of readers don't care at all about what's on the main page, so the value question is going to be more what more encourages people to contribute. Difficult to come up with a suitable assessment criteria for that, and very little data anyway.
Aesthetically it strikes me as a little off, but that may just be because I'm not used to it yet. From a web design perspective the entire model is so dated that any assessment based on contemporary criteria will grade both options rather low. ~2026-46960-97 (talk) 16:21, 28 October 2026 (UTC)
This should not have been placed above the ITN section in my opinion. - Indefensible (talk) 18:10, 28 October 2026 (UTC)
Something I wish we could A/B test: randomly give users either ITN or AFI first, allow them to easily switch positions, and compare how many switch positions one way vs the other. Chaotic Enby (in solidarity · talk · contribs) 18:12, 28 October 2026 (UTC)
I mean no offense to anyone who got this new section onto the WP home page. But I would say pretty objectively this is both bad UX design and bad WP process that produced this result. It absolutely should be A/B tested. - Indefensible (talk) 18:15, 28 October 2026 (UTC)
I agree in part with the process part, but what about the UX is bad (other than the placement)? Axolitl(talk|contribs) 01:39, 29 October 2026 (UTC)
Preparing for a short-notice security update to our services
Hey everyone – due to a critical security advisory about the PHP language (which we depend on), many Wikimedia services are going to be affected. We are hoping to avoid downtime to the wikis, but some supporting tools and services are unfortunately going to be impacted. This is a complex operation on short notice and we are still figuring out the details. More information will come later this week. Johan (WMF) (talk) 21:55, 20 October 2026 (UTC)
Thank you for your patience as we've been dealing with this security issue. It's been a lot of hard work, for the Wikimedia technical community and the web in general.
Toolforge and Cloud VPS have been back up since last Thursday, 22 October. Many key tools the editing communities depend on have been gradually restored.
Some tools need the respective volunteer maintainers to restart them. Others still need to upgrade to a patched PHP version – some tools were using older versions of PHP which are not supported by the recent security patches, and these will require maintainers to carefully upgrade to a more recent version, which might require additional effort to make them compatible. You can follow the work on Wikitech. Johan (WMF) (talk) 15:57, 28 October 2026 (UTC)
In response to the recent PHP security advisory[0], we are temporarily disabling all network access for Toolforge and Cloud VPS pending security patches.
As security patches get deployed we plan to incrementally re-enable services. Initial efforts will be focused on securing Toolforge, but if you are 100% sure that your project uses no PHP please contact us
directly and we’ll put you on the short list.
This is likely to be a prolonged outage which will depend on a lot of coordination with project and tool admins. This is not ideal, but is the best option among those currently available.
Well, this answers some of the questions that drew me to this page. Please keep the communication open and alert us to any progress made or obstacles that come up. Thank you. LizRead!Talk! 00:12, 21 October 2026 (UTC)
Miraheze has taken their entire wiki farm offline. Obsidian the Fox 03:33, 21 October 2026 (UTC)
Well, shucks. That's why PetScan wasn't wanting to load. I hope they take the time that's necessary to do a patch; I'm glad they're being cautious. EatingCarBatteries(contribs|talk) 04:15, 21 October 2026 (UTC)
An update outlining the work to bring back affected tools, from the teams working on this (I'm merely passing it on):
For people following along: We have a two-pronged approach to getting services back up.
Toolforge:
We're working on making the Toolforge build service smart enough to block launching of PHP tools so that we can start launching non-php things safely. Next, we'll figure out what to do about tools that rely on unfixed/unfixable PHP versions. We hope to have partial (php-free) Toolforge functionality restored sometime in the next 24 hours.
Cloud-VPS:
We're currently focusing on projects maintained by WMF staff and/or NDA users, since we have more flexibility to adjust those projects to our current safety standards. Our team is auditing projects one by one with the goal of starting up those projects that don't use PHP at all ASAP. After that we'll look at patching projects that use PHP in some form - we'll do so to the best of our ability and understanding of each project, with a focus on security rather than fully enabled functionality at first - and after that we will face up to the projects that rely on unfixed PHP versions. This whole process will likely take a few days for most projects which have a simpler path to safety, and a few weeks for the most complex ones. We might start contacting some maintainers for support as we start working on their projects.
Both:
It's worth noting that while we're still focused on the wider platform functionality, we're hoping to use your input on specific tools at some point, so thank you to everyone who has been contributing to the talk page[0].
All of these timelines should be interpreted very loosely -- any new surprises will delay things. We appreciate your continued understanding and support as the WMCS admins continue to work diligently to bring as much as possible back up as quickly and safely as possible.
We are happy to announce that Toolforge is available again for users.
We don't have yet images with patched php or have updated the buildpacks to be able to build images with php, but non-php jobs and webservices are free to run once again.
We will update as soon as possible once we have patched images for webservice and can allow build service images that use php back, but until then, please refrain from trying to work around the guardrails we have put in place.
There might be other things still not working completely, as not all CloudVPS is online yet, but please reach out with any issues you find and we'll try to help get you unblocked, though please be patient as we are still working on bringing some of the system online.
Our availability across timezones is also limited, and we're trying to make sure the team can get some rest in between all the effort we're applying, so any and all questions can take a while to get back to.
Thanks you very much for your patience and your effort, it's really appreciated.
That page is also down as of the time of writing. – MrPersonHumanGuy(talk) 15:45, 21 October 2026 (UTC)
The wikis were temporarily affected by related maintenance work, but the link above should remain the best place for updates about which tools remain offline and which have been fixed. Johan (WMF) (talk) 18:14, 21 October 2026 (UTC)
I'm assuming that it's still down, perhaps? Tried to visit these links:
but it reports an error about the services being unable to be reached, and telling me to contact a maintainer, without stating who a maintainer is in this instance (but including instructions for maintainers):
Error
This web service cannot be reached. Please contact a maintainer of this project.
Same for WP:TWL. Now all we get is a connection timed out error. ミラP@Miraclepine 03:50, 21 October 2026 (UTC)
WP:TWL is part of Cloud VPS. Since it's not written in PHP it should be back online sooner than most tools ... * Pppery *it has begun... 04:13, 21 October 2026 (UTC)
Yes. I confirmed that it is down intentionally, then added it to the Wikitech page. –Novem Linguae (talk) 13:15, 21 October 2026 (UTC)
It has now been restored, as have Phabricator, Translatewiki and GitLab. Johan (WMF) (talk) 18:10, 21 October 2026 (UTC)
Context
for those who are seeing this and don't immediately know what it's about: two vulnerabilities have been found in PHP versions up to the latest, and they're really really badGnomingstuff (talk) 06:30, 21 October 2026 (UTC)
and for the very beginners, PHP is the absolute essential foundation software Wikipedia needs to run. The whole of Wikipedia cannot operate without PHP. MilkyDefer 07:26, 21 October 2026 (UTC)
It is also the "php" in en.wikipedia.org/w/index.php?. LightNightLights (talk • contribs) 08:08, 21 October 2026 (UTC)
I assume that this is connected to German Wikipedia being down right now? RIght now it gives "Error: Please try again later (a607b0e)" when I try to access any pages. Chorchapu (talk|edits) 15:19, 21 October 2026 (UTC)
Many others, too, eg. nl.wiki and et.wiki.
Also just noticed that many images aren't displaying on en.wiki, although when you click through to Commons, they seem fine there. Presumably that's somehow part of this. -- DoubleGrazing (talk) 15:23, 21 October 2026 (UTC)
ZHwiki also went down, I saw, but it looks like they've all just gone back up. Chorchapu (talk|edits) 15:25, 21 October 2026 (UTC)
Down for me. But this is expected, they will selectively allow certain blocks of IPs to work (sites, services), check logs if any exploits come in, move on to the next. -- GreenC 15:59, 21 October 2026 (UTC)
I see also that image issue now. It looks like it's just previews - when reading the articles the thumbnails seem to load just fine, but when I click into the preview it goes black. Then, on Commons the preview also doesn't load but the image does. Chorchapu (talk|edits) 15:38, 21 October 2026 (UTC)
Some maintenance work briefly affected the wikis, yes. We have updated our related Diff post to acknowledge this. Johan (WMF) (talk) 18:09, 21 October 2026 (UTC)
All my non-PHP tools on toolforge required a webservice restart to get rid of that error. Refill looks like it's node.js based, so Novem Linguae probably just has to give it a good kick to get it running again. --Ahecht (TALK PAGE) 21:51, 22 October 2026 (UTC)
It uses a php image, with vue.js as the front end framework. Ill try a restart when im back at a computer –Novem Linguae (talk) 02:29, 23 October 2026 (UTC)
Restart didn't work. I think Toolforge is up but PHP is still down. Details of what I tried at phab:T441973#12464513. Will try again another time. –Novem Linguae (talk) 05:47, 23 October 2026 (UTC)
Even though Toolforge is back up, for the most part, AIUI the owners of each tool/bot still need to update their individual tool to get it working again. Chorchapu (talk|edits) 22:23, 22 October 2026 (UTC)
For non-PHP tools nothing needs to be done other than a restart. For PHP tools, if they're using a patchable version it should be similar once WMCS updates the images over the next few days, but otherwise tool owners will need to update their scripts to support a more modern version of PHP. That being said, for non-PHP tools, this is a good opportunity for tool owners to update them to the latest versions of their languages. --Ahecht (TALK PAGE) 23:41, 22 October 2026 (UTC)
OK thanks - didn't even think the PHP issue would affect this! GiantSnowman 08:11, 23 October 2026 (UTC)
It's up now. I put in a temporary non-PHP server for the static files. – SD0001 (talk) 10:47, 23 October 2026 (UTC)
The Excel-to-Wikitable tool on Toolforge is still down. When I copy a spreadsheet into the tool, it says no healthy upstream. Do I need to ask the owner of the tool when it will be available, or can that question be answered? Robert McClenon (talk) 05:18, 23 October 2026 (UTC)
I think Toolforge PHP is still disabled. We should circle back to this when the cloud-announce mailing list says that safe PHP versions on Toolforge have been restored. –Novem Linguae (talk) 05:50, 23 October 2026 (UTC)
I am the owner of a tool. That tool also says no healthy upstream. If you asked me when it will be available I wouldn't know the answer. I think owners are meant to add the tool to this list. I think that has already happened for Excel2Wiki Sean.hoyland (talk) 05:53, 23 October 2026 (UTC)
...apparently owners can now manually restart non-PHP tools themselves. Sean.hoyland (talk) 05:57, 23 October 2026 (UTC)
@Robert McClenon: excel2wiki is written in PHP, so I'm waiting on the new PHP images to be made available on Toolforge before I can re-enable it. --Ahecht (TALK PAGE) 14:12, 23 October 2026 (UTC)
It's back up, and I took the opportunity to rewrite it entirely in Javascript so there's no server-side processing or dependency on PHP. --Ahecht (TALK PAGE) 21:24, 23 October 2026 (UTC)
Comment on excel2wiki
As User:Ahecht notes, the tool has been rewritten. There is no longer a button to push to request the conversion. The conversion happens immediately on pasting the spreadsheet into the space. This is good, but is a surprise. Existing links to the tool work, but existing pages of the tool do not work, and must be relaunched from links. Thank you. Robert McClenon (talk) 23:29, 23 October 2026 (UTC)
I'm a big user of the Wikipedia Library wikipedialibrary.wmflabs.org which is not available currently. Same problem? Any timeline to fix it? Thanks.Bob (talk) 20:13, 23 October 2026 (UTC)
I've restarted it. Should be up now. cc @Mike Christie. – SD0001 (talk) 11:26, 24 October 2026 (UTC)
Thanks; I've been away from the PC I use to access toolforge this week so could not do it myself. Mike Christie (talk - contribs - library) 11:40, 24 October 2026 (UTC)
gitlab.wikimedia.org/toolforge-repos
I am unable to git push to gitlab.wikimedia.org/toolforge-repos. I am getting a "ssh: connect to host gitlab.wikimedia.org port 22: Operation timed out" Hawkeye7(discuss) 23:32, 27 October 2026 (UTC)
Incorrectly shown difference between revisions on mobile
See this diff and select mobile view (this is on Wiktionary). From Line 88 onwards, it doesn't show that I moved the * {{pedia}} part (no yellow or blue highlighting) under a new heading, it shows two unaltered * {{pedia}}. There is also an extra space after both headings. Is this normal behaviour? Aloysius Jr (talk) 10:18, 23 October 2026 (UTC)
@Aloysius Jr: It's a bug I reported in March in phab:T419530. There are supposed to be curved arrows where you moved * {{pedia}} from and to. The arrows appear in desktop view but not in mobile. The necessary indicators to make the arrows are there so it could be fixed locally in wikt:MediaWiki:Minerva.css with the code I posted at Phabricator. There may still be many users who don't notice the arrows or understand their meaning but it would help. Maybe we should also add my fix to our own MediaWiki:Minerva.css when Phabrictor shows no sign of work. PrimeHunter (talk) 12:05, 23 October 2026 (UTC)
You have to select "Inline" in the desktop diff to see how mobile should have looked. Here is a local example where {{norse-myth-stub}} was moved down. I personally see the arrows in mobile because I added this to Special:MyPage/minerva.css:
You have my gratitude! Aloysius Jr (talk) 21:15, 23 October 2026 (UTC)
Semantic search experiment on web
Hi all,
We’re sharing this update to let you know about the Reader Growth team’s upcoming experiment to test out bringing semantic search capabilities to the web version of Wikipedia. This is part of our cross-platform initiative to make finding information easier on the wikis.
Semantic search, or natural language search, means retrieving information based on the meaning, concepts, or contextual relationships of someone’s query. Currently Wikipedia search does not support semantic search, and instead fully relies on lexical retrieval, which is based on exact search terms, or keyword matching.
With the increased usage of AI summaries or chatbot answers, people are less likely to click through to the Wikipedia article in their search results.
4–7% of all search queries on Wikipedia are phrased as natural language questions (e.g. “What”, “Who”, “How”), even as people do searches in natural language more and more over time. We suspect this is because question-style searches like "Who invented planes?” or queries such as “Biggest city in South America” are significantly less successful at leading users to the right article compared to simple keyword-based searches.
The left screenshot illustrates the current experience of searching on Wikipedia mobile for "who invented airplanes." The screenshot on the right shows the experience asking the same question in the experimental semantic search treatment.
Many readers currently default to external search engines or AI-powered tools to reach Wikipedia content, or even to get synthesized answers based on Wikipedia rather than starting their search here. With pageviews to Wikipedia on the decline, we have fewer readers to become invested in the platform and contribute to it. If we improve our on-platform search, we hope to encourage people to treat Wikipedia as a knowledge destination they visit directly. Making it easier for readers to find information during their first visits helps them experience Wikipedia as a place for discovery rather than just a background knowledge source reached through others.
What we found on the apps:
This summer, the Apps team ran an experiment with adding semantic, or natural language, results to search, which were surfaced alongside traditional keyword results in a beta feature mode. Their experiment yielded 3.6 million search sessions from more than 300,000 readers, the first real evidence we now have of how people search Wikipedia when meaning-based results are available to them. They found that adding semantic results raised search engagement by 6.9–7.9% consistently across all four pilot Wikipedias, without harming overall app retention. Based on these promising results, we are ready to kick off experimentation on the web, alongside continuing explorations on the apps.
How web is different:
The apps and the web are different digital spaces. On the apps, search is already highly utilized. As mentioned above, internal search accounts for under 2% of pageviews on web, so a better web search experience will be limited in impact until readers can find the search in the first place. That is a discoverability problem as much as a retrieval one, and it needs its own work (coming soon). We will be brainstorming in this space and encourage you to share your ideas and thoughts with us.
However, there is progress that can be made now on the web. In parallel with the app experiments, we will make semantic search retrieval available to a sample of readers in a test so that we can start seeing how web readers react to semantic search.
How the experiment will work:
We are planning an A/B test on desktop and mobile web for 1% of English Wikipedia in mid November, allowing us to see how web readers react to semantic search results.
The test's primary success metric will be whether readers use search more after interacting with the semantic search results. We will also track whether readers are more likely to come back to Wikipedia after trying semantic search, as well as qualitative feedback that readers give about semantic search results.
The test will be turned off in mid December. If early results are successful based on this criteria, we hope to return here and discuss a limited rollout for December.
This test will be shown to readers typing in the search bar, who will see the existing "Search for pages containing..." call to action (CTA) as usual below the typeahead suggestions. Clicking that CTA or hitting enter on their query will take readers in the test's treatment group to an advanced search results page that will include semantic results.
Please check it out if you’re interested in learning more. We would love to hear thoughts and feedback from you, particularly around risks and edge cases. EBlackorby-WMF (talk) 20:25, 23 October 2026 (UTC)
Is there a way to disable this if I actually want to search for specific terms in articles? If I click thumbs down to "are these results useful" will that make them go away, or will it just be logged in a database somewhere? --Ahecht (TALK PAGE) 21:32, 23 October 2026 (UTC)
Hi @Ahecht, good question! During the test, the usual lexical results will be available under the semantic results, and there will also be a link back into Special:Search at the bottom of the page. EBlackorby-WMF (talk) 16:01, 26 October 2026 (UTC)
I also hope the ability to limit searches to keyword-based is maintained, as these can be useful for editing (eg. finding places a wikilink might help). However, thank you for the statistics on natural language searches. Is it possible to somehow opt-in and test semantic searches ourselves? CMD (talk) 23:13, 23 October 2026 (UTC)
@Chipmunkdavis, thanks for the note. We are definitely conscious of the need to maintain a high-powered keyword-based search, so noted on that request.
For testing, we don't yet have a way to test now but we will share the URL param for the treatment when we go live here on this post. EBlackorby-WMF (talk) 16:06, 26 October 2026 (UTC)
I think it would be good to have both options: the semantic search for readers to find information to answer their questions, and the keyword/filter search for power users and editors to find pages with precise criteria.
As for sharing the URL parameter, I'm not sure what your current practice is, but to ensure that your data is statistically representative, I would recommend distinguishing between the users who are given the treatment randomly, and those who purposefully go to test it, especially since they're likely to have different usage patterns.
Navigation templates break the "What links here" tool
When someone clicks Special:WhatLinksHere from the sidebar of a Wikipedia article, they expect to find the pages which link to the page, or one of its redirects. But, for many pages, what they get instead is mostly noise consisting of all pages transcluding some navigation template, among which the actual inbound wikilinks are hiding and difficult to find. In my opinion this is a serious bug which makes the "What links here" tool cumbersome and frustrating to use for many pages, sometimes to the point that it is basically unusable.
Instead, the "What links here" page should only show linking pages for which the link is directly contained in the source, excluding the content of template transclusions where the template directly contained the wikilink. The template itself should show up in the "What links here" list, but we don't need dozens to hundreds of list items for a single inbound link defined in a template.
This should not affect links generated by other types of template. (E.g. if someone uses the {{slink}} template to link to a section, that should not be excluded).
(The example that came up recently was a new user complaining that they couldn't easily find the articles linking to Intersecting chords theorem because it is included in the navigation footer template Template:Ancient Greek mathematics, which is transcluded by hundreds of pages.) –jacobolus(t) 17:32, 24 October 2026 (UTC)
While we're here, it would also be extremely helpful if the "What links here" tool would separate inbound links pointed at specific sections of the linked-to page, and explicitly show which anchor each inbound link was pointed at. –jacobolus(t) 17:36, 24 October 2026 (UTC)
Update: After running a search, I see that people have been complaining about this over and over again since 2004. Here's a partial list of past complaints/requests about this issue:
This has been a known problem for longer than I've been editing navboxes (1 August 2009). --Redrose64🌹 (talk) 18:15, 24 October 2026 (UTC)
Yeah, hee's a complaint from 2004. Among dozens if not hundreds of others since then. It's absurd that this has never been fixed, since it is obvious to everyone that it fundamentally breaks the "What links here" tool. –jacobolus(t) 18:24, 24 October 2026 (UTC)
The links table does not distinguish between links that come directly from the wikitext for the page and those that come via templates. This is because the links table is updated after all templates have been expanded, and so are essentially part of the final wikitext. But consider also that links may also be made by templates that are not navboxes - for example I might put {{tlx|not done}} which makes a link - is that link due to the template, or due to the wikitext of this page? In short, how would the links table generator know the difference? --Redrose64🌹 (talk) 18:55, 24 October 2026 (UTC)
Templates such as navboxes which always include a specific wikilink as part of their output are clearly different from templates which generate a wikilink based on their inputs, and should not be treated the same way.
One possibility would be to have some kind of dedicated marker for templates such as navboxes (a start could even be as simple as flagging any template built on top of {{Navbox}}) which causes them to be excluded by whatever process is building and analyzing pages to compute the link tree. –jacobolus(t) 19:50, 24 October 2026 (UTC)
How about a hybrid approach, similar to what we currently do for redirects? This might be more complicated to implement, though, since the target page can be variable.
Template:Section link
[usages that result in a link to the page in question]
This should not affect links generated by other types of template. (E.g. if someone uses the {{slink}} template to link to a section, that should not be excluded). Already you're realizing why "fixing" this would be more difficult than it seems. Anomie⚔ 18:58, 24 October 2026 (UTC)
It may be difficult to fix, but the current state, since the beginning of Wikipedia, has been profoundly broken. It's ridiculous for Mediawiki developers to just mark this as WONTFIX and the let thousands of people repeatedly hit the same catastrophic bug over and over again until the end of time. –jacobolus(t) 19:44, 24 October 2026 (UTC)
Meh, I mean, it's not necessarily trivial, but I assume there's an HTML class used by most navboxes; exclude links coming from that (or make a new class), or preferably a box to tick as an option of whether to include them or not.
Yes, the tree view mentioned in Meta:Community_Wishlist/W185 would be more complicated to implement, but I suspect that simpler fix would cover most people's concerns. LittlePuppers (talk) 19:52, 24 October 2026 (UTC)
Although not a navigation template (but another form of template), this is the exact reason why using the IMDb template on actresses links to IMDb (identifier) which in turn redirects to IMDb. Same with good articles when clicking on the green circle on the top right; it leads to Wikipedia:Good articles* (with an asterisk at the end) rather than just Wikipedia:Good articles. And then you have links to periodicals like The Guardian often using a citation template, but it would break the 'what links here' feature if one isn't used. But anyway, I do agree that the feature shouldn't include links from navigation templates, but its just quite difficult to implement. Because of that, I'm surprised it isnt currently listed at Wikipedia:Perennial proposalsJuniperChill (talk) 10:22, 26 October 2026 (UTC)
I'm apparently unable to edit from my user account
I am User:IGAEB. Something appears to be wrong with my account, and I don't know what the situation is. I log in, then whenever I make an edit, it says I'm logged out. It then posts my edit as an edit from a temporary account, as it has done here. Whenever I try to edit protected pages, it says I can't do it because I'm not logged in (even though I am an extended confirmed editor). One WP how to page said that it might work if I cleared my cookies, but I did that and the problem persists. And, this is not just my computer -- the same thing has happened when I attempt to make edits from many computers. Often, when I edit, it says, "You are centrally logged in as IGAEB. Reload the page to apply your user settings." But, when I refresh the page, it does the same thing. How do I edit from my account? What it the problem, and how do I fix it? ~2026-56871-02 (talk) 20:04, 24 October 2026 (UTC)
When I click "Edit source" it says I am still logged in. But then, when I click "publish changes" it says I'm logged out. I did log in and then went to Special:Preferences#mw-prefsection-rendering and I selected "Always enable safe mode." But then, after I clicked "save" on that page it again said I was logged out again. So, apparently, this is a Catch-22. I can't select "Always enable safe mode." Nothing like this has ever happened to me on Wikipedia before. It started happening two nights ago (Thursday). Then, on Friday, I was again able to edit under my user account. But then on Friday afternoon, I was again unable to edit from my user account. This morning (Saturday morning) I could at first edit from my user account. But, later today, I couldn't edit from my user account.
This all started just after I made an edit to Wiktionary. I don't know if that did something to cause this, but I'd like to be able to again edit from User:IGAEB. An admin said I wasn't blocked, so I don't know what the problem is.
But now a new problem has arisen. I tried to post this comment using a temporary account. But it said it couldn’t create a temporary account due to throttling. So, I created this new account just so I could post this comment. I believe that this is a legitimate use of an alternative account, but I would really like my old account back so I could just stick with one account. IGAEB2 (talk) 22:04, 24 October 2026 (UTC)
Safemode is automatically enabled while you are at Special:Preferences so if it happens there then I guess it wouldn't help to always enable safemode. PrimeHunter (talk) 23:42, 24 October 2026 (UTC)
Then what do I do? IGAEB2 (talk) 23:57, 24 October 2026 (UTC)
They don't have any user scripts. --Ahecht (TALK PAGE) 12:36, 26 October 2026 (UTC)
I just successfully made an edit; I made this edit. So apparently my editing ability has been restored. I'm not sure this will continue, however; in the past few days, I have made some edits, and then later on I was unable to do so. IGAEB (talk) 02:30, 28 October 2026 (UTC)
However, a few minutes after I made the above mentioned edit, it wouldn't let me make any more edits. Every time I would try to edit, a message would pop up saying something like "Server error HTTP 503 forbidden." It wouldn't let me log out either, when I would try to log out, it would also say Server error HTTP 503 forbidden. But, when I closed the page, it did log me out. But I still couldn't make edits while logged out; even while logged out, when I tried to edit with a temporary account, it also said Server error HTTP 503 forbidden. Then, I tried to log in under my makeshift alternative account, User:IGAEB2. When I tried to edit from that account, it still said Server error HTTP 503 forbidden. But, if this post gets posted, it will show that I can edit now.
I've not had this happen before. Does anyone know what might be causing this, and how I can stop it from happening in the future? IGAEB (talk) 13:28, 28 October 2026 (UTC)
Since you may not be able to make edits even after switching accounts, it sounds like a device issue. Have you tried doing your edits on another device and/or internet connection?
If you can edit from your phone but not your computer it's likely your device.
If you can't edit from both your computer and phone, and both are connected to the same Wi-Fi network, then it's likely your network's firewall is blocking Wikipedia.
I was able to edit from my cell phone this morning (although I have had trouble editing from my cell phone in the recent past. I'm on my desktop now, and if this post gets published, it will show that I can edit from my desktop. But, to keep this from happening in the future, how do I whitelist a website? IGAEB (talk) 00:24, 29 October 2026 (UTC)
Could you making a few more edits (preferably 5 each) on both devices to see if the 503 forbidden issue stops? (You can use your sandbox for doing dummy edits) Adding a whitelist to your network can be complicated especially if it requires changing settings on your router/modem and the steps differ wildly between manufacturers. Whitelisting on your devices (which is easier) may help, but I don't believe it's an issue with your phone/computer. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:44, 29 October 2026 (UTC)
I just made five dummy edits from my desktop, and five dummy edits from my mobile device. No trouble.
I don't know whether the problem has to do with a network. But here's what I do know: My desktop is not connected to Wi-Fi, it's connected to a land line. And this morning, I made my mobile edits from the local courthouse. Just now I made my five mobile edits from the same place where my desktop is. IGAEB (talk) 00:55, 29 October 2026 (UTC)
Interesting. I'm unable to assist further though since you're using a landline, sorry! Regardless, it looks like you've (temporarily) fixed the issue. If you continue to face any other issues I would let other volunteers assist you. Happy editing! Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:11, 29 October 2026 (UTC)
If you continue to have these issues, please note the exact languge of the error, even a screenshot will do, and create a task in https://phabricator.wikimedia.org/ giving as much detail as you can, including the error message. (Your IP address should not be in there, but if it is, obscure that.) If by any chance there is an email address given in the error message to report problems, do that instead. I would send you to bot-traffic per https://wikitech.wikimedia.org/wiki/Bot_traffic but it doesn't sound like you are doing anything that approaches bot behaviour. ArielGlenn (talk) 05:23, 29 October 2026 (UTC)
"File missing" in recent uploads
Initially noticed at Commons (see c:Commons:Village pump/Technical §"No file by this name exists") but also present for local uploads here, so probably a general Mediawiki issue; and I'm also reporting this issue here, as local audience is usually more active than at Commons.
If you go to the Gallery of new files and search for "File missing", you will notice several files that are "missing" but (temporarily) reappear if their description page is purged. Somebody with access to technical information, please see what happens with such files and create a ticket at Phabricator (I don't have enough information and reproducibility to do this myself). — Mikhail Ryazanov (talk) 22:13, 24 October 2026 (UTC)
I was just about to ask about this myself. Yesterday I uploaded File:NZ Outdoors and Freedom Party logo.png. The description page says "No file by this name exists...", but it's showing up fine on the NZ Outdoors & Freedom Party page. I uploaded a replacement image, and that seemed to fix it briefly, but now it's back to saying it doesn't exist on the description page.-Radicuil (talk) 22:57, 25 October 2026 (UTC)
Could some of you experts please take a look at this recent edit to this article. It's already a Rated C article but this anon sort-of added +53,289 bytes of content without any explanation. I think it's all the same as a previous version, but did they just re-jigger the content and move sections around? They also today changed {{Use mdy dates|date=December 2022}} to {{Use mdy dates|date=October 2015}}. - Shearonink (talk) 01:27, 26 October 2026 (UTC)
Looks like they copypasted a previous version onto the current one. Not sure what the policy here is. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 02:12, 26 October 2026 (UTC)
Another editor has removed the duplicated content. I suppose originally the duplicated content was just a mistake. There also doesn't seem to be a good reason to have changed the 2022 date to 2015, so I changed that back to 2022. - Shearonink (talk) 04:06, 26 October 2026 (UTC)
When receiving a large number of notifications, only 25 are shown when I click the "Your notices" tab
An example: I can only see 25 of 48 notifications (screenshot taken 24 September 2026)
I'm sure this has been brought up before but I can't seem to find it from searching this page's archives. Say, I receive 40 notifications from 5 discussions, 8 replies in each. I will only see 25 of these, and replies from each discussion aren't able to be selected all at once. I have to tediously read the replies from, for example while I was sleeping, in little bits and pieces. This is very annoying and makes following lengthy discussions very difficult. Is this a known issue, and how can it be fixed? Chorchapu (talk|edits) 17:15, 26 October 2026 (UTC)
If you want to see more than 25 just click on the "All notifications" at the bottom left. KylieTastic (talk) 19:21, 26 October 2026 (UTC)
I know that, but then I can’t click to see them in groups. I have to read them one by one, and that’s really impractical for long discussions. Chorchapu (talk|edits) 19:22, 26 October 2026 (UTC)
This also annoys me and I was sure there had to be existing issues or old discussions. (AI disclaimer/warning) I got ChatGPT to look for issues; the two most relevant seem to be T317365(Change maximum unread notifications allowed in notification tray dropdown from 25 to 200) and T145250(Consider requesting more notifications if the popup only has bundles) (opened ten years ago!). —ClaudineChionh (she/her · talk · email) 20:06, 26 October 2026 (UTC)
Yes, those I believe are the problem I’m experiencing. Thanks very much for finding them. I do note that Community Wish intake is open right now; if this is a problem that many people seem to be experiencing I may submit a wish on this topic. Chorchapu (talk|edits) 20:21, 26 October 2026 (UTC)
If you submit a wish I'd vote for it and I don't think I'd be alone in that. —ClaudineChionh (she/her · talk · email) 20:27, 26 October 2026 (UTC)
It sounds like there’s support for such a wish. I’ll see about submitting it once I get home. Chorchapu (talk|edits) 20:43, 26 October 2026 (UTC)
There is a pink banner at WP:Request an account marking the service as down. I learned of this from this discussion by a TA asking for help with an IP range block who tried but was unable to use the service. Mathglot (talk) 18:02, 26 October 2026 (UTC)
Oops; thanks. I guess this can be merged as another subsection. Meanwhile, is there one best resource to monitor to watch the response, given that Phab is down also? Mathglot (talk) 18:24, 26 October 2026 (UTC)
Thanks. Clarification: by "it", you mean Phabricator; WP:Request an account is still down. A propos of that: is an admin able to create an account without recourse to that service, so that this TA user could exceptionally get an account by going through a manual process with a particular admin, rather than through the service? Or do admins use that service as well to create accounts? Mathglot (talk) 18:47, 26 October 2026 (UTC)
@Mathglot Anyone can use Special:CreateAccount to create an account for others (just check the box to email a temporary password). You just need to be an admin, account creator, or event coordinator to do more than 6 in 24 hours. --Ahecht (TALK PAGE) 18:59, 26 October 2026 (UTC)
Great; thanks! Mathglot (talk) 02:17, 27 October 2026 (UTC)
Tech News: 2026-44
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
An experiment launched on September 29 is testing article recommendations for new account holders who also identify as readers. By suggesting articles to read, similar to recommendations in the Wikipedia app for logged-in readers, the experiment aims to encourage new account holders to read and return to the website regularly, with the goal of increasing internal referrals by 1%. See the related Community Wishlist proposal.
Several Wikimedia services were taken offline last week because of a security vulnerability in PHP. This is because they need to be updated before they are safe to put back online. This is not a problem just for the Wikimedia movement but affects a lot of websites. You can follow updates on Wikitech. Cloud VPS and Toolforge will take longer to bring back online. This is to make sure that applications which run on Cloud VPS or Toolforge are not affected. Tool developers can see updates and more information on the Cloud-announce mailing list.
Last week we shared that to measure the impact of incorporating some community-requested features on logged-out reader retention, a test for the Image Carousel feature would be pushed to logged-out readers. Due to an issue, we will be restarting the test, but it will be live on October 26, not November 20 as initially announced.
Updates for editors
A new bot detection system to better identify automated traffic that disguises itself as human visitors, is coming to the Wikimedia wikis. This might cause sudden changes to visitor statistics starting from 26 October, going back to 20 June 2026.
The Score extension which renders musical notation inside wiki pages, has been temporarily disabled on all wikis due to a security issue. Affected pages will display a notice instead of musical scores, but the underlying code remains intact. No action is needed from editors, and a fix is in progress. A separate announcement will follow when the extension is re-enabled. Read more on Phabricator.
View all 18 community-submitted tasks that were resolved last week. For example, the issue where CodeMirror syntax highlighter appears to have been enabled in error for existing editors has been fixed.
Updates for technical contributors
All wikis will be read-only for a few minutes on Wednesday, October 28 2026 at 15:00 UTC. This is for the datacenter server switchover backup tests, which happen twice a year. During the switchover, all Wikimedia website traffic is shifted from one primary data center to the backup data center to test availability and prevent service disruption even in emergencies.
Scholarship and sponsorship applications for the 2027 Wikimedia Hackathon will close on Friday, October 30th. Submit your application through Pretix before the deadline!
Reference #54 is a single ref# with Harv warnings for 8 of its 12 cites with "There is no link pointing to this citation. The anchor is named CITEREF" notices. Why? I can't figure out how to fix it so the article won't be in Category:Harv and Sfn no-target errors. Help appreciated with the warnings - trying to work on the orphaned Harv/Sfn errors of Nittle 2023 & Rivers 2017 in the meantime. Thanks - Shearonink (talk) 22:44, 26 October 2026 (UTC)
Did you mean reference #154? For those eight, did you try setting |ref=none? Have we not talked about this same issue before? Where are you seeing anchors named only 'CITEREF'? For references 133 (Nittle 2023) and 134 (Rivers 2017) there are no matching long-form references.
Yes, I do run into this issue occasionally it is true. And sometimes I can fix it and sometimes the exact issue escapes me. Thanks for the hint, though, greatly appreciated. Already took care of the Harv errors, yes I know they did not have a complete citation to target. Had to run down the full source for the citation to fix the problem. - Shearonink (talk) 23:14, 26 October 2026 (UTC)
The CITEREF/Harv warnings only show up when the page is in editing mode. - Shearonink (talk) 23:19, 26 October 2026 (UTC)
I'm not sure that I believe that. When I look at this version of the article, reference 154 shows the eight warnings and references references 133 and 134 show the error messages. 'Editing mode', whatever that is, is not special.
You did not answer may question: Where are you seeing anchors named only 'CITEREF'?
I didn't answer your question? I was giving an example of what the notices for the 8 refs had in common, but seeing as there's been some misunderstanding - here are the complete notices as they appeared before I "ref=none'd" them:
For the Susan Haigh cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFHaigh2024
For the Savannah Taylor cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFTaylor
For the D. Mariah cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFMariah2024.
For the Constance Grady cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFGrady2022.
For the Caché McClay cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFMcClay2024.
For the Mesfin Fekadu cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFekadu2019
For the Caspar Llewellyn Smith cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFSmith2009.
For the Taylor Bryant cite... Harv warning: There is no link pointing to this citation. The anchor is named CITEREFBryant2019.
There you go. - Shearonink (talk) 03:28, 27 October 2026 (UTC)
@Shearonink: These are warnings, not errors. They don't show up to logged-out users, and only show up to logged-in users who have certain preferences set. No action is required. If you want more detail, all that these warnings mean is that there are some {{Cite news}}/{{Cite magazine}}/{{Cite web}}/{{Cite news}} templates but there are no {{harvnb}}/{{sfn}} templates having the same surnames and year. This is not an issue. It would only be an issue if the article was set up to use WP:CITESHORT exclusively, like NBR 224 and 420 Classes, where it would highlight the inconsistent use of a long-form ref. However, by making this edit, you have suppressed the warnings, even for those without the appropriate settings. --Redrose64🌹 (talk) 09:10, 27 October 2026 (UTC)
Yeah, I know they're not Errors, they're just warnings. Clearing up Harv errors & warnings is just my particular wiki-gnoming contribution these days, especially the errors since that funs afoul of verifability. Bunched/bundled refs with both errors & warnings do show up together in the same Category:Harv and Sfn no-target errors articles. - Shearonink (talk)
Listing very infrequently auto-archived pages?
Is there a tool or database page which lists Talk pages which have an autoarchiving config (for any bot), where the bot hasn't run for a very long time? (To list pages where archiving may be broken or which may not need autoarchiving at all due to long-term inactivity,) – Scyrme (talk/solidarity) 04:38, 27 October 2026 (UTC)
Easy enough to make one. How long is "a very long time"? (And which archiving bots are you interested in?) quarry:query/110613 has a proof of concept for User:Lowercase sigmabot III; the absolute oldest are 21 pages not archived since 3 November 2013, and the thousandth-oldest was archived on 14 February 2017. —Cryptic 05:04, 27 October 2026 (UTC)
Great! Anything that hasn't seen a bot run in over 10 years seems like a good place to start, though setting an exact age cut-off isn't really important and fetching the 1000 oldest regardless of age works too. All these pages that haven't seen a bot run since 2013/14/15/16 are exactly the sort of thing I'm looking for. I'm particularly interested in Lowercase sigmabot and Cluebot, as they're the most commonly used and I'm more familiar with how to fix them if the reason for them not being archived in ages in due to something on the page preventing them from running as intended. – Scyrme (talk/solidarity) 07:34, 27 October 2026 (UTC)
quarry:query/110629 for tagged pages that have never been edited by Lowercase sigmabot III. The ones that nobody's edited since 2007 are probably more of a problem than the ones edited in the last week; but there's no way for this tool to tell when the template was added, so some of the later pages on the list might have had broken archiving for a long time too.quarry:query/110630 and quarry:query/110631 for the equivalents for User:ClueBot III. —Cryptic 15:10, 27 October 2026 (UTC)
Notifications not being cleared and "Mark all as read" button missing
Button to mark all notifications as read has disappeared
Has anyone else noticed this? (Vector 2022, Firefox) Helpful Cat🐈 11:55, 27 October 2026 (UTC)
The "Mark all changes as seen" button? Works fine for me on Monobook/Firefox (158.0) and I just flipped the skin to Vector 2022 and it was still there. Black Kite (talk) 12:08, 27 October 2026 (UTC)
This one for notifications - but it suddenly came back after you posted this. How odd. ("Mark all as read" in this screenshot was missing when I posted this question) Helpful Cat🐈 12:22, 27 October 2026 (UTC)
did you have any unread notifications? I don't think the button shows unless you have at least one unread notification. Nthep (talk) 12:52, 27 October 2026 (UTC)
Yes, I had three notifications that were persistently showing as unread, even though I had read them. Helpful Cat🐈 12:54, 27 October 2026 (UTC)
Sorry for many comments - the persistent notifications are back, and the button is gone again: Helpful Cat🐈 12:58, 27 October 2026 (UTC)
Ghost notifications
For the past few days I have been facing notifications that will not go away and that I cannot see or remove. The marker is greyed out, like when you've viewed a notification but haven't read through it, but when I click on it nothing is there. Marking all as read makes it seem to go away, but when I move to another page it comes back. It appears in both pings and echoes; the actual notification changes if it is on pings or echoes and the number of notification (it seems to have to do with whatever the last actual notification I received was?). Yesterday it went away for a bit but then it came back.
I've logged in and out, didn't change it. Cleared cookies, didn't change it. The issue is present across all the multiple devices I am logged in on. Appears across all wikis I've checked.
Any ideas? It's making telling if I have actual notifications somewhat hard. Unsure if this is the same issue Helpful Cat has above, as I can mark them all as read but it comes back. PARAKANYAA (talk) 14:54, 27 October 2026 (UTC)
@Helpful Cat Is this the same issue you're having? I can't tell from the description. PARAKANYAA (talk) 14:56, 27 October 2026 (UTC)
This sounds similar to my issue, but slightly different. My persistent notifications are/were real notifications that I can see and read, but that just can't be marked as read; this comes and goes, so sometimes the notifications will disappear from the unread section but then will become unread again. My "mark all as read" button also disappears on and off. I've been having this issue with persistent notifications for a few days, and they sometimes block new notifications from appearing. I assumed it was PHP-related. Helpful Cat🐈 15:22, 27 October 2026 (UTC)
They seem related, at least. And yeah it started at about the same time as the PHP issue developed so wouldn't be surprised. PARAKANYAA (talk) 15:27, 27 October 2026 (UTC)
I have experienced a similar issue. Axolitl(talk|contribs) 14:58, 27 October 2026 (UTC)
Same here. qcne(talk) 11:02, 28 October 2026 (UTC)
I've had this same issue but it's gone away upon clicking the notifications box and then reloading the tab. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 11:21, 28 October 2026 (UTC)
Some sort of server issue is causing 503 and API errors when performing a variety of operations right now. Staff are aware of the issue and working on it. – Jonesey95 (talk) 03:47, 28 October 2026 (UTC)
Thank you, Jonesey95. I thought it was an issue with Twinkle but now the top of the article doesn't have a Page tab on the regular menu either so I don't see a way to delete pages. LizRead!Talk! 03:53, 28 October 2026 (UTC)
That sort of answers my question about HTTP 503 errors. I think I will do something else for a while and then come back. Robert McClenon (talk) 03:55, 28 October 2026 (UTC)
Thanks, thought it was me and my connection when I kept getting 503s on previewing my changes, but other sites were working great with no issues. Will come back tomorrow. Zinnober9 (talk) 03:59, 28 October 2026 (UTC)
I'm still having problems trying to carry out tasks with red error messages about the API. Sometimes if I do the same edit two or three times, it works but other times, I just have to move on. LizRead!Talk! 04:18, 28 October 2026 (UTC)
I have been encountering these kind of errors too. EnDeeDoubleYou (talk) 05:09, 28 October 2026 (UTC)
Outdated thumbnail in file history
Hello, the thumbnail for the latest version of this file shows the previous image, even though opening the revision shows the correct one.
Now the thumbnail is correct, so the issue is fixed. Carloseow (talk) 00:04, 29 October 2026 (UTC)
Template generating categories mess
Can someone familiar with overly convoluted templates have a look at Template:Category U.S. State elections by decade/core and fix a problem? The US elections categories are being renamed en masse, basically from STATENAME elections to elections in STATENAME (see Wikipedia:Categories for discussion/Working/Large) but they're populated by messy templates and attempts to adjust them are creating oddities - see Category:1912 elections in Alabama for one of numerous such cases where the template generates category names like "1910s elections i elections", "Elections in elections i by year" and "1912 in elections i". Thanks in advance. Timrollpickering (talk) 14:51, 28 October 2026 (UTC)
I think the problem is the lines | place = {{{place|{{#invoke:string|sub|{{BASEPAGENAME}}|5|-10}}}}} and | year = {{{year|{{#invoke:string|sub|{{PAGENAME}}|1|4}}}}} in Template:Category U.S. State elections by year (and the similar ones in "by decade"). I'll see if I can make it a bit more robust. --Ahecht (TALK PAGE) 15:12, 28 October 2026 (UTC)
I have done quick (non-robust) fixes to both pages that seem to be working. There will be some red categories until the category moves are complete, but the category names should all make sense. – Jonesey95 (talk) 15:13, 28 October 2026 (UTC)
We can't have the old set of categories and the new set working at the same time. Old category names will be broken until all of the pages have been moved by the bot. I have also adjusted {{Category U.S. State elections by decade}}, which will break existing pages until all of the category pages have been moved. – Jonesey95 (talk) 15:29, 28 October 2026 (UTC)
The bot is working at a rate of very roughly one state per hour, and there are 50+ states and territories, so these updates might take a day or three. Pinging Bearcat, who will probably notice. – Jonesey95 (talk) 15:38, 28 October 2026 (UTC)
@Jonesey95, Timrollpickering: I implemented a much more robust fix that can handle either format ("#### elections in Foo" and "#### Foo elections") and correctly handles "(state)" and "(U.S. state)".--Ahecht (TALK PAGE) 16:29, 28 October 2026 (UTC)
There are indeed a pile of related categories on the current run of Special:WantedCategories, but entirely so far of the "[State] special elections" → "Special elections in [State]" variety that seems to be handled by a different template than the one under discussion, specifically {{United States House of Representatives special elections in state category header}}. Could somebody more versed in template coding than I am look into that template, since it doesn't appear to have been updated in conjunction with this? (It hasn't been edited at all since May.)
I'd also like to note that at least officially, we have a rule that template-generated categories aren't supposed to be speedy-moved by bots, precisely to avoid pages being left sitting in the redlinked old categories due to the template not being updated — but when this has been raised in the past, the maintainer of the bot that does speedy moves complained about the added burden that would be placed on his shoulders if he had to verify the template-generatedness of every category before throwing it to the bot. (Yet the added burden that's placed on my shoulders as Cleaner-Upper-of-Redlinked-Categories if this isn't done seems not to be a concern at all, as if his time is more valuable than mine?) So could we at least compromise on a new rule that the bot has to speedy-move categories with a categoryredirect from the old name instead of deleting the old names outright, and then the old category can be deleted after we've been able to confirm that it's been fully emptied instead of before? Bearcat (talk) 16:49, 28 October 2026 (UTC)
ISTR we had that set-up in the later years of Cydebot but it provoked complaints that numerous redirects were being created by bot. It may be time to reconsider that one. Though it would place a large burden on the redirect system and those who clear that up.
I think the biggest annoyance is the drive by, slap one, rush off approach by both nominators and some admins. The original nomination made a vague reference to "any related templates should be updated" instead of identifying which templates should be amended. Then the processing admin just slapped them on the large working page and left it to the bot to plough through them. It's only once the bot is underway that it becomes clear there's a problem and that encourages speedy attempts to fix it. Is there any way to automate showing that a category is populated to a template rather than relying on nominators and admins to check? Timrollpickering (talk) 18:37, 28 October 2026 (UTC)
CSS width values are offset
Don't know if this has anything to do with PHP or not, but something weird is happening with the width of my signature. Currently, the code for signature is <div style="border: 2.25px solid #333; width: 210px; border-radius: 12px; padding: 7px; background-color: #FFD230; display: in;">[[User:F0malhaut42|ғѳmɑɭʱɑυե]] [[Wikipedia:Editors' pronouns|(Any pronouns)]][[User Talk:F0malhaut42|ᵀᵃˡᵏ]]</div> , but the width part appears to be glitched. 185px width should leave enough space for my signature to fit on one line, but when I replace the 210px with 185px, the following happens:
Same thing happens with any number up to 200 and possibly higher (I haven't tested any values in between 200 and 210), so it looks like the width values are offset by roughly 20. I only changed my signature to this today, so I'm not sure if this is a known problem or not, but it's probably for the best if I put this here just as a heads-up.
Probably depends on the font and skin. But more importantly, you really need to go read Wikipedia:Signatures#Appearance and color, your signature goes against the policy there in multiple ways. Anomie⚔ 23:51, 28 October 2026 (UTC)
With that said, the first one shows no line wrapping for me. LittlePuppers (talk) 00:05, 29 October 2026 (UTC)
Something like <span style="border: 2.25px solid #333; border-radius: 8px; padding: 3px; background-color: #FFD230; display: inline;">[[User:F0malhaut42|ғѳmɑɭʱɑυե]] [[Wikipedia:Editors' pronouns|(Any pronouns)]][[User Talk:F0malhaut42|ᵀᵃˡᵏ]]</span> would fix... several issues. LittlePuppers (talk) 00:10, 29 October 2026 (UTC)
They look fine to me unless I hit Command-+ to increase my browser's zoom level, at which point the signature wraps. That tells me that a fixed pixel width is the wrong way to construct this signature, or any box with text that is not supposed to wrap. – Jonesey95 (talk) 01:30, 29 October 2026 (UTC)
Indeed, the width really shouldn't be needed, your browser will figure out what's needed on its own. (I meant to fix that in my example above but forgot... regardless, inline elements ignore width so it wouldn't have mattered.) LittlePuppers (talk) 04:26, 29 October 2026 (UTC)
Stay away from block elements - not just <div>...</div> - for content that is supposed to be inline. --Redrose64🌹 (talk) 06:46, 29 October 2026 (UTC)
Difference between revisions - new display?
I have noticed that the differences between revisions have been displaying differently since yesterday (or was it the day before)? I assume that this is meant to be an improvement, but (a) I find it harder to read - although this may just be a matter for getting used to it, and (b) it seems to be taking an inordinately long time to open for me after clicking on the link in an email. Can someone advise me as to why this was done or what is the benefit of the change? Laterthanyouthink (talk) 06:19, 29 October 2026 (UTC)
Different in what way? --Redrose64🌹 (talk) 06:47, 29 October 2026 (UTC)
It used to show the removed text highlighted in yellow, and the added text in blue, side by side. No other colours.
Now, it highlights the previous "revision as of" line at the top in red, with a strikethrough, and the new "as of" version in turquoise, across the top.
Then, if it's just an addition, you have to scroll down to see the bits that have been added (in turquoise). If just a removal, there's just text at the side, e.g. "Link removed: [name of link]". If the changes are more complicated, various means show new bits in turquoise, notes on the right about removals, etc.
A bit difficult to describe without being able to do screenshots, but if you look at differences in any page history, you should be able to see them. Laterthanyouthink (talk) 07:59, 29 October 2026 (UTC)
VisualDiff
Wikitext diff
Toggle button
@Laterthanyouthink I don't think it's a software change, perhaps you accidentally clicked on "Visual" which enabled the view you're currently seeing – clicking on "Wikitext" switches you back to the diff view you're used to. More info: mw:VisualEditor/Diffs. Johannnes89 (talk) 09:43, 29 October 2026 (UTC)
Ah, doh! So that's what the problem was! Thanks very much for that - all hunky dory now. Laterthanyouthink (talk) 12:12, 29 October 2026 (UTC)
Proposals
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) CNCin 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 labelDefault 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.
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.
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 optionBecause 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)
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)
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)
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)
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)
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)
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"? BD2412T 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)
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:
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:FaviFake20: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:FaviFake20: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.
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)
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)
A comparable user right and protection level would be template editor and template protection. Circumstances are a bit different, but there is precedent for user rights related to specific actions being able to edit past protection of those actions. Skarmory(talk •contribs) 03:03, 25 September 2026 (UTC)
This all seems very sensible to me. Thryduulf (talk) 08:20, 25 September 2026 (UTC)
I would support this. Most move-protected pages are from page-move vandalism or page move warring (source: just a guess), and I think by granting someone page mover the community trusts them not to perform page move vandalism. Axolitl(talk|contribs) 22:39, 25 September 2026 (UTC) edited 22:40, 25 September 2026 (UTC)
I also was discussing this on Discord too at a different time, though in an unrelated context. I would support this, especially since it means that admins would have a reliable middle ground to not need to default to full move protection when extended-confirmed protection is insufficient, except in the most extreme of cases. Any page mover who can't be trusted to, well, move pages responsibly and in accordance with policy, probably should not be a page mover. I think we should probably at least informally expect that admins do not use this new protection level for edit protection, only move protection, similarly to how template editor protection isn't (usually?) used on articles, since it's inconsistent with why the right was created. EggRoll97(talk) 01:58, 26 September 2026 (UTC)
IIRC I can implement it to be an option for move-protect only. msk 02:06, 26 September 2026 (UTC)
Er, are you sure? The array in wgRestrictionLevels (which controls the protection options) is 'enwiki' => [ '', 'autoconfirmed', 'extendedconfirmed', 'templateeditor', 'sysop' ], so unless you have another location for more fine-grained tuning in mind, I don't think it can be technically restricted from being used as an edit protection level (nor do I think we really need to, I think we can just trust that admins wouldn't use it for something it's not designed for). EggRoll97(talk) 05:40, 26 September 2026 (UTC)
Nope, you're right. Sorry about that. msk 14:13, 26 September 2026 (UTC)
Support. Page movers can be trusted to move the mine run of move-protected pages (in mainspace at least), so I'd be on board with downgrading a large number of protections if this is successful. Expectations like "don't use for edit protection" can be documented in a new section at Wikipedia:Protection policy. Extraordinary Writ (talk) 05:56, 26 September 2026 (UTC)
I accept that this proposal wouldn't save time on net, but I still think it's important just as a matter of principle to apply the least restrictive level of protection necessary and only take things away from non-admins as a last resort. That's probably an unorthodox position, though. Extraordinary Writ (talk) 01:44, 21 October 2026 (UTC)
@Extraordinary Writ: Adding a new protection level above extended confirmed is likely to make page moves more restricted for the broader community, not less. The typical long-term editor's most advanced group is extended confirmed. The better solution is to reduce the frequency of full move protection. Daniel Quinlan (talk) 01:59, 21 October 2026 (UTC)
Adding a new protection level above extended confirmed is likely to make page moves more restricted for the broader community, not less. So your argument is that, if we add mover-protection, admins applying move protection would disregard our policies and use mover-protection even where, at most, only ECP move protection would be allowed? FaviFake (talk) 15:55, 21 October 2026 (UTC)
ECP move protection is non-standard; see Wugapodes' comment. msk 16:27, 21 October 2026 (UTC)
Then IAR applies. If an article can't remain confirmed-move-protected but doesn't need to be admin protected, use ECP. For example, the current TWAFI has been EC-move-protected for a week due to the relatively minor potential for disruption. FaviFake (talk) 18:21, 21 October 2026 (UTC)
No, I just think it's inevitable. How it happens will likely be reflected in policies and guidelines. Daniel Quinlan (talk) 16:56, 21 October 2026 (UTC)
If I understand correctly, the argument is something like this: Right now there is only ECP and the far more drastic admin-only move protection. There is some number of pages where maybe ECP isn't quite doing the trick but the currently available next level feels too extreme. Some, many, perhaps the vast majority of these remain at ECP. If we introduce this intermediate protection level, it will be more palatable to increase the protection on more and more pages without having to go all the way to admin-only move protection. Over time, the total number of pages that have a move protection level higher than EC will be potentially much greater than it is today. A downstream effect will be that requests to increase or decrease between the different levels will increase. —Myceteae🍄🟫 (talk) 18:21, 21 October 2026 (UTC)
Why would it be more palatable to increase the protection on more and more pages? To whom would it be more palatable? If a non-admin thinks ECP is not enough, they'll go to RfPP regardless of whether there is another available intermediary protection type.If an admin lands on an article and they think ECP is not enough, they'll simply apply mover-protection and move on. I don't see the issue here. FaviFake (talk) 18:25, 21 October 2026 (UTC)
I'm not making this argument but my understanding is that admins sometimes encounter pages where ECP might be too loose but admin-only might be too restrictive. Some portion of these, perhaps the majority, remain at ECP. If they had another intermediate option available, they would use it. I'm not an admin and rarely have requested or participated in discussions about page protection. I don't have any sense of what the potential impact would be. —Myceteae🍄🟫 (talk) 18:52, 21 October 2026 (UTC)
I think it was said elsewhere in this discussion that ECP is not applied for moving without it being applied for the whole article, even though it can technically be done, because there's no guidance as to when it would be allowed. –Maltazarianᚾparleyinvestigateᛅ 18:56, 21 October 2026 (UTC)
Ah, maybe that was more the issue. —Myceteae🍄🟫 (talk) 19:00, 21 October 2026 (UTC)
At the very minimum, at least one of ECP or page mover should be a valid move protection level. Skarmory(talk •contribs) 19:05, 21 October 2026 (UTC)
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)
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. CNCin solidarity (talk) 06:10, 28 September 2026 (UTC)
Support – Page movers should be able to move pages. Being trusted to do so responsibly is the whole point of the user right.
I have on multiple occasions expressed my frustration both on- and off-wiki (although not actually in the discussion that led to this RfC, which I was pleasantly surprised to see in WP:CENTRAL) about being a page mover yet being unable to move pages. It is a regular source of additional work and annoyance (especially for more complicated closes) for page movers closing RMs and the admins who have to stand-in to carry out the moves. On multiple occasions I've had to spend time explaining to editors asking me why the pages haven't been moved that yes, the closing template has a field that explicitly states that a non-admin page mover performed the close, but no, that page mover cannot move the page. Yes, it is relatively rare, but the additional work adds up and there is no good reason for it to be happening at all.
We are trusted with the ability to override the title blacklist, create and edit page edit notices and redlink almost anything by moving without leaving a redirect (and some other stuff), but somehow not trusted to do normal moves for pages that some other editors have been improperly moving. If someone cannot be trusted to deal with the ability to move pages that are move protected they should not be trusted to do any of these other things. –Maltazarianᚾparleyinvestigateᛅ 16:33, 28 September 2026 (UTC)
Just going to note that many (but not all) of the arguments along the lines of there being no need do not really argue why it would be a negative, and that the concerns about it being too much work are ignoring that msk offered to do it (and for the record, they are more than capable of doing so) which makes it a very low cost for the community-at-large (unless we want to insist msk would otherwise be obligated to spend that time working elsewhere on the wiki). –Maltazarianᚾparleyinvestigateᛅ 08:50, 23 October 2026 (UTC)
Personally, I'm seeing the opposite: a lot of the support votes focus on "page movers can be trusted to move pages" without considering whether there's enough of a need to balance the increases in complexity in interfaces and processes that result from adding another protection level. Anomie⚔ 11:54, 23 October 2026 (UTC)
There isn't much to say about that. If we want pages to be protected more precisely, then we need to add a new level, which should be used and requested if needed. The benefits of adding one more option in the drop-down are greater than leaving pages with an undue move-protection level. FaviFake (talk) 11:59, 23 October 2026 (UTC)
Most of the discussion here doesn't seem to be about protecting pages "more precisely" in the first place. It's about page movers being unable to handle the RM in the relatively rare cases where a fully-move-protected page needs moving, but without evidence this is leading to any sort of a backlog or unreasonable delay. Anomie⚔ 12:06, 23 October 2026 (UTC)
That's just a direct consequence of the fact that admins are currently forced to use full move protection in cases where ECP is not sufficient. FaviFake (talk) 12:11, 23 October 2026 (UTC)
What is? That most of the discussion isn't about what you claim, or that there's no backlog? Either way, I don't see how it supports your point. Anomie⚔ 22:49, 23 October 2026 (UTC)
Not sure if I've said this elsewhere in the discussion, but I do definitely think there are benefits to having this level around; I would think it would be a better level to use for cases of page move vandalism or move warring than full move protection when ECP isn't sufficient. Skarmory(talk •contribs) 13:50, 23 October 2026 (UTC)
I think that is actually a principled stance to have though. We strive to be an encyclopedia that anybody can edit, and we only put limits on that when it would be infeasible/unreasonable to not do so, not just for the sake of convenience, and we try our best to limit it only to the extent required to prevent disruption. Being supportive of a proposal to let editors one views as trusted to make certain edits be able to make those edits is in line with that. –Maltazarianᚾparleyinvestigateᛅ 13:20, 25 October 2026 (UTC)
Oppose. Just let page movers move all pages. If they can't be trusted with such power, they shouldn't have it. Jessintime (talk) 16:35, 28 September 2026 (UTC)
This is a different proposal than the once considered here. If, hypothetically, your suggestion couldn't be implemented and you were left with only two choices, would you prefer to keep the status quo or create a new protection level?FaviFake (talk) 16:40, 28 September 2026 (UTC)
Taken literally that is an incredibly bad idea. Letting page movers move any page would give them the ability to "edit" (replace the contents) of any page, including interface pages, the local global js/css files, etc, pages that even regular administrators can't edit. If a page mover were then to be compromised they could then engage in significantly more disruption. msk 17:27, 28 September 2026 (UTC)
Yeah pages that have higher-level protections should require corresponding permissions to move. Some widely-used templates also break if you move them due to accompanying css modules. We recently had an incident where an RM led to some list templates were moved, such as Template:Hlist to Template:Horizontal list, and that caused a large part of the wiki to break, including the main page, although it was fortunately swiftly fixed. That move also queued so much work for the backend jobrunners that it put enough of a strain on the backend for a WMF employee to take notice and ask that further moves be held off to let the queue be cleared.
Knowledge of this is not something page movers are expected to have, and the potential for disruption is on the level of "you can break the website doing this". Brings to mind that video of a chimpanzee being handed an AK-47. –Maltazarianᚾparleyinvestigateᛅ 18:02, 28 September 2026 (UTC)
MSK (Monkey Shooting a Kalashnikova) msk 18:04, 28 September 2026 (UTC)
To be honest, that should be a separate proposal. (Not to mention that allowing PMVs blanket access to the move tool might not be a good idea for the reasons mentioned by other users above.) Accessedgrant (Epicgenius mobile alt) (talk) 16:42, 6 October 2026 (UTC)
Comment how frequently do pages get fully move-protected because XC move-protection isn't sufficient, where the reason isn't a move war (for which full protection should continue to be used should this protection level be created) and why? Snowmanonahoe (talk·contribs·typos) 18:41, 28 September 2026 (UTC)
I had a similar question. I'm a fairly new page mover and I've actually not encountered this barrier yet although I am aware of the issue. My understanding is that the practical effect of this change would be primrarily to allow page movers to carry out RM closures for pages that fall under the first two bullets at WP:MOVEP (pages prone to vandalism and frequent page-move disputes). The purpose of page protection in these cases is to force a formal RM discussion, and page movers are entrusted to close and carry out complex and contentions RMs. I would think that the third MOVEP bullet (high visibility pages like WP:AN and Today's featured article) could maintain a higher, admin-only protection level. The discussion above highlights another category, templates and other complex pages where moving may break other parts of the site (although it's not clear if the templates discussed above were move-protected at the time or if the protection level was sufficient). —Myceteae🍄🟫 (talk) 18:53, 28 September 2026 (UTC)
Just to provide some context, the current list of fully-move-protected pages is at , and while I don't have a hard number for you, there is page after page of this. Anything from arbitration enforcement, to vandalism, to sockpuppetry, you name it for the reasons. As for where the reason isn't a move war, I would actually say page-mover-protection should be the default for move wars if created, as the main idea of the page mover group is that it is experienced and trusted users who regularly move pages and demonstrate familiarity with Wikipedia's policies and guidelines regarding page moving and naming, which is a quote directly from the page mover policy. EggRoll97(talk) 04:35, 29 September 2026 (UTC)
Weak oppose I like the idea, but I'm convinced by Anomie and BilledMammal that the demand isn't really there. Especially if it does in fact require a patch to MediaWiki core, which we seem to be unclear on(...?)
This RfC looks like it's going to pass, so one thing I will say is that this action should be treated with a certain gravitas like we do with redirect suppression and template editor. The protection policy should say that a page mover should in most circumstances only move a move-protected page when implementing their close of an RM. Snowmanonahoe (talk·contribs·typos) 05:47, 29 September 2026 (UTC)
Agreed that moving through move protection should not be done lightly and should mostly be used for implementing results of consensus discussions. Skarmory(talk •contribs) 02:07, 30 September 2026 (UTC)
I mean yeah, I fully expect of all page movers to understand that move protection is generally a very clear indicator that a move will be controversial and thus require an RM. –Maltazarianᚾparleyinvestigateᛅ 02:49, 30 September 2026 (UTC)
Support convinced by Extraordinary Writ's second comment above. Snowmanonahoe (talk·contribs·typos) 01:50, 21 October 2026 (UTC)
Hey @Sohom Datta, is there a reason you made this an RfC? AFAIK, the template shouldn't be added retroactively. It makes the old !votes a bit more confusing in context. Axolitl(talk|contribs) 00:52, 29 September 2026 (UTC)
It was on WP:CENT, and we were already !voting in the RFC style, so I assumed this was intended to be a RFC and the RFC tag just hadn't been applied. (No concerns from my end if there is consensus to not make this a RFC) Sohom (talk) 03:31, 29 September 2026 (UTC)
That's fine, though should we rephrase the opening statement, so it stays neutral? Axolitl(talk|contribs) 04:07, 29 September 2026 (UTC)
Pinging @MSK for their thoughts on this, as they were the one who started this discussion. - BlueEleephant (talk · contribs) 02:02, 30 September 2026 (UTC)
I did rephrase it as Should a new move protection level be created, which only allows page movers and administrators to move it? I tried to keep the intent of the original, while maintaining neutrality. Axolitl(talk|contribs) 02:11, 30 September 2026 (UTC)
Note that the "it" should have probably been "the page", but it's kind of too late now. Axolitl(talk|contribs) 02:11, 30 September 2026 (UTC)
I think the intended meaning is clear in this discussion. —Myceteae🍄🟫 (talk) 16:16, 30 September 2026 (UTC)
Support the idea, but this could end up blocked on the technical side. I think it will require a patch to MediaWiki core, and I am not sure this idea is wiki-agnostic enough to justify adding complexity to MediaWiki core. I've made a phab comment at phab:T439172#12372365. –Novem Linguae (talk) 02:45, 29 September 2026 (UTC)
I've rephrased the issue because of that; this will be enwiki specific. msk 02:47, 29 September 2026 (UTC)
The technical obstacles are not as severe as I thought. It looks like this can be done in config files, without making changes to MediaWiki core, except for some translation messages to be added to mw:Extension:WikimediaMessages. –Novem Linguae (talk) 21:30, 29 September 2026 (UTC)
Thinking about this more, could we perhaps just encourage making most move protection extendedconfirmed rather than sysop? Or is there some evidence that there are lots of cases where extendedconfirmed folks are not trustworthy enough but page movers are? –Novem Linguae (talk) 05:38, 30 September 2026 (UTC)
Good questions. It's also been suggested here that (page mover) move protection might be applied more often if this proposal goes through. —Myceteae🍄🟫 (talk) 15:11, 30 September 2026 (UTC)
Most of the page protections that I have seen would have been fine as extendedconfirmed protection. For example, the move vandalism at Epstein files. BilledMammal (talk) 23:45, 20 October 2026 (UTC)
I think some could be reduced, but that is absolutely not the example I would have picked. That general topic area is more disrupted than almost every topic area, and that specific article has been move vandalized.
We could consider mass reducing the move protection level (to extended confirmed) all main space articles that are extended confirmed edit protected with full move protection if the article has never been moved (including moves at prior locations). It would be fairly easy to write a one-time script to do this. I suggest "never been moved" rather than "never been move vandalized or subject to a move dispute" because the latter would require a massive and complex manual review and the simple approach would yield most of the benefit. This proposal would need an RFC and we would want to review the full list of articles that would be affected first, obviously. Daniel Quinlan (talk) 00:22, 21 October 2026 (UTC)
The move vandalism there was by an editor who was not extendedconfirmed. It was also by only a single editor; blocking that editor and not apply any protection would probably have been sufficient, but if it wasn't applying extendedconfirmed move protection would have been. BilledMammal (talk) 01:52, 21 October 2026 (UTC)
I concur with @Daniel Quinlan here. I have seen and experienced a rise in vandalism, especially move-related vandalism, from anons as well as newly created and autoconfirmed accounts. I have found that ECP is usually sufficient in countering and preventing such abuse, though often when I do request that for moves or editing in general, it is not implemented in favor of a subpar protection unless there have been multiple egregious offenses. —Trailblazer101🔥 (discuss · contribs) 04:25, 25 October 2026 (UTC)
Back in 2021 when Xeno and I were working through old move protections, the concern with using ECP for move protection was that it's never really been used outside of contentious topics, and neither WP:MOVEP nor WP:ECPGUIDE say that ECP move-only protection is allowed. They still don't. It's been a decade, and we still haven't documented all the corner cases of ECP. You can see the old AN discussion on the protection reviews for some old opinions on the idea. I'm not sure we ever finished reviewing all the old protections. It was like 9000 articles, but most of them could simply be unprotected. I did about 50, Xeno did nearly 500. It's why we added the unprotection reasons to the list of drop down options in the protection interface. This is to say, I'd be fine with allowing ECP for move protection, and would also encourage people to unprotect some stuff listed at User:Wugapodes/moveprotectreview. — Wug·a·po·des 00:30, 21 October 2026 (UTC)
If this proposal fails, there should definitely be a discussion about ECP move protection, because not having anything between autoconfirmed and full protection for moving pages enshrined anywhere seems wrong, especially if ECP is in actual use. Skarmory(talk •contribs) 18:25, 21 October 2026 (UTC)
EC move protection is already covered in the protection policy. Move protection of any duration may be applied to pages being repeatedly moved in violation of policy using the lowest protection level sufficient to stop the disruption (extended-confirmed or full). ~ Jenson (SilverLocust💬) 23:35, 21 October 2026 (UTC)
Support. This is good idea. It would allow admins more freedom to move-protect pages and let trusted pagemovers handle more controversial moves. Protection limited to people experienced with pagemoves is fairly similar to template protection for people experienced with templates, which I think is widely recognized as a useful tool. On procedure, I don't see how the presence or absence of an RfC tag has any impact on the validity of the consensus produced here, whatever that may turn out to be. The main point of the tag is to attract people watching the RfC categories to prevent local consensus issues, but VPPROP and CENT are sufficiently high profile to do the same. Toadspike[Talk] 11:11, 29 September 2026 (UTC)
Support. Page movers are generally not stupid, and similar to when we established template editors, only the highest of the high-risk needs to be kept behind the sysop gate. Please ignore my brazen conflict of interest here, and perhaps consider me an exception to the first clause of my previous sentence. With love from Maryland, charlotte👸♥ 09:06, 1 October 2026 (UTC)
Oppose. An additional move protection level will almost certainly lead to more protection requests and actions to adjust protection levels, and these requests will outnumber the move requests this would potentially avoid (which is only when a page happens to be at this level and a page mover happens to handle the request). I believe the real issue is that extended confirmed is a poor proxy for trust when it comes to page moves. We should address that issue instead. I also agree with Anomie that this would clutter the configuration and protection interface, and as someone who has handled many page protections, I believe adding another level would make each protection decision more complex and slower. Daniel Quinlan (talk) 20:11, 1 October 2026 (UTC)
extended confirmed is a poor proxy for trust when it comes to page moves. We should address that issue instead. This is an attempt to solve this exact issue. How do you think the 30/500 protection could be limited to more users? I don't understand; if we make extended-move-protected pages require, say, 1000 edits instead of 500, that's no longer "extended-move-protection". FaviFake (talk) 20:14, 1 October 2026 (UTC)
I didn't propose specific changes to extended confirmed, but I'm ready to join a discussion about other approaches at WP:VPI. I oppose this proposal because it likely adds more work than it saves. An acceptable approach would reduce reliance on sysops for page moves without adding more sysop workload than it saves. Daniel Quinlan (talk) 20:47, 1 October 2026 (UTC)
Sure, I was just confused about how it could be possible to address this issue by modifying the 30/500 move protection in a way that wouldn't completely change the protection level itself. FaviFake (talk) 20:52, 1 October 2026 (UTC)
OT/FYI: there have been discussions at WP:PP regarding a new protection level, something between ECP and Full stil get's my support. The fact there is nothing between a busy one month editor and admin protection is baffling, aside from imposing PBAN/TBAN/CBAN. Personally I prefer the high bar like 5K/6M or 10K/1Y as "Advanced protection", then just yank privileges when needed, something we never do for experienced editors as 500/30 as is only a month break by comparison, so bans become necessary. A 6M/1Y defacto ban from editing pages with advanced protection makes a lot more sense overall, if that is the issue with certain users. In absence of that, I support this idea. CNCin solidarity (talk) 09:27, 3 October 2026 (UTC)
I don't really see why it needs to lead to more frequent requests for move protection, other than perhaps as a result of admins being more willing to use it, and discussions about changing the move protection level would be exceedingly rare – the only situation where you would realistically use full move protection would be on highly-visible templates.
For article space, I expect things to function pretty much just like they do now but with page movers able to move pages, and potentially with admins being more willing to use move protection on pages (which I don't see as workload as much as more tools to work with). –Maltazarianᚾparleyinvestigateᛅ 22:04, 1 October 2026 (UTC)
An increase in protection levels is not just "more tools" and it's definitely not a free lunch. Every new protection level creates two new boundaries, and we regularly field requests to increase or lower protections (both on RFPP and on sysop talk pages), and many of those are rejected due to insufficient disruption or excessive risk. Adding a new protection level because a small number of requests take a day or two to resolve is using an expensive sledgehammer to swat a fly. Daniel Quinlan (talk) 23:49, 1 October 2026 (UTC)
I know you field plenty of protection requests for the different kinds of protection we currently have in place, but that doesn't mean that this one will be the same, and there is good reason to believe that it would not be for the reasons I already mentioned. The way I see it the current move protection can be split in half with a pretty clear boundary between the two levels. The only editors that would even be affected by a change between full move protection and the lesser move protection is page movers, and I cannot imagine that page movers are going to be consistently requesting changes to the protection level of high-visibility template pages. –Maltazarianᚾparleyinvestigateᛅ 01:29, 2 October 2026 (UTC)
Support This seems like a good idea. Page Movers are on some level going to be inherently more trustworthy than extended confirmed users in these situations because they have more to lose if they abuse it. --Ahecht (TALK PAGE) 17:20, 9 October 2026 (UTC)
Support as there are less page movers (467) than admins (808) and that PMs can be trusted not to move protected articles unless absolutely necessary (usually after an RM). I have the PM right also JuniperChill (talk) 11:55, 10 October 2026 (UTC)
Oppose per BilledMammal below - the amount of effort spent dealing with this ultimately exceeds the value. * Pppery *it has begun... 20:32, 10 October 2026 (UTC)
Support per above, mostly on the idea that those with the extended mover right have been trusted with those tools. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:11, 12 October 2026 (UTC)
Oppose a user group existing doesn't mean a protection level should also exist. The work saved needs to outweigh the work created. For work saved, it would save us one or two requests per week based on the comments from Anomie and Billed Mammal. Meanwhile, the work created is quite steep. New protection levels mean new protection policies for those levels that need to be maintained and argued about---it took 6 months and 2 RfCs to settle on the current ECP policy back in 2016. Editors will place more requests at RFPP to change protection levels, not all of good quality, that require more admin time to decide than the weekly technical request and distract from more pressing protection requests. The non-standard changes to the server-side code needs to be written and maintained even when the original writer stops caring. The trade-offs seem terrible. Page movers who can be trusted with sysop-protected pages should apply for the existing sysop permission rather than creating a new protection level and all the work that comes with it. — Wug·a·po·des 20:27, 12 October 2026 (UTC)
I'm not in this group so maybe I'm out of line here but I stumbled upon this and it sounds like a no-harm addition useful to at least a small extent with a person willing to implement it. Blippy1998 (talk) 08:06, 19 October 2026 (UTC)
You're not out of line. No one with advanced permissions of any kind inherently has any sort of authority over others as to how this website should be run. Snowmanonahoe (talk·contribs·typos) 18:44, 20 October 2026 (UTC)
It sounds that way, but it's unfortunately a false economy. This approach will almost certainly generate far more work at WP:RFPP than it will save at WP:RM/TR. It would be better to find a different solution that doesn't have that downside. Daniel Quinlan (talk) 18:58, 20 October 2026 (UTC)
Oppose per Daniel Quinlan and Wugapodes. The benefits don't seem to outweigh the potential problems/time spend. mdm.bla 17:58, 20 October 2026 (UTC)
Oppose per Daniel Quinlan. Wikipedia doesn't need more and more and more levels of every option just for the sake of adding them. This applies to protection levels.Katzrockso (talk) 00:33, 21 October 2026 (UTC)
Oppose - As I said ten years ago in a slightly different context: There is no need. Requests of this nature can be easily handled by an administrator ... as the current rate of occurrence is low. Anomie demonstrates above that this sentiment still rings true for the matter at hand now. There is also a reasonable argument to be made that a move-protection level between EC & Full is overarchingly undesirable, but I will refrain from making it until a need is demonstrated. —Godsy(TALKCONT) 02:51, 23 October 2026 (UTC)
@Daniel Quinlan and Wugapodes: You both hit the nail on the head. Re-reading your comments above made me realize something—this proposal would really just result in a quasi-unbundling of the sysop toolset. However, the framing avoids the traditional ire drawn from true technical unbundling proposals! Convolution should always be avoided; if page movers are so trusted in actuality, then they should be granted the ability to move fully-protected pages. It certainly should not be done in this manner which suffers from all the cruxes which you both so aptly point out. —Godsy(TALKCONT) 04:01, 25 October 2026 (UTC)
Very good point. While I still support the proposal in absence of an alternative, a better direction would be similar to the intended purpose of NPR and PMR. In the same vein that NPR was "unbundled" from the admin tool set, and we now have more non-admin reviewers than admins with full permissions to review pages, PMR should realistically also include permissions for move-protected pages, based on the assessed trust of those who have page mover permissions. In response to Wugapodes however, Page movers who can be trusted with sysop-protected pages should apply for the existing sysop permission [...], I strongly disagree. Most page movers appear to have no interest or demonstrated need for sysop permissions, because their focus is on moving pages, not everything else that comes with the mop and bucket. On this note I'd prefer to see further unbundling of sysop toolkit, such as WP:Page deleter, WP:Page protector, etc, for those who prefer to stick to particular areas of the 'pedia. Moreover, the benefits of further unbundling would be worth the time and effort, like it has been for NPR and PMR already, while I can see the drawbacks of a new protection level. Overall for every permission granted, it can translate to dozens if not thousands of admin-like actions that otherwise wouldn't have occurred. I can't imagine where the project would be without NPR/PMR to be honest, especially given how backlogged NPP usually is on a good month. Also if editors want more admins then the best strategy for that is to create more stepping stones in order to reduce the hurdle of RFA/AELECT. Whereas recommending page movers apply for sysop rights, simply in order to move protected pages, is well intended but thoroughly unrealistic. CNCin solidarity (talk) 09:44, 25 October 2026 (UTC)
I would also like to note that move protection is hardly being applied to mainspace pages because only sysops can be trusted to move them, it's done because there is no other alternative. –Maltazarianᚾparleyinvestigateᛅ 13:10, 25 October 2026 (UTC)
Moving full protected pages is a demonstrated need, and page movers are great admin candidates. Page movers have been trusted with limited delete permissions since 2021. They also show demonstrated experience in reviewing contentious discussions for consensus and can follow admin-level policy documents well. If a page mover only uses the tools to move pages we're better for it, and if they use the rest of the kit to improve the encyclopedia, even better. The tools are a way to serve your corner of the encyclopedia, not leave it.That said, I don't think generally unbundling the core block-protect-delete tools is a good idea either. Dealing with disruption requires all three in your toolbox. For example, socks should usually be range blocked as a first resort rather than have the page protected and revision deletion can be important for cleaning up afterward. If we give some people block and some people protect and some people delete, then at best we will still need to wait for someone with the proper tools and at worst we will use the wrong tool for the job. Personally, I think one of our biggest AntiPatterns is that we spend hundreds of person-hours debating new permissions, coding new permissions, writing policies for permissions, processing requests for permissions, and monitoring use of permissions so that our most responsible editors can build an inferior toolkit request by request. At a certain point we need to kindly but firmly say, if someone wants to serve the community with further tools they need to stop making work for others and just get the whole toolbox. — Wug·a·po·des 02:39, 26 October 2026 (UTC)
@Wugapodes: I agree. Just want to clarify that while I think granting page movers the ability to move fully-protected pages is a better idea than what is being proposed here, it still is not something I would support. —Godsy(TALKCONT) 02:54, 26 October 2026 (UTC)
Do you think someone would pass RFA or AELECT if the only reason they are running is to supplement their ability to move pages? I suspect at best, it would be a very hard sell. Skarmory(talk •contribs) 02:56, 26 October 2026 (UTC)
Probably not, but most extended movers work in multiple areas, and the most trusted ones would benefit from the additional permissions that are entrusted to sysops. Daniel Quinlan (talk) 03:04, 26 October 2026 (UTC)
"I want to move pages and I might help with other stuff" was my answer to Q1 and it worked fine. — Wug·a·po·des 03:26, 26 October 2026 (UTC)
I believe extended confirmed move protection will be sufficient for most if not all of these articles. If full move protection becomes necessary on an article, and there's consensus to move the article, and the consensus is reached before the full move protection expires, someone can make a request at WP:RM/T and it will be dealt with quickly. Daniel Quinlan (talk) 18:03, 27 October 2026 (UTC)
A few hours isn't really "quick" for a TWAFI. FaviFake (talk) 18:08, 27 October 2026 (UTC)
Given the number of administrators involved in TWAFI, watching the current and recent TWAFI articles, and handling requests related to the article, a wait of a few hours is not likely. Daniel Quinlan (talk) 18:26, 27 October 2026 (UTC)
Discussion (mover protection)
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)
I would probably name the sysop level full move protection and let this one be move protection. Skarmory(talk •contribs) 23:29, 28 September 2026 (UTC)
Surely "Move protection" and "Full move protection" are the simplest options here. –Maltazarianᚾparleyinvestigateᛅ 05:12, 29 September 2026 (UTC)
I feel like common usage is already for "move protection" to refer to the green lock. Like, sure, technically an ECP page is move protected at an ECP level, but I can't recall hearing anybody talk about it that way.
I'd suggest "extended move protection" as msk did, but then we're causing confusion due to EC not having anything to do with it.
Idk this part isn't all that important to me anyway. –Maltazarianᚾparleyinvestigateᛅ 08:24, 29 September 2026 (UTC)
Yeah it's tricky. For now my preference is for "mover protection"; pages will be "mover-protected" FaviFake (talk) 08:28, 29 September 2026 (UTC)
Impact
Looking at the past month of requests at WP:RMTR, I see just seven:
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:
Updated the table. The earlier one was moves of all move-protected pages, included extended-move protected. This one is still a bit of an estimate, as it assumes that if a page is protected now it was protected when the move occurred, so it can miss some moves where protected lapsed or was removed, and counts moves of pages later protected. For example, six moves from March are of Epstein files, none of which was done while the page was protected. BilledMammal (talk) 05:56, 29 September 2026 (UTC)
How hard to we really expect it to be to implement? Anyone got an idea? Also Move+ already has RM/TR capabilities last I checked. Did the recent update get rid of them? –Maltazarianᚾparleyinvestigateᛅ 05:15, 29 September 2026 (UTC)
Move+ lists moves at RMTR, it's never supported (outside of a prototype I wrote two years ago) implementing the moves at RMTR. BilledMammal (talk) 05:19, 29 September 2026 (UTC)
50 to 100 moves per year adds up over time, and this project is already over 25 years old. Meanwhile, we have someone volunteering to make the patch, who also happens to be the person who started this discussion, so that cuts down on the needed development time. This doesn't even account for other possibilities for how the protection level could be used; notably, I agree with EggRoll97 above that this would make sense as the standard for protection in case of move wars. Skarmory(talk •contribs) 05:16, 29 September 2026 (UTC)
Sourcing tools preceding / following AfD nominations
Hi everyone. We're all aware that one of the key issues driving nominations at AfD is a lack of proper sourcing on proposed articles. People aren't wrong that it's unlikely many of these pages will be worked on for a long while, which may lead to some resentment of Keep voters willing to salvage an article on notability grounds, but not to help improve the article thereafter.
With that in mind, I'm curious if we might benefit from something akin to the editing interface Refideas notice, at least for some time after an AfD nomination on sourcing grounds, to indicate to editors that come across the page that there are in fact sources available that were raised in the discussion to support what is otherwise unclear notability. Obviously this could be done just as well using Refideas, but doing so is functionally more difficult and not always possible given template restrictions. I'm curious what others have to say.
CSGinger14 (talk) 21:53, 14 October 2026 (UTC)
People aren't wrong that it's unlikely many of these pages will be worked on for a long while, which may lead to some resentment of Keep voters willing to salvage an article on notability grounds, but not to help improve the article thereafter.
I would say any such resentment or... really anything would be invalid and silly. AFD is notability gauntlet broadly when deleting is up as a question. If WP:GNG is proven, or one of the sideways Notability gauntlets that are black and white objective ("You pass GNG if you have earned X, Y or Z"), then any Admin honestly doing anything but Keep is being wrong or acting on emotion versus policy.
The best long term solution would be to something that imports all the URLs/sources at least to the talk page in a non-archive bot eligible section up top. Articles can be stubs. Stubs are fine. Something could trivially pass WP:GNG and be a stub for 20 years. That's fine too.
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.
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 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,
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:
How do we stop misuse of the AFD system from being rewarding; or
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.
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).
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)
@CSGinger14 I think you're being generous. I find a lot of nominators don't do due diligence searches. Even where they do, it's often limited. And when two sig cov sources are found, some nominators (and previous delete voters) won't withdraw their objections. The problem with PROD is it relies on someone objecting. If the creator is no longer an active editor, the page has less chance of uplift/survival. The issue with AfD is that, instead of the closer/AfC reviewer determining if the article now means notability requirements, it's essentially a vote (even if we say it isn't). So a page can be subjectively deleted or saved. I'm happy to support your proposal but I don't think it goes far enough. I think we need one of two AfD circuit breakers:
if you AfD an article, the discussion doesn't not start immediately, the article is templated for 7 days. You are obliged to reconsider your nomination if two sig cov IRS sources exist/are added in that time or it can be 3O'd if rescuer thinks the nominator is being unreasonable.
if two sig cov IRS sources are added during the discussion, the previous delete votes get less weight or are thrown out
But honestly, I'd like to see an investigations process for bulk nominators where there is suspected bias/abuse. Mme Maigret (talk) 00:22, 27 October 2026 (UTC)
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)
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)
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)
Interesting. I have the gadget enabled, although I pretty much only use it for either spelling/grammar or formatting corrections. Anything more extensive I type out manually. I guess the users who'd abuse such a feature don't know or care enough to bother enabling it. I'm mildly surprised that they'd outweigh good faith new users who'd prefer that option though. ChompyTheGogoat[Bleat|Munched] 19:49, 22 October 2026 (UTC)
I would also support a trial. What were you thinking, first 50 or 100 edits? First X mainspace edits? Relatedly, it would be good if someone could put together a quick and basic info page about what the warning looks like, perhaps something that Special:Preferences#mw-prefsection-gadgets could link to. That would also be a useful page to note any test results and track changes in defaults. CMD (talk) 07:25, 22 October 2026 (UTC)
I would say the group I expect the biggest difference for are newbies. So an A/B test among TAs and nonconfirmed editors would make most sense. To reduce confusion, I image their settings won't get changed once they reach a certain edit count. In solidarity, —Femke (talk) 🐦 16:55, 22 October 2026 (UTC)
Support: For newbies, more so than experienced editors. But happy to support for both Mme Maigret (talk) 09:30, 27 October 2026 (UTC)
Support changing the default in a trial, but Oppose any change that would prevent disabling the setting. Daniel Quinlan (talk) 17:35, 27 October 2026 (UTC)
Support adding it as default for a trial, collecting data for groups across editing levels. As far as I know, gadgets can always be disabled if needed. Chaotic Enby (in solidarity · talk · contribs) 18:05, 27 October 2026 (UTC)
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
"Anchor" comment placed at the top for the purpose of giving editors something to hit "Reply" on.–Maltazarianᚾparleyinvestigateᛅ 14:28, 26 October 2026 (UTC)
Strong support for ECR (creation of articles) and confirmed (any edit at all).
Support the use of ECR for Indian cinema (option B), presumably this would be through a WP:GS designation by the community. I wasn't aware of the social role that Indian cinema has until I started seeing the disruption (and LLM junk) here on enwiki, and I have not really watched any Indian movies to any real extent (saw one or two years ago but I can't remember which movies right now). I have no stake in this other than as an enwiki editor. ‑‑gurkubondinn 07:13, 20 October 2026 (UTC)
Support 500/30 rule (Option B) for Indian cinema topic area - What do Indian cinema and Indian military history have in common? Both are intrinsically linked to caste, which has been THE primary motivator of problems with regards to the India topic area. The standard set is irrelevant as Indian cinema already falls under WP:CT/SA and thus it can be assumed discretionary sanctions are already on the table. The problem is more dealing with blatant mercenary editors and the caste/nationalist warriors that come out of the woodwork in defence of a film that supports their caste or weltanschauung. —Jéské Courianov^_^vThrillerNight! 06:22, 20 October 2026 (UTC)
Option C as first choice, Option B, as second choice. I don't think autoconfirmed is pointless here. While registered editors can certainly game autoconfirmed, TAs are a sizable chunk of the problem, and they can't be autoconfirmed at all. It's not uncommon to have to tangle with a TA editor on a slop article four or five times in a day as they rapidly jump TAs and IP ranges. CoffeeCrumbs (talk) 09:56, 20 October 2026 (UTC)
For the benefit of the closer interpreting these multi-choice options, while I like C a tiny bit more than B, ultimately, my preference is for whatever helps create a working consensus for C or B. CoffeeCrumbs (talk) 04:09, 24 October 2026 (UTC)
I also support D if there's a consensus. At this moment, doing anything is, in my eyes, better than A, which is nothing more than sitting back and waiting until the garbage is so high that there's no volunteer army large enough to empty the landfill. CoffeeCrumbs (talk) 01:56, 26 October 2026 (UTC)
Support Option C then Option B - Option C would restrict many of the SPI throwaway accounts who operate heavily in that space. However, it would could be a nightmare to enforce and cause more issues than we alrady have. Option B would be my second choice. --CNMall41 (talk) 20:44, 20 October 2026 (UTC)
Support 500/30 requirement with Option B per Jéské Couriano. --ABx11 (she/they) 00:35, 23 October 2026 (UTC)
Option B as proposer. This is a hugely problematic topic area rife with UPE, promotional editing, and identitarian conflicts as described in the discussion section. ECR is an appropriate remedy and will make sure those editing in the topic are are serious. Autoconfirmed would be an insufficient remedy due to the ease with which autoconfirmed can be gamed; the problematic editors in this topic area are more than passionate enough to game AC in order to edit here. Athanelar (talk) 10:57, 23 October 2026 (UTC)
As I said in the discussion, I support option D. I've trawled through the new users log quite a bit in the last two weeks and one of the things that comes up there frequently is that promotional edits are most often for companies based in India. Now, I do not know what proportion of Wikipedia editors are based in India, but if memory serves me correctly then there is only one promotional company that explicitly declared their location that wasn't based in India compared to 4 or 5 that were based in India. Placing the topic under autoconfirmed would both stop TAs from creating overly promotional drafts and discourage at least some of the promotional sludge that we see rear its ugly head a few times a day. In terms of South Asian Cinema, pages that are related to castes should already be covered by CT/CASTE (I am by no means an expert on South Asian cinema so I could be wrong here), so I don't see the need for anything extra. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 12:55, 23 October 2026 (UTC)
In terms of South Asian Cinema, pages that are related to castes should already be covered by CT/CASTE It's not that simple, and this is why it's hard for people not in the know to understand how deep the problems run here.
In Telugu cinema (Tollywood) for example, a lot of the major actors are either of the Kapu caste (Chiranjeevi, Ram Charan, Pawan Kalyan) or of the Kamma caste (Nagarjuna, Mahesh Babu, N.T. Rama Rao). Not only that, but there are major film dynasties too; the three people I mentioned from the Kapu caste are not just related by caste, but also familially, and their family has major control over the whole production environment in Tollywood. There's an incredible amount of intersectionality and identity politics here which goes way beyond anything in Hollywood, and a lot of unseen factors that can influence disruptive editing (e.g., if I'm a person of a caste which is related to the Kapus, then I might have an identitarian interest in downplaying the success of films whose major actors are Kamma, or conversely in lavishing praise on people and projects related to the Kapus). I'm not as knowledgeable about Tamil films or Malayali films, but I have no doubt the same things exist there. Then there's also a whole separate dimension of Hindu vs Muslim politics in movies like Dhurandar and Ustaad Bhagat Singh.
The reason why ECR is appropriate here is because otherwise antivandal editors in this topic area need a veritable degree on regional history and sociopolitics to understand half of the shit causing the disruption. Athanelar (talk) 16:32, 23 October 2026 (UTC)
That explains why I keep getting accused of supporting some other person I've never heard of when I block inappropriate additions. Wait til they hear I'm a white girl who's never left the states. ChompyTheGogoat[Bleat|Munched] 21:15, 23 October 2026 (UTC)
Thanks, that was really informative to me. ‑‑gurkubondinn 22:09, 23 October 2026 (UTC)
This is a big reason as to why I don't agree with the two-tiered approach. I knew caste was a significant factor here, but I wasn't aware of just how much of one it was. —Jéské Courianov^_^vThrillerNight! 16:47, 24 October 2026 (UTC)
Did not know that. Given that, this should probably be extended confirmed so I'm changing my vote to a mixture of Option D and Option C, with ECR for cinema and ACR for CT/SA in general. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:04, 25 October 2026 (UTC)
Support D then C - While I agree this area is problematic, ECR is a very high bar to meet (it takes the average editor over 1 year). It's already overused in my opinion, we shouldn't be expanding it's use. Let's see if a lower restriction could work, it can be changed later if truly needed. InfernoHues (talk) 14:52, 23 October 2026 (UTC)
Option B. I'm not sure if anyone has brought this up yet, but G5 would be difficult and confusing to apply under option C. If a non-extended-confirmed account creates an article violating ECR, then a different non-extended-confirmed account could make significant edits to it, rendering the article ineligible for G5. I would imagine this scenario to happen often enough—either as a concerted effort or just naturally—to render option C significantly weaker than it would seem. Kisseran (talk) 18:55, 23 October 2026 (UTC)
G5 says no substantial edits by others not subject to a block, ban, or sanction. Based on that I believe the criterion would only be nullified if there are substantial edits by someone who is EC. Or are you saying that because the subsequent edits aren't article creations themselves, they could be construed as overriding the inappropriate creation? I can see how that might get messy based on interpretation. My original suggestion had included allowing non-EC users to submit drafts through AfC and only prohibiting direct creations in mainspace, but I think that would just increase the workload for reviewers even more, and full ECR is a cleaner approach. ChompyTheGogoat[Bleat|Munched] 04:23, 24 October 2026 (UTC)
Support Option B followed by Option C. I proposed the autoconfirmed restriction initially, but since then I've seen increased disruption from confirmed accounts and indeed even by EC editors who have reached that status purely through inappropriate edits to this subject area that have gone unreported. There's a huge mess that editors who haven't spent time patrolling these articles aren't aware of, and it's going to take us a long time to clean things up. I no longer believe option C is sufficient and I think we'd just end up back here debating increased restrictions after continuing to chase down more bad edits by autoconfirmed accounts. ChompyTheGogoat[Bleat|Munched] 21:22, 23 October 2026 (UTC)
Strongly oppose ECR ECR should be reserved for the worst of the worst topic areas. Movies may get a lot of passionate editors, but that's because movies are a universal experience. We all watch lots of movies and care strongly about them. Editing movies is a way that many editors come to Wikipedia. We'd be cutting off a significant avenue of recruitment for Indian editors by saying that only experienced editors can work in the topic. I have always worried that ECR would be extended into topics that truly don't need it, and this is a clear example. Movies have nothing on something like Israel-Palestine. I express no opinion on the other aspects, I just would hate to see ECR expand to...movies. CaptainEekEdits Ho Cap'n!⚓ 02:58, 25 October 2026 (UTC)
STRONG Oppose ECR, status quo we should not lock down everything and should leave ECR as option of last resort; it is a failure of all other systems and breaks wikipedias ethos of the encyclopedia anyone can edit, if only to protect in worst case areas. Eek is right, if there is need for this let arbcom do it. User:Bluethricecreamman(Talk·Contribs) 03:08, 25 October 2026 (UTC)
It's reductive to boil this down to just "movies." Like I've said, this is a hugely identitarian thing that intersects inextricably with caste, religion and culture in a way completely alien to the western film world. Athanelar (talk) 00:13, 26 October 2026 (UTC)
I don't buy that. Western cinema is just as full of propaganda/religion/culture, westerners just have a blind spot for their own media. If you've ever watched a twitter debate between movie dudes, its not very different. We're exoticizing Indian cinema and telling hundreds of millions of Indians that they're too passionate about their culture, so only the staid and sensible (and mostly Western) experienced Wikipedians can interpret their culture for them. CaptainEekEdits Ho Cap'n!⚓ 19:37, 28 October 2026 (UTC)
Rest assured I am not speaking from an entirely outside perspective here. I know a thing or two about a thing or two; South Indian cinema particularly, but the same issues abound all over. I really encourage you to read the other comment I posted here, if you ctrl+f "kapu" you'll find it. It really is nothing like anything that exists in Western cinema. Everyone knows Tom Cruise is a Scientologist, right? Now imagine like 80% of the USA are scientologists and slavishly devoted to watching Tom Cruise movies, and you're approaching the ballpark. Tollywood has a term, "TFI banisa", for its superfans. It literally means "Telugu Film Industry slave". I haven't heard any major subsection of the filmgoing western population calling themselves "Hollywood slaves". Imagine an entire cinema full of people screaming and hooting and throwing confetti at the screen because Tom Cruise or whoever their favourite action star is came on the screen. "Jai Balayya!" is something of a cultural catchphrase, meaning "Hail Balayya!" or something to that effect. Balayya of course being a major Telugu actor. Again, imagine if you could shout "Hail Tom Cruise!" in a public place and have at least a few people shout it back without hesitation.
Granted, the Telugus are about the mos extreme end of this spectrum, but it really, really is not the same in Western cinema. Athanelar (talk) 19:50, 28 October 2026 (UTC)
@Athanelar Could you please clarify your last sentence? ... I don't think many editors here are going to find creating a CTOP because the Telugus are about the mos[sic] extreme excessively convincing. To put it mildly.GreenLipstickLesbian💌🧸 20:17, 28 October 2026 (UTC)
I mean that as far as South Asian cinema superfans go the Telugus are probably the most extreme of the bunch, but that it also exists elsewhere, again c.f. Dhurandar. I just can't speak from a position of as much knowledge about other regional cinema industries because the Telugu industry is what I know best. Athanelar (talk) 20:32, 28 October 2026 (UTC)
Okay, let me rephrase: your comment is coming across as quite dismissive of an entire ethnic group. Could you please rephrase? GreenLipstickLesbian💌🧸 20:36, 28 October 2026 (UTC)
The fact that Telugu cinema fans are among the most devout and passionate is not an insult to them. Again, see "TFI banisa" above. The reason I said that is because I know a lot about the Telugu film industry and its fans and not as much about other South Asian regional industries, and I didn't want to imply that this same fan culture extends to Tamil cinema or Malayalam cinema or anywhere beyond, because I don't know if it does. I was defining the scope of my knowledge, not making a dig at the Telugus. Besides, I'm not sure how "Telugus are amongst the most extreme [cinema fans]" is any more disparaging to Telugus than Eek's statement Americans are overwhelmingly patriotic is to Americans. Also, to quote myself above, Rest assured I am not speaking from an entirely outside perspective here.Athanelar (talk) 20:47, 28 October 2026 (UTC)
You probably could have worded it better. "Extreme" is a word with quite a few negative connotations. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 20:48, 28 October 2026 (UTC)
Oh, please. My statement was Telugus are about the most extreme end of this spectrum and that statement comes at the end of a lengthy comment talking about how passionate Telugu film fans are. Literally what else could I possibly be referring to by "this spectrum" except their passion for film? Athanelar (talk) 20:54, 28 October 2026 (UTC)
You don't want to ask CaptainEek to rephrase or strike the statement Americans are overwhelmingly patriotic? Athanelar (talk) 21:36, 28 October 2026 (UTC)
Patriotic is a word which carries positive connotations. If the sentence had been "Americans are overwhelmingly nationalist", then this would be a different discussion. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:44, 28 October 2026 (UTC)
Patriotic is a word which carries positive connotations. For you, maybe. It definitely doesn't for me. Athanelar (talk) 21:47, 28 October 2026 (UTC)
With all cards on the table, I debated reporting this to AE, because casually using stereotypes is well below the standards expected in a contentious topic, but I prefer to avoid the drama if at all possible. I'd prefer not to, but saying that people of a certain ethnicity do or believe X is harmful, even if it's not ill-intended. GreenLipstickLesbian💌🧸 22:28, 28 October 2026 (UTC)
the Telugu film industry and its fans does not mean "all Telugus everywhere behave this way due to inherent ethnic factors". No derogatory statement was made and this smacks of western virtue signaling. ChompyTheGogoat[Bleat|Munched] 22:36, 28 October 2026 (UTC)
You're right; but the fact you take umbrage with what I said being an "ethnic stereotype" and not what they said is not because one of us did something wrong and the other didn't, it's because of your own Amerocentric worldview.
I have no interest in doxxing myself to win an argument, so I will leave it at asking you to please stop pearl-clutching at me. I have said nothing which is ethnically offensive to Telugu people, and I promise you I can say that with more than a reasonable degree of certainty. Anyone who has seen me around the project knows I'm not needlessly belligerant, if I'm standing behind my words to this extent I am doing so out of certainty that I've said nothing wrong. Athanelar (talk) 22:33, 28 October 2026 (UTC)
Now at WP:AE#Athanelar, in case anybody wants to make a statement about my behaviour during this discussion. Athanelar (talk) 23:31, 28 October 2026 (UTC)
That's exactly the point - you're applying your personal assumptions. I also dislike patriotism, but I don't assume negative connotations because I know most people don't intend it that way. Extreme is simply a modifier. "Extreme kindness"; "extremely charitable"; even "extremely passionate" can be positive - heck, I'd bet there are plenty of people involved with this topic who would see "extremely passionate about their favorite stars" as a positive statement. It's simply descriptive. ChompyTheGogoat[Bleat|Munched] 22:11, 28 October 2026 (UTC)
That's a fair explanation here. I withdraw my point, as this is a matter of opinion. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:12, 28 October 2026 (UTC)
Still carries negative connotations. When you say "extreme end", the first thing that comes to mind is extremism. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:43, 28 October 2026 (UTC)
If seeing the word "extreme" in the same paragraph as a mention of brown people makes your mind go to "extremism" when the context very obviously implies nothing of the sort that is a commentary on you, not on me. Athanelar (talk) 21:45, 28 October 2026 (UTC)
Implying that this is because it mentions Telugu people is an aspersion, and an assumption of my thoughts. It would be the same if we were talking about, say, Americans or Brits. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:46, 28 October 2026 (UTC)
I don't think I worded this well, so to clarify: the connotations would still be there if we were talking about any other people, and ethnicity has nothing to do with it. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:47, 28 October 2026 (UTC)
I highly doubt you would still be griping at me if I typed a paragraph about the history of Brits and tea consumption and ended it by saying "the British are among the more extreme end of this spectrum [of tea culture and tea consumption]" Athanelar (talk) 21:51, 28 October 2026 (UTC)
Actually, the first thing that comes to mind here is the American Revolution and the second thing that comes to mind is the slave trade. So yes, I probably would be griping at you here. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:55, 28 October 2026 (UTC)
I lived in an ultra-confederate lost-cause state for nearly a decade. That's why I made that logical leap. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:15, 28 October 2026 (UTC)
So it's your personal bias showing through, as we've pointed out. Not a universal interpretation. ChompyTheGogoat[Bleat|Munched] 22:17, 28 October 2026 (UTC)
It's less personal bias and more lived experience, but yes, I do now agree with your point that this matter is entirely subjective. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:19, 28 October 2026 (UTC)
Bias develops out of lived experience. No one is born with it but we all have them, and it takes constant work to attempt to overcome them - or at least prevent them from affecting your interactions with others. When it comes to marginalized groups listening to what actual members of those groups say is one of the best tools for doing so. ChompyTheGogoat[Bleat|Munched] 22:45, 28 October 2026 (UTC)
That is a fair point, and I agree. What is the relevance of your point about marginalised groups here though? (Sorry about my signature, I'm currently in the middle of changing it)
It's an aspersion to imply I could've meant literally anything untoward based on my word choice in this context. Athanelar (talk) 21:49, 28 October 2026 (UTC)
I'm not saying that, I'm saying that you could have chosen your words more carefully. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:50, 28 October 2026 (UTC)
An assertion which is based on the idea that the words I chose could possibly carry the connotation of "extremism" in this context, which is completely absurd. Bad day to be a fan of extreme sports, for all anyone knows you could be expressing your enthusiasm for Jihadi skateboarding. Athanelar (talk) 21:55, 28 October 2026 (UTC)
Extreme sports is a very idiotic wording and the first thing that comes to mind when you mention extreme sports is getting shot out of a cannon into a volcano. I am generally not a fan of the use of the word extreme as a descriptor unless it is talking about extremism, due to the fact that it contains those connotations of extremism to begin with. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 21:59, 28 October 2026 (UTC)
Sounds like you have an overall problem with the English language. Extreme has been used as a descriptor for a wide range of ideas before "extremism" was known as a specific concept. This is an extreme interpretation. ChompyTheGogoat[Bleat|Munched] 22:14, 28 October 2026 (UTC)
Once again, I do not think I worded this well, so to be more precise, "extreme sports" carries a connotation of violence. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:02, 28 October 2026 (UTC)
Extreme sports do carry a high risk of injury. That's precisely why it's used. And people still love them despite it. ChompyTheGogoat[Bleat|Munched] 22:15, 28 October 2026 (UTC)
Extreme sports have nothing to do with extremism but they bring those connotations to mind anyway. Maybe it's just a quirk of my brain, but synonyms are hard to comprehend to me. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:10, 28 October 2026 (UTC)
Also, "chicken" is not a negative connotation. "extreme" is. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:11, 28 October 2026 (UTC)
Not true! If I called you a "chicken" I'd be calling you a "coward". Does that mean one could conceivably argue that Chicken of the woods might, if you squint at it hard enough, mean "coward of the woods" and therefore if I say "I think chicken of the woods tastes great!" I'm some kind of Klingon who enjoys eating cowards?
I hope you're starting to see my point. In any case I think this discussion ought to end here because we're thoroughly derailing things. I need to move this all down to the appropriate section once it quiets down. Athanelar (talk) 22:13, 28 October 2026 (UTC)
I have heard the word "chicken" used in that context about 4 times before, so I think this is just a case of differences in opinion and perception. But yes, we probably should end this discussion here. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 22:17, 28 October 2026 (UTC)
"People are extremely passionate about this subject" is not a stereotype, nor derogatory. I could make the same remark in regards to many Western topics. The fact that it's racially charged is a significant factor in why it needs to be a CTOP. You wouldn't say people can't refer to ethnicity in a discussion about caste restrictions because it's intrinsic to the entire reason for the discussion. ChompyTheGogoat[Bleat|Munched] 21:28, 28 October 2026 (UTC)
I still don't buy that that is substantially different than "Guy who has seen all 38 Marvel movies" or "audience that claps at the end of a movie" or "screaming Beatles fans." Americans are overwhelmingly patriotic and turn out in mass droves to watch, funnily enough, Tom Cruise flavored military propaganda like Top Gun: Maverick. Indians being hype about home-grown cinema isn't surprising. Super fans are universal. CaptainEekEdits Ho Cap'n!⚓ 20:22, 28 October 2026 (UTC)
And it's certainly not unusual if you compare it to, say, American sports culture (I am an Eagles fan -- we are notoriously violent. Let alone throwing confetti at a screen, we'll throw projectiles at living people.) GreenLipstickLesbian💌🧸 20:29, 28 October 2026 (UTC)
Sure, and if an argument could be made that American sports fanaticism was leading to a lot of UPE and general disruption on Wikipedia then there would probably be a case for a CTOP there. We do after all have a CCTOP on pro wrestling (albeit not ECR) due to the same sort of thing.
The thing is, we probably wouldn't need any specific restrictions in this topic area if we instead had an abundance of editors doing cleanup and making reports for normal AE actions under the CT/SA area. But I think what Sennecaster (I think it was them?) has pointed out about the lack of South Asian cinema-related arbitration reports is a good example of a sort of survivorship bias. We don't see a lot of arbitration reports not because it's not a contentious area, but because there's not a lot of people knowledgeable enough/willing enough to do the required enforcement. Athanelar (talk) 20:38, 28 October 2026 (UTC)
And there are still other cultures that take sports culture much farther, which American fans are often unaware of, because people here can't see past the end of their own nose. ChompyTheGogoat[Bleat|Munched] 21:33, 28 October 2026 (UTC)
Right. Eagles fans are "notoriously violent" for throwing things. Ultras of Glasgow Rangers and Glasgow Celtic are "notoriously violent" because they regularly stab each other when their teams play. Athanelar (talk) 21:44, 28 October 2026 (UTC)
Eek, given the connexions between Indian cinema - not just the actual films themselves, but the entire industry - and caste (the latter of which you know is a perennial powderkeg looking for a lit fuze and is partly responsible for the Indian milhist 500/30) the question is less "Should we institute 500/30?" and more "Are we going to be forced to institute 500/30?" One way or another, I see Indian cinema being put under XCR for the exact same reasonsas Indian milhist. —Jéské Courianov^_^vThrillerNight! 17:01, 26 October 2026 (UTC)
If I were assembling a "how much does it matter that this article is accurate in the real world" tier list, MILHIST articles are A tier in importance, and movies--no disrespect to them--are C or D tier. Movie pages are very popular, and a good way to recruit new users. By shutting out the problem editors, we shut out good editors too. Movies just aren't that important to warrant cutting out such a big portion of our potential editor base. CaptainEekEdits Ho Cap'n!⚓ 19:46, 28 October 2026 (UTC)
See my comment below. I would contend that it's the exact opposite and it's not worth dealing with swarms of UPE/COI for the very small number of good faith editors who might make valuable contributions. It's really not the same as Western film - as Jeske said, almost all of them either have a conflict of interest or are true believers. The vast majority are SPAs with no interest in any editing beyond pushing their POV on these articles, regardless of whether they're getting paid for it. They are not improving the project as a whole. ChompyTheGogoat[Bleat|Munched] 21:48, 28 October 2026 (UTC)
Option C preferred. Option B is fine but this should then be revisited to tell if Option C is warranted. As already discussed by Athanelar and other, the caste issue is inextricable to this topic area and warrants the same treatment as the other topic areas. Οἶδα (talk) 22:05, 25 October 2026 (UTC)
Option A To be quite honest, a restriction this wide on a very active topic area is going to be nigh-impossible to enforce. Yes, there is a lot of UPE editing happening in this very broad area. Yes, there is also a lot of bad editing in this very broad area with new editors not familiar with our policies (or not caring about those policies). Yes, this is a lot of socking in this area that just don't care about Wikipedia policies, they just want their own way. I don't think the other proposals are actually viable. There would be lots and lots and lots of requests for blocks, protections, huge numbers of edit requests that will get ignored for far too long. Ravensfire (talk) 22:52, 25 October 2026 (UTC)
@Ravensfire: While I haven't yet made up my own mind about this proposal (I find both Athanelar and CaptainEek to have persuasive arguments) I would like to note that this rationale could have been used to oppose implementing ECR on Israel/Palestine as well. There were lots of protections requested when that was implemented, but the admins were able to manage it. QuicoleJR (talk|edits) 23:04, 25 October 2026 (UTC)
I think that in terms of the sheer number of articles that exist, this would vastly exceed the number for Israel/Palestine. The number of new articles that get created on a weekly basis is absolutely going to be more than exist in the IP area. Indian films, actors, actresses, directors, producers, music folks. Pakistan films, actors, actresses, directors, producers, music folks. Bangladesh. Television equivalents of all of that. This area is going to be absolutely massive. Ravensfire (talk) 23:40, 25 October 2026 (UTC)
And ECR would quash a lot of that. It's easy to just draftify anything created by non-EC editors - no deeper analysis required. If they keep trying to move back they get blocked. It would take time to work through the backlog, but it's certainly doable. EC editors following protocols can request protection out of the gate so their articles don't devolve. I don't consider "the problem is too big so we should let it continue being a problem" to be as viable argument. ChompyTheGogoat[Bleat|Munched] 07:05, 28 October 2026 (UTC)
Support D->C->B in that order of preference, Oppose A. We should try the least restrictive thing first and see if that works before trying more restrictive options, but let's try something rather than doing nothing. Levivich (talk) 00:18, 26 October 2026 (UTC)
First choice D, second choice A: ACR currently does not exist, but is intriguing (currently, WP:ACR points to Wikipedia:Your first article). I oppose ECR per CaptainEek unless and until it becomes clear that a less draconian restriction does not work. mdm.bla 00:35, 26 October 2026 (UTC)
User:Mdm.Bla, we have something extremely similar to an autoconfirmed restriction in the form of the aggressive semi-protection allowed in WP:GS/PAGEANTS. If a single logged out editor edits a beauty pageant-related page it gets semi'd indefinitely. There's a pretty strong BLP aspect there (especially relating to children) that fuelled it, I believe, although it was adopted before I began editing. Sennecaster (Chat) 17:17, 27 October 2026 (UTC)
Thanks, I didn't know about that! mdm.bla 04:58, 28 October 2026 (UTC)
Option C, Option D as second choice, with the understanding that the concern raised over WP:G5 under Option C (if an article is created in violation of the sanction and then receives significant contributions by autoconfirmed editors post-creation) would be enforced by only considering if there has been post-creation significant contributions by EC editors (otherwise you could just game your way past the restriction). The fact that it is unprecedented doesn't mean much to me since it is essentially just a remix of restrictions that we do already use, rather than some wholly new concept.
I hesitate to go for ECR without having tried something less hefty first. As it means only a tiny handful of readers can edit an article, it should only be used in cases where it is unfeasible to allow articles to go without it. This does appear to be true for certain kinds of Indian cinema articles, but to place the whole of Indian cinema under ECR should require that the whole of Indian cinema needs to be under ECR. I do not think that's been established here. ECR can be applied to those kinds of Indian cinema articles where it seems necessary as part of the WP:STANDARDSET, but for Indian cinema as a whole we should try to go with a lesser restriction first. If that doesn't work we can revisit the matter. –Maltazarianᚾparleyinvestigateᛅ 14:14, 26 October 2026 (UTC)
Option A first choice, D second choice (but see below). Oppose B and C as too heavy-handed. From my experience in RCP and NPP, the problem of disruptive editing and spam in the South Asian film industry area is no worse than that in South Asian (non-film) biographies, companies, politics, sports, etc.; and likewise caste is as intertwined with South Asian cinema as it is with virtually any other topic under CT/SA. (Which is, well, a complex topic and I could write plenty about it; but there's no point in typing out a lengthy essay on that here.)
As such I don't see why South Asian cinema should be specifically singled out for ECR or an autoconfirmed restriction since the arguments used above to justify such a restriction would apply equally well to any other CT/SA subtopic. I wouldn't necessarily be opposed to a blanket autoconfirmed editing restriction on all of CT/SA (though in my experience from RCP this restriction feels a little too severe), but this is not what the RfC is about. ECR wouldn't deal with the UPE problems since most of the organised paid editing syndicates operate accounts with XC anyways, and the non-XC paid editors generally produce blatant spam that can be dealt with without needing anything from the CTOP toolkit. The other disruption for the most part can be dealt with using tools already available under the standard sysop and CTOP toolkits.
I think that a blanket autoconfirmed restriction on South Asian cinema would have more benefits than drawbacks, but it comes off as too broad in scope to me since most of the disruption (as I see it from my experience in RCP and NPP) seems to focus on new or "hot" films (and their crew); famous or controversial films, personalities, etc.; and topics already clearly under the caste and milhist ECRs. Most (>80% I guess) pages in the area get very few edits and don't need protection. A narrower scope for option D which applies only to (for instance) films released in the last 365 days and their crew would be fine with me. JavaHurricane 17:02, 26 October 2026 (UTC)
Option A first choice, D second choice. South Asia movie/music scene is too large to have such tight restrictions. Many new editors from the region may be interested in editing the movies, and imposing a 500/30 restriction would be too harsh for them, killing the incentives to be an editor. In my opinion, South Asia move scene is less controversial and explosive when compared to other contentious topics such as the Israel/Palestine issues, and we still have WP:CT/SA to if manners escalate to nationalism or caste issues. If the goal is to prevent LLM-made article, that job is for the WP:NPP instead of creating another restriction. We can also try to narrow the scope of the restriction - maybe only restrict movies that have racist/caste issues undertones? ✠SunDawn✠Contact me! 17:30, 26 October 2026 (UTC)
A large number of those "new editors" are UPE (who may not actually be new), and the vast majority never contribute in any other subject areas. TAs and SPAs abound. Getting drawn into editing in general and becoming a constructive editor who follows P&Gs is exceedingly rare. I've advised others who at least attempt to comply to try editing elsewhere to gain experience and reach EC, and it falls on deaf ears. They don't care about anything else. ChompyTheGogoat[Bleat|Munched] 05:17, 28 October 2026 (UTC)
Option A per Java Hurricane and SunDawn. Bad faith editors can easily game EC and AC, so the people most affected by these editing restrictions are potential new editors, the very group the community keeps saying that we need more of. Some1 (talk) 03:00, 27 October 2026 (UTC)
Option A for now. I'm open to ideas about restricting article creation in parts of WP:CT/SA bc of high rates of LLM/UPE/socking, but I am unconvinced by the AC editing restriction, especially for South Asian cinema, which likely has way more good faith editors than other subtopics like South Asian incorporated entities (businesses, schools, etc.) NicheSports (talk) 18:30, 27 October 2026 (UTC)
I support an ECR article creation restriction, but oppose any general restriction on editing. South Asian films are a hugely popular area for casual editors and are some of our most viewed articles. A general autoconfirmed restriction would lock out huge numbers of casual editors, while doing little to prevent the determined abuse and sockpuppetry these proposals are aimed at. OTOH, an ECR restriction on new article creation may have an impact on the widespread promotional/UPE sockpuppetry focused on boosting non-notable actors, films, and other topics in this area, while having minimal impact on casual editors interested in what they're seeing in the cinema or in the news. Toadspike[Talk] 01:45, 28 October 2026 (UTC)
'Status quo, strongly oppose putting the area under an ECR restriction; our top-viewed and edited articles on the website are often South Asian-cinema related. If we're going to block off casual and new editors from incredibly popular topics, there needs to be a good reason. The editing around most entertainment topics, especially fandom related, is pretty universally shit -- and I spend enough time cleaning up after UPEs and awful editors in the film world to know that the South Asian topic area isn't actually that worse than, say, the American or European industries. GreenLipstickLesbian💌🧸 06:40, 28 October 2026 (UTC)
But the latter are actually policed. They don't make any headway. ChompyTheGogoat[Bleat|Munched] 07:06, 28 October 2026 (UTC)
LMFAO no. Sorry, but.... no. They are not policed effectively. GreenLipstickLesbian💌🧸 07:13, 28 October 2026 (UTC)
Sorry if that came off a bit sharp, but I've removed too many decades old press releases copy-pasted in to articles by administrators to do anything other than laugh at the idea that this is effectively moderated. GreenLipstickLesbian💌🧸 07:17, 28 October 2026 (UTC)
It is in relation to the topic area under discussion. You saw the problem and removed it, because you are part of that moderation. Indian cinema has minimal enforcement of any kind. ChompyTheGogoat[Bleat|Munched] 07:26, 28 October 2026 (UTC)
By that standard, we'll only know in 10 to 15 years whether or not the moderation is the same. GreenLipstickLesbian💌🧸 07:50, 28 October 2026 (UTC)
Huh? The topic has already existed for years and gone largely unmonitored. It won't take long to see whether or not restrictions start having an impact on new additions. Heck, even working RCP it ought to be noticeable once enough protections are applied that they start popping up less often via the various tools. Newer articles won't have pages of edits by TAs and redlink users with zero edit summaries that make it difficult to even track down where the problems are.I've never pulled up an article for a Western show/movie and immediately thought "Wow, this is barely even intelligible". Some of them certainly need improvement and yes, there can be sourcing issues, but it's just not on the same level. Even Fandom insertions are better quality. Can you imagine a recent Hollywood blockbuster with entire sections totally unsourced? (Casting is hardly ever sourced, so there's no easy way to check whether an addition is legitimate or a UPE trying to claim a false credit for their client.)Old articles being allowed to languish in a subpar state isn't unusual in any subject area, and not the main issue here. No one will ever get around to working on those when newer ones are so rife with bad edits. ChompyTheGogoat[Bleat|Munched] 09:31, 28 October 2026 (UTC)
You're telling me I'm "part of that moderation" because I'm removing ancient issues which slipped past RCP because admins added it; I'm going to say that, if you're judging whether or not moderation of an area is successful by whether issues survive over two decades, by the metric you set for me and Western shows, we're going to have to wait a very long while to see if this works.
I am afraid I have to disagree with you on your second point too I spend most of my time looking at old articles in subpar states; I can safely say that, speaking from experience, entertainment articles are, across the board, much worse than any other group. They get a flurry of edits when the show or movie first comes out, from fans and PR people alike, then they sit in that state forever. Sometimes fans hang out and add fancruft, copied from fandom (which was copied directly from the marketing department and laundered through Fandom half the time so, no, not better than UPE in any meaningful way.) No industry is unique for that -- Kdramas, Masala films, MCU blockbusters. Don't believe me? check my edit history. Or, do as you suggested and spend some time actually working cleanup in this subject area to see just how extensive the problem is. GreenLipstickLesbian💌🧸 10:19, 28 October 2026 (UTC)
I will not be working any areas ever because my contributions don't appear to be welcome on Wikipedia. But what your describing isn't remotely close to the issues in the Indian cinema subject area. At all. The fact that fandom content is still better than many of these despite how problematic it is was my point. ChompyTheGogoat[Bleat|Munched] 11:10, 28 October 2026 (UTC)
No, Fandom content is not better -- if anything, I've found it's much, much, much harder to clean up because, again, the spam has been laundered and divorced from many of the obvious flags that RCPs like yourself check for when spam hunting. But I'm afraid we'll have to agree to disagree -- funnily enough, I checked the date your account was registered, and I was actually working on cleaning up my favourite spammy Manipuri film industry sock farm that very same week. I'm not big on metaphors, but I think this is the equivalent of teaching your... well, not grandmother, so let's just say your big sister to suck eggs. GreenLipstickLesbian💌🧸 11:58, 28 October 2026 (UTC)
Would you two mind if I move this conversation under the "Discussion" heading? It's a bit lengthy and tangential for the survey section. Athanelar (talk) 12:06, 28 October 2026 (UTC)
Option B as first choice. Descending options C->D after that. Every time I see anything on an Indian film on this project it's either because there's an edit war over box office figures or it's because there's an edit war over its interface with Indian politics. I think we need to treat this as an integral part of a contentious topic and keep it as locked down to responsible editors as possible. We should also consider excluding box office figures from infoboxes as a matter of policy (not just for Indian cinema) and only discussing box office figures when such are well sourced and encyclopedically relevant. Simonm223 (talk) 11:30, 28 October 2026 (UTC)
I would happily ban all box office stats unless mentioned in depth in reliable sources, across all cinema -- even in this topic area, the sources the regulars revert to (Bollywood Hungama) are not particularly better than the ones they revert out with a high degree of aggression and warnings (Sacnilk, and every source which sites it). Like the victor parameter in the infobox conflict, it just causes more strife and edit warring than good editing. GreenLipstickLesbian💌🧸 12:02, 28 October 2026 (UTC)
Wildcard, devil's advocate proposal (and sorry if this is already what you mean by this!): we could just ban box office figures in general unless it's a significant part of the notability and discussion surrounding the film (like Avatar's remarkable box office success), since otherwise it's really not important to an encyclopedia, right? This'd have to be a separate discussion, but I think I'd probably be in favour of a moratorium on box office figures in film articles. Athanelar (talk) 12:09, 28 October 2026 (UTC)
I'd support that in theory, but it's only viable if we do achieve ECR. Otherwise it's easier to allow them from accepted sources than spend even more time fighting all insertions instead of just the ones that aren't adequately supported, which is hard enough. People get pissed when I get protection on an article and they can't continue to update it every five minutes. And @GreenLipstickLesbian as I've already mentioned we've attempted to initiate reviews of the different sources to no avail. I agree that BH doesn't seem particularly more reliable than others to me based on what I've read and I asked for them to be objectively evaluated based on firm criteria rather than just vibes, but until and unless that occurred I followed established consensus, as do the others monitoring those articles. So once again, the lack of input from experienced editors without bias is the underlying problem. (I think I'm the only one who's actually gone through and read the previous discussions leading to the current designations, and they do not inspire confidence.) ChompyTheGogoat[Bleat|Munched] 22:03, 28 October 2026 (UTC)
This is part of why I want to put ECR on this - I think restricting access to editors who have been around long enough to, in theory, have learned "don't put box office figures in an infobox" is needed to prevent edit wars over box office figures. Simonm223 (talk) 12:19, 29 October 2026 (UTC)
I would somewhat oppose full ECR restrictions; I believe that should be reserved for the most controversial topics when truly necessary. While South Asian cinema definitely has ties to the restricted topic; I doubt that it belongs at the same severity. So I would support C or D. There are a few autoconfirmed users who cause trouble, so I can understand the B position; but I'm not sure if it's enough to warrant it. Dawn Lim (talk) 11:38, 28 October 2026 (UTC)
Option A have seen no evidence that Indian cinema is so far worse than the rest of CT/SA that additional restrictions are warranted. ~~ AirshipJungleman29 (talk) 12:19, 28 October 2026 (UTC)
Support B > C > D. This is a very UPE spam and copyvio prone topic, so much so it's as if an entire cohort of editors doesn't know what a good article looks like. I consider the entire topic a no-go area. MER-C 19:20, 28 October 2026 (UTC)
Option B - This topic sees the most disruption, sockfarms and UPE in CT/SA. It should be placed under ECR. Zalaraz (talk) 00:56, 29 October 2026 (UTC)
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)
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).
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é Courianov^_^vThrillerNight! 06:22, 20 October 2026 (UTC)
Both are intrinsically linked to caste, Huh? That's entirely false. I'm fairly certain that the scores of WP:UPE editors in the Indian cinema topic area are not motivated purely by nationalistic or caste-specific sentiment. You do get the odd film that flares nationalistic rhetoric (for example Dhurandhar: The Revenge) but tbh that is not significant enough to require a special carveout, SASG and IMH are good enough for those. The problem that it looks like we are trying to solve is UPE Sohom (talk) 08:55, 26 October 2026 (UTC)
@F0malhaut42 and @Athanelar There might be underlying caste lines in the Telegu industry but those are not the ones that have seen the most problems onwiki. For what it's worth, the WP:UPE disruption is not confined to just the Telegu film industry. UPE disruption exists in the Tamil industry, Telegu industry, the Bengali film industry, the Hindi one and potentially even the Punjabi one. The constant and primary disruption factor onwiki is WP:UPE, not motivated editing (which would require significantly different considerations) denoted by the fact that that most of the reports related to disruption show up on WP:SPI and not WP:AE and are typically less about POV-pushing of specific caste-associated sets of movies (obviously we ignore the SASG specific ones like Dhurandar that are already covered by ECR) Sohom (talk) 00:53, 27 October 2026 (UTC)
It's both. There are tons of disruptive editors who can't be taken to SPI because a bunch of unsourced insertions with no edit summaries or attempts to communicate leave no proof either way. I've been accused of bias numerous times for blocking such changes. There's nothing to take to AE because the current restrictions are too vague to apply to this problem. If they did we wouldn't need to implement additional ones. ChompyTheGogoat[Bleat|Munched] 23:35, 27 October 2026 (UTC)
FYI for those participating in the discussion: I think the best way to go about this is that after a couple more days of discussion, if there is consensus (and there does seem to be) to designate a CTOP here and impose ECR on that topic, then I'll open a subsection here for an RfC on that question so that more people can be notified and we can get a robust consensus. If anyone disagrees with that approach, please do say so.
Based on what's been said so far, these are my proposed RfC prompts;
A. Status quo: South Asian cinema remains under the broader WP:CT/SA but is not subject to specific subtopic restrictions
B. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA and placed under the extended-confirmed restriction.
C. South Asian cinema, broadly construed, is noted as a subtopic of CT/SA. Article creation is restricted to editors with extended-confirmed permissions. The topic area as a whole is placed under autoconfirmed restriction. (not sure if autoconfirmed restriction has precedent?)
Please give feedback/workshop these however you think necessary.
N.B., "South Asian cinema, broadly construed" includes films as well as all associated cast and crew including musical directors, musicians and playback singers primarily working in film, and is specifically inclusive of India, Pakistan, Bangladesh and Sri Lanka. Athanelar (talk) 06:46, 20 October 2026 (UTC)
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)
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, Rosguilltalk 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)
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)
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)
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)
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)
Post RfC start discussion
What kind of enforcement actions are available and aren't working? Indian cinema rarely escalates to the arbitration enforcement noticeboard; is this a lack of capacity (awareness of CTOPs, energy to do so, confidence to do so), range hopping TAs, mostly handled by non-CTOP admin actions, etc? Is this mostly getting reported to SPI, ANEW, and RfPP? Is this appearing at AN/ANI, and if so, what are those threads like?
Looking at a few recent protections from the protection log; Dalit Film and Cultural Festival under CT/CASTE, Fighter (2024 film) under IMH, Jailer 2 (1 year ECP, no subtopic), Achhut Kannya (no subtopic). Most people are getting blocked/topic banned for subpar conduct in CASTE or IMH or modern politics (check WP:AELOG for yourself to be sure, but I've read or participated in almost all cases in the last year and definitely in CT/SA). It's hard picking out the cinema related ones from the protection log alone, but it's not as frequent as other CT/SA protection clusters. The main clusters I am aware of are modern politics and political parties, castes, and military history. As for why I'm asking, characterizing how disruption is currently being handled helps a lot in understanding what we are struggling with. I don't go out of AE and AN very often, my main area is copyright after all, and I would imagine that this will also draw people that are unfamiliar with the scope of enforcement entirely. Sennecaster (Chat) 17:37, 27 October 2026 (UTC)
In my anecdotal experience we've had a lot of film-adjacent articles come through AfC in some form or another with UPEs, socks, etc. One which springs to mind is Mission C2000 which was tendentiously created and recreated under lots of different titles by Alakmarsaify socks. Admittedly I've never dived much into cleaning up the topic area myself because what I have seen of it at AfC has really kept me at bay. @ChompyTheGogoat is probably in a better position to call up some specific examples since they were recently doing cleanup. Athanelar (talk) 22:59, 27 October 2026 (UTC)
There's not enough enforcement period. Most of it goes through SPI or ANI when someone (usually me) actually bothers. The current CT/SA restrictions don't apply to this subject area, and most editors just drop whatever insertion they feel like with little to no sourcing and no communication, primarily from TAs or low count named SPAs.Anyone who thinks we shouldn't need additional restrictions should spend some time actually working cleanup in this subject area to see just how extensive the problem is and why current remedies aren't sufficient. I just ran an editor to ANI with 2500 edits over multiple years, compromised almost entirely of unsourced or poorly source additions to this subject area. They had 18 warnings (and an additional dozen miscellaneous TP messages) that they ignored. All of those other editors were content to drop drive-by templates and move on without actually addressing the problem - and it's far from the only case. Even under ECR we'd have to work through grandfathered editors like this, but "difficult to enforce" is not a viable excuse for not implementing restrictions - otherwise why have restrictions at all? At least this would give enforcement some teeth. Widespread ECP and a low bar for blocks would have a huge impact. The problem has been allowed to build up for years and it will not be handled without additional restrictions. Milder sanctions might have been sufficient if it had been addressed sooner, but that ship has sailed. Whatever is decided, you can deal with it without me. Or don't. Keep letting it fester. I'm washing my hands of it regardless. I'm done being the only person who cares. ChompyTheGogoat[Bleat|Munched] 23:46, 27 October 2026 (UTC)
ChompyTheGogoat, you sound dangerously close to total burnout. Maybe you're already there. Someone else will pick up that cleanup work later. Anecdotally, I've been doing copyright nonstop for 3 1/2 year straight, and then have done arbitration enforcement for 2 years straight. I am burnt out. I don't have capacity to report or handle everything even in copyright. That's okay though. I completely understand your frustrated, I have had extremely similar moments, but I am not here to be your "enemy" or to say that there's no need for action here. I'm trying to figure out what specifically needs to be targeted, whether or not any proposal here gains consensus or not. Okay, we need to get the AFC people more involved in identifying socking/UPE and escalating. That is doable. Okay, maybe we need to get RCPers using more semi-auto tools that make reporting a lot easier. EditCheck should hopefully be helping, but if it's not we need to know and the people that do this are not omnipresent and not high in number. There's a lot of people here that are interested in stopping disruption and frequently work arb enforcement, so you're speaking to people that do not have experience in this specific topic. I don't do AFC. I don't do SPI, and a lot of my wiki-friends are SPI but only think of it from the UPE and socking perspective. None of us are saying that there isn't an issue. The people that are familiar here are administratively conflicted out in a lot of ways, or don't want to open themselves up to the very real risk of harassment. We are asking in good faith because we want to know what we can do in the meantime. We're aware of the issues now, we can do something about it.WP:CT/SA covers all of South Asia, broadly construed. It covers Indian cinema. What you're experiencing is the very real reality in that CTOP enforcement is incredibly stretched thin and simply do not patrol that topic enough. I don't appreciate All of those other editors were content to drop drive-by templates and move on without actually addressing the problem - and it's far from the only case.'s lack of good faith, so I really do ask that you step back before you say anything you regret. I get the burnout. I really do. I have spent a lot of time arguing with people that they can't add copyright violations back. But it doesn't give you the right to take that frustration out on others, and not on people that aren't familiar with the issue because that isn't their expertise or interest. It's the reality of wiki work that we have different things, and that we get burnt out and frustrated, but we have to emphasize and understand each other despite that. Sennecaster (Chat) 03:57, 28 October 2026 (UTC)
Horse, barn door. I tried giving myself a break by working on another topic area that I'm passionate about and got accused of LLM use after spending hours hand writing an entire article, so when I say I'm done, I'm done. It really doesn't matter what other editors think of me at this point.Someone else will pick up that cleanup work later. If that was true we wouldn't be in this situation in the first place. Editors have spent years ignoring the problem, as Jeske said below. And when I said All of those other editors were content to drop drive-by templates and move on without actually addressing the problemthat is literally what happened. Eighteen editors dropped templates and ran, without looking at the pile that had already gone unanswered or bothering to file at any noticeboards. For years. That is a fact, not hyperbole. It is not the only such case that I've filed. So yeah, when the people who have no experience in this subject area still think they're qualified to drop a !vote claiming we don't need to make any substantial changes, I take issue with it (and yes, some are saying that). They're free to abstain if they don't have the relevant experience to give an informed opinion. I also have no prior experience or interest in the topic. I stumbled across it and saw a problem that no one else was stepping up to deal with, so I did. Or at least tried. And it's no wonder no one wants to do it. It's incredibly thankless work - it's one thing getting harassed by the POV pushers that are causing the problem, and quite another when other experienced editors patrolling noticeboards are more worried about the formatting of my reports than the actual problem I'm reporting. You want to know why people are hesitant to report? That's why. Too much infighting and pedantry; not enough concern for the actual damage being done to the project. I'm highly disappointed in this community overall, and with AI hoards at the walls - now including fully autonomous agents - I don't think you'll be able to hold out for long while competent editors are being chased off. Even veteran editors of 20+ years are giving up in frustration, and I can understand why. Guess I waited too long to sign up. ChompyTheGogoat[Bleat|Munched] 05:04, 28 October 2026 (UTC)
I understand you're frustrated, but it's very likely that some of those 18 editors have their own overwhelming backlogs of work. Like with me for example, I almost definitely have flagged some Indian cinema articles for AI (if there is AI) instead of dropping everything to go fix it, because I am currently about 200 tabs deep in other unfinished AI cleanup and I do not have the time. There are a finite amount of hours in the day.
And if you mean userpage warnings, what more exactly are people supposed to do? Stand outside their window with a boombox? You can't force someone to change their behavior. Gnomingstuff (talk) 02:58, 29 October 2026 (UTC)
I think the point Chompy's making is that that's exactly why we need restrictions in this topic area. People obviously don't have the time or interest to dedicate to cleaning up this topic area, reporting editors and pages for arbitration remedies, etc. It's not that any of those 18 editors should've dropped what they were doing and solved the problem themselves, it's just that if we don't have the interested and able editor-power to do it, then we need another solution. Athanelar (talk) 03:10, 29 October 2026 (UTC)
Yes, the warnings. That's why we have noticeboards. Sanctions are a thing. Most of the ones I've taken the time to report do get blocked, and there would be much less disruption if others had bothered to do so sooner. The time it takes to file said reports is far less than the cleanup that's now needed for all those thousands of edits. I refuse to believe that all 18 editors (and all of the others who dropped additional messages there, or other warnings on other editors) were so very busy in that exact moment that they couldn't possibly take the time to compile a few diffs. Other types of disruption in other subject areas get addressed far more quickly.So, if people aren't willing to address the huge number of problematic editors on a case by case basis, we instead need sweeping restrictions that will stop the vast majority of them, even if a few good faith also get caught up in the net. Page protections are one of the best tools we have for preventing ongoing distribution with minimal effort, and the sooner they can be applied in subject areas that are rife with these issues the less needs to be fixed. ChompyTheGogoat[Bleat|Munched] 03:37, 29 October 2026 (UTC)
Other types of disruption in other subject areas get addressed far more quickly.
This feels like the thing (and I've probably done it too) where a person is so focused on putting out a metaphorical fire in their room that they don't notice that the rest of the house is also on fire. Every part of Wikipedia is falling apart. I'm familiar with the amount of squabbling that goes on with film articles (since I have to slog through the hundreds of drive-by talk page comments per month that just say "Box office"), and even that is nothing compared to the dozens of backlogs of hundreds of thousands of articles needing maintenance.
As far as sanctions go, it's emotionally exhausting enough to even create one noticeboard report, and I don't blame anyone who just doesn't have it in them. Gnomingstuff (talk) 12:50, 29 October 2026 (UTC)
Yep - even with ECR it'll take some dedicated editors with no vested interest who are willing to roll up their sleeves for the overall integrity of the project to really get a handle on things. I think once the current swarms who feel like they have free rein to insert whatever they feel like realize that won't fly anymore things will simmer down and be easier to maintain - but that works needs to happen first or it will just continue to snowball. Good luck. ChompyTheGogoat[Bleat|Munched] 05:09, 28 October 2026 (UTC)
Hence my linking catch-22 above. I think it's safe to say the issues are threefold:
Nobody with experience is familiar enough with Indian culture and how it interacts with cinema, especially where caste is involved. This makes them incompetent, through barely any fault of their own, to actually edit in and administer the topic area. Those who are knowledgeable about the subject matter are vastly outnumbered and overwhelmed.
Few/none of the new users entering the area are willing or able to treat Wikipedia as anything more than an extension of Indian media, and almost all of them either have a conflict of interest or are true believers.
The topic area is in an intractible ethnopolitical hellhole CTOP and tends to be connected to two potent third rails in that hellhole (caste and politics). This makes experienced users even more reluctant to touch the topic area and sets up new users for failure (CTs are the worst places to learn to edit; the intractible ethnopolitical hellholes especially so).
The ways to fix this would require, at a minimum, ECR in the immediate term. This is a very similar blend to the situation that caused WP:ARBPIA3 to happen. Once that is set up, and the firehose of edits to the area is slowed to a more manageable amount, there needs to be a community-wide effort to assess the articles for neutrality and COI concerns, with anything failing the test being sent to AfD if they cannot be improved. Anyone trying to disrupt this with nationalist, LLM, or COI bullshit needs to be at minimum topic-banned from the cinema topic area. Anyone evading these bans needs to be indef'd and restricted to one account, if that is possible as a discretionary sanction. (For anyone thinking about what precedent I'm looking at, SCI and MM are moreso what I'm looking at than any of the 17 PIA cases.) If this disruption continues despite everything, haul the mess to ArbCom, with an eye primarily towards amending CT/SA to make ECR de jure in the topic area indefinitely. —Jéské Courianov^_^vThrillerNight! 06:52, 28 October 2026 (UTC)
@Jéské Couriano; I appreciate the clarification. Unfortunately, my experience over at CCI tells me that community cleanup efforts are vastly outpaced by the pace of crap added or the size of things to review without serious political and social capital. Doug Coldwell's whole pile of crap GAs isn't even fully cleaned up yet. A lot of what you're saying about CT restrictions, but we have a critical lack of capacity that is making everything worse. Treating admins poorly will not help the issue (I'm not accusing anyone, but it is a fear expressed to me). I just don't know what we can do that doesn't amount to "bully administrators into doing things they actively resent doing", since we have always been hesitant to elect admins focused heavily in "experienced user conduct" (a phrase from my own RFA).
As for cleanup: Chunking down Indian cinema to specific subtopics (ie. telugu films, marathi TV) with aggressive presumptive removals would lead to less reviewer/community burnout. It could also be turned into an editathon or drive. This level that's being described means that something much more drastic than a methodical combing and AFD can resolve without exhausting significant portions of the community. Despite my criticisms and counter-suggestions, there's a lot of good ideas here, and I think I know some things that I can angle people with more capacity than myself to get started on regardless of the outcome here. I myself am not experienced enough with background conflicts to admin fully in CT/SA, like you've described. I can handle blatant POV pushing and caste warring, but I've had to call in help from multiple sources both wiki editors and not to even begin on trickier reports. It's an issue and the more that you know here, the more you're likely to end up WP:INVOLVED. Sennecaster (Chat) 22:55, 28 October 2026 (UTC)
I would imagine the scope of the issue would more or less mandate that the subtopic be further broken up into further subtopics in order to actually deal with it. "Indian cinema" is the sort of overly-large topic area that ArbCom themselves comments about at WP:ARBIMH#Breadth of topic bans, and experiences with one subset of it don't necessarily translate well to other subsets (h/t Athanelar). The editathon/drive idea would certainly help as well (to get out in front of "how about AFI?", that to me seems more of a mixed bag, but it'd be worth a try for some of the lesser-known articles in the area that haven't drawn mercs or zealots), but this would fall into the same issue of anyone not "read in" being driven off by mercenaries and "true fans". Hence I think there would need to be an ECR in order for us to even entertain any such cleanup. The other alternative is going scorched-earth on users in the topic area to get rid of the UPEs, and that's counter-productive and would be a waste of admin time even if it weren't. —Jéské Courianov^_^vThrillerNight! 00:39, 29 October 2026 (UTC)
I was thinking that setting up a tracker within the task force page could be helpful with cleanup - after restrictions are in place, because people will absolutely get driven off if they attempt it now (hi). Having a system to mark what's been reviewed, tagged, nominated for deletion, etc would help give a visual representation of progress and motivate people because they could see that even small contributions can move the needle. Maybe a bot could move pages through in batches to address the backlog in a format that feels manageable. ChompyTheGogoat[Bleat|Munched] 01:02, 29 October 2026 (UTC)
That would help, but the overall scope is the bugbear here. Going through it one subtopic at a time is still going to be the best way to handle this. This is an issue that has been festering for years; a quick fix at this point is unrealistic. —Jéské Courianov^_^vThrillerNight! 01:44, 29 October 2026 (UTC)
Oh, I know. That's just one idea that could potentially help with working through content. Restrictions and above all willing editors are necessary if any progress is going to be made at all. ChompyTheGogoat[Bleat|Munched] 02:59, 29 October 2026 (UTC)
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.
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.
Add Wikipedia:sandbox (WP:TEST) to Main Page, Main menu, or Page Tools
The sandbox is so hidden and useful to me when I was a newcomer for learning how to use Wikipedia. I think Wikipedia can create at least a link or a button for sandbox at an obvious spot or at least somewhere. ~2026-56952-03 (talk) 11:05, 24 October 2026 (UTC)
Looking at the main page in Vector2022 (the default skin) I agree there is no clear link to any sandbox, registered editors do see a link to their personal sandbox but it's in a dropdown menu behind a non-intuitive icon (in my preferred monobook skin there is a prominent link to your personal sandbox at the top of the page), and in the sidebar a semi-prominent "Learn to edit" link to Help:Introduction, but again no link to a sandbox. Now I'm aware of this, it does seem like an omission. Thryduulf (talk) 20:04, 24 October 2026 (UTC)
English Wikipedia HomePage 2001-02-19
the missing sandbox was a thing tho, rip ~2026-56947-61 (talk) 22:33, 24 October 2026 (UTC)
I like the idea of making the sandbox highly visible to readers, probably on the main page. Let them play with the editor in a safe environment. Though I wonder how it would handle a significant increase in traffic and edits. Thebiguglyalien (talk) 02:13, 26 October 2026 (UTC)
This is a good idea. Maybe the Sandbox could be linked inside of {{Article for improvement}} like this:
If there is agreement on giving greater prominence to a sandbox, I think the user's sandbox would be better. It would avoid conflicts with other editors, not get reset periodically, and perhaps (with a bit more guidance) help new users learn about user subpages. isaacl (talk) 19:12, 26 October 2026 (UTC)
Agreed, though beware that Special:MyPage/Sandbox redirects logged-out users to the login page rather than a usable sandbox. Certes (talk) 19:35, 26 October 2026 (UTC)
this would be a good idea, but it wouldn't work for users without an account. temporary accounts work, but you need to edit a page first to make one - perhaps we could switch the link for users with an account? Rexo (talk|contributions) 19:53, 26 October 2026 (UTC)
This could be solved by linking to the sandbox using the following text: {{If IP|1=[[Wikipedia:Sandbox|Sandbox]]|2=[[Special:MyPage/sandbox|Sandbox]]}}. This template renders as SandboxSandbox and links to your sandbox if logged in, and the global sandbox if logged out/TA. mdm.bla 20:17, 26 October 2026 (UTC)
So as to not confuse people, I think it should say "your personal sandbox" for logged in users. ScienceD90 (she/her) (talk) 02:33, 27 October 2026 (UTC)
That sounds like the best way to link it! Not as sure about tying it to TWAFI (which also restricts it to just the Main Page, which some users might not visit, instead of a more accessible sidebar), but that still makes sense. Chaotic Enby (in solidarity · talk · contribs) 18:02, 27 October 2026 (UTC)
This seems like the most logical place for a link to the sandbox. – The Grid (talk) 19:26, 26 October 2026 (UTC)
On a DYK article's Talk page, remove the Do not modify this page notice from the Talk page's DYK Nomination section
note: to see an example of the current state of what causes the problem
Go to the Wikipedia Main Page.
Select any of the articles in today's DYK list.
Look at that article's own Talk page.
This numbered sequence of successive events illustrates how the problem happens:
An article is nominated to be included on the Wikipedia Main Page article list Did You Know...?
The article has a Talk page (Talk_A).
In a different place, there is a DYK Nomination discussion of the article.
The DYK Nomination discussion (Talk_N) ends.
Talk_N receives a header that says Do not modify this page (intended to prevent the modification of Talk_N).
Talk_N is reproduced as a section on Talk_A.
Now, Talk_A has a section that says Do not modify this page (intended to prevent the modification of Talk_N).
Eventually, Talk_A needs to be modified.
A user (User_A) who needs to modify Talk_A sees a section of Talk_A (described in 6. above) that says Do not modify this page (intended to prevent the modification of Talk_N).
User_A understands this prohibition (against the modification of Talk_N) to mean that modification of Talk_A is forbidden.
User_A leaves Talk_A unmodified for the sake of obeying the directive that had forbidden modification of Talk_N.
A confusing message has prevented User_A from accomplishing Wikipedia's mission; this is a serious problem.
Let's fix this problem! —catsmoketalk 05:18, 27 October 2026 (UTC)
@Catsmoke I made this edit to {{DYK top}} so that on talk pages it will say "Do not modify this section" instead of "this page". That won't fix existing pages, but it should fix it for ones created in the future. A bot task would be needed to fix existing ones by running through the 78,000 subpages at Special:PrefixIndex/Template:Did_you_know_nominations/ and replacing page with {{talk other|section|page}} -- you can request one at WP:BOTREQ. --Ahecht (TALK PAGE) 17:16, 27 October 2026 (UTC)
I feel kind of weary transcluding {{talk other}} so many times. Couldn't this be achieved with <noinclude> tags? Axolitl(talk|contribs) 23:43, 27 October 2026 (UTC)
Or alternatively, something like "Please don't modify the nomination"? Axolitl(talk|contribs) 23:45, 27 October 2026 (UTC)
Apple
I belive that searching up "Apple" should take you do a disambiguation page, showing both Apple Inc. and Apple, as in the fruit. Both are very common topics, and I belive neither should have a primary position.
Yes, Apple has trillions of dollars. But, the fruit is often more common in daily conversation. ThejimsterF (talk) 08:59, 27 October 2026 (UTC)
ThejimsterF Nothing wrong with coming here, but this is probably best discussed at Talk:Apple. I'd suggest that you review the several prior discussions on this very topic(linked to at the top of the talk page) before proceeding with such a discussion. 331dot (talk) 09:09, 27 October 2026 (UTC)
Per the Q&A on the Apple talk page, "In at least 6 move discussions (see the list below) on this page, Wikipedia editors have determined that the fruit is the primary topic, so disambiguation is not required.". So it seems like this has been discussed and settled. I'm not sure how long it's been though, or if circumstances have changed. Icandostuff! (talk) 21:16, 28 October 2026 (UTC)
25th Anniversary Logo
I propose temporarily changing the Wikipedia logo for the 25th anniversary to be the one shown above. As you can see on this page, it is an unofficial logo for the 25th anniversary.
The actual website has a different logo, which only has the wordmark and a puzzle piece with "25" written above it.
The reason is that the logo is very iconic and should be kept. It symbolizes what the standard globe already symbolizes (the diversity and evolution of Wikipedia), but it also acknowledges the 25 years of Wikipedia's existence.
Some language versions like the German Wikipedia use a similar logo.
This is temporary (until January 15th, 2027), only affects the English Wikipedia, and would replace the current wordmark logo. Koubaki (talk) 14:57, 27 October 2026 (UTC)
We've already changed it to wikipedia-wordmark-en-25.svg in the vector2022 (desktop default) and minerva (mobile default) skins and the exact logo you posted in the vector2010 (desktop default prior to 2022) skin. This is consistent with vector2022 and minerva using the wordmark in place of the globe logo. --Ahecht (TALK PAGE) 16:41, 27 October 2026 (UTC)
As you can see here on Vector 2022 before the 25th anniversary there was a globe. Koubaki (talk) 19:21, 27 October 2026 (UTC)
I believe we went with the horizontal wordmark as it was one of the default options created by the WMF. It allows the tagline to stretch along the entire image. de.wiki gets lucky because its tagline doesn't need "of the". CMD (talk) 22:42, 27 October 2026 (UTC)
That's probably why the logo I'm proposing uses "Celebrating 25 years" as its tagline. Koubaki (talk) 10:13, 28 October 2026 (UTC)
Idea lab
AI-assisted search
While AI is terrible for writing articles or as a source of information, I think it could be very useful for performing advanced searchs in Wikipedia (and other Wikimedia projects). Many information in Wikipedia about a particular topic is disperse across several articles (many of them unrelated), and I think AI could be useful to find all the information related about a particular advanced search. The key points of my idea are:
Wikipedia is losing visits because of AI. While Wikipedia is not a business and its main goal is not to maximize the number of visits, many Wikipedians are worried about this. If Wikipedia makes use of AI, the people who go where there is AI because it's cool, would also come to Wikipedia (they wouldn't see Wikipedia as an old-fashioned site where AI is not present at all, but as a modern cool one). Another reason why more serious, conscious people can be making use of AI in place of Wikipedia is the ability to perform advanced queries and get links to reliable websites in a quicker way than they would with Wikipedia (or with a traditional search engine). If Wikipedia provides this ability, in combination with its human-reviewed, extense articles, it can be an absolute winner.
Full respect to people who reject use of AI. Wikipedia is not anti-AI, but people who don't want to use AI at all must remain free to keep doing so. The current search box must continue working without any LLM AI.
Any used software, including the LLM, must be freely licensed. All such software (LLM included) should be run at WMF's infrastructure.
An AI button would be shown at the right of Wikipedia's search box. From there, the user would be able to perform advanced searches using natural language. The button should be present in all Wikipedia editions in languages supported by the LLM, and maybe also in other Wikimedia wikis.
The AI must have restrictions in place so it can't be used for any purpose that is not the search of information in Wikipedia or other Wikimedia sites.
The search results can include Wikipedia articles, Wikivoyage travel guides, books at Wikisource, images, videos or PDF books at Wikimedia Commons, etc. All of them in any language, with machine translation being used when convenient. The results could also be a specific section or subsection of any of these wiki pages. Unlike a "normal" search, the search results would not be a simple list of links, but a coherent text that presents them in a way that is easy to understand by the user.
The AI should generate the shorter possible response in natural language. The important part of the response would be the search results: the generated text would be mostly for putting the different results together, and for providing context to the user, but the generated text should never be provided in a way that replaces reading the original wiki text. If the specific search makes it convenient, parts of such wiki text (including their external references) could be provided verbatim in the response, in a way that it's clear to the user that the shown text comes directly from the wiki.
Of course, this idea would cost time, money and resources to WMF, but maybe these costs could be far less than those of the failed Abstract Wikipedia, while achieving a similar goal (or so I believe; sincerely, I was never able to fully understand the exact goal of Abstract Wikipedia), and in a way that is accessible to the mass public (and, for a part of them, even "cool"). MGeog2022 (talk) 17:46, 18 September 2026 (UTC)
Besides being more expensive and probably worse, how would this be different from going to your chatbot of choice and typing in "I would like to know _____. Please use exclusively Wikimedia sources to research and write a summary answer, and provide links and quotes to relevant wiki articles as appropriate."? -- LWGtalk(VOPOV) 18:58, 18 September 2026 (UTC)
Well, my proposal would give the user true Wikipedia results, and encourage the user to use Wikipedia. The user would be using pure Wikipedia, with no hallucinated garbage in the middle (the summary would be brief and leading to true Wikipedia articles; in some cases, it could include verbatim copies from them).
Please use exclusively Wikimedia sources to research and write a summary answer: the point here is: how many people (particularly non-Wikimedians) would do that? How much hallucinated trash are people believing and reusing because of not being conscious of these options in LLMs? When bad quality information/"knowledge" is on the increase, we could help to solve this problem. And, well, it would probably be expensive, but I suspect Abstract Wikipedia is more expensive and produces next to none useful results, while integrating AI could help to connect again with the mass public that is leaving Wikipedia for their "new toy". About being "probably worse", with all the conditions that I specified (brief summaries with the only purpose of querying Wikipedia, leading the user to actual wiki pages or parts of them), there is no need for the LLM to be the best one available. As a source of knowledge, every LLM is bad. LLMs are (relatively) good at doing things, they are not good at knowing non-trivial facts. MGeog2022 (talk) 19:15, 18 September 2026 (UTC)
"how would this be different from going to your chatbot of choice and typing in": by the way, this is not different from many commercial websites that include their own AI chatbot. People could use any general-purpose chatbot for that, but the site's owners consider that having their own chatbot is the way to retain visits to their site. While Wikipedia is non-commercial, and maximizing visits is not our main goal, a really massive loss of visits can eventually become a huge problem for the community (even while it will always keep a certain niche of users, but that would not be the same Wikipedia we all know). MGeog2022 (talk) 19:22, 18 September 2026 (UTC)
An important detail that I forgot: on its own initiative, WMF has plans to introduce AI for suggestions when editing, no matter how expensive it is or if a general purpose chatbot could do it better. In my opinion, this is just the case where AI should be avoided at all: for writing content (other than for minor adjustements, such as translations, where it is acceptable). If WMF is in favor of using AI in Wikipedia, I think the querying part is the one where it can do more good than harm. MGeog2022 (talk) 20:00, 18 September 2026 (UTC)
I suspect that WMF is fully aware of our strong antipathy towards AI. Blueboar (talk) 20:06, 18 September 2026 (UTC)
please read the thread you linked in its entirety, there have been some clarifications and changes to said plans which will become clear once you read it Gnomingstuff (talk) 06:46, 20 September 2026 (UTC)
A really long discussion there. What seems clear is that most of the community fully rejects any use of AI in Wikipedia. MGeog2022 (talk) 08:52, 20 September 2026 (UTC)
with no hallucinated garbageAnother fatal misunderstanding of AI. You cannot prevent hallucinations. They aren't a flaw limited to how specific systems are programmed - they're an inherent flaw with the technology itself. Don't you think they'd fix it if they could? Limiting the database to specific sources won't solve it. I've experienced outright hallucinations from a micro AI that was programmed for a single book. The only way to guarantee information is accurate is to verify it yourself, regardless of where the feature is hosted. Why should we waste WMF resources for something that would have no significant benefit over external tools? ChompyTheGogoat[Bleat|Munched] 20:40, 18 September 2026 (UTC)
Thanks for your responses. Yes, that's true. But, if the software behind this function asks the LLM to work in some specific ways, including writing only very brief summary texts with links, or verbatim copying some sections, the risks of hallucinations causing any damage is minimal (the brief text itself could contain instructions not to directly use it but to click on the provided links to articles or sections of articles).
Why should we waste WMF resources for something that would have no significant benefit over external tools? I think the benefits would be about reaching the wider public in the AI era, and I believe this is no minor issue: it's like having official Facebook and Twitter accounts 10-15 years ago; we could dislike social network sites, but Wikipedia created official accounts in both of them, and it helped to reach a wider public. I don't like Wikipedia being considered as something from the past by an important part of the population, no matter how silly their thought can be. This is a complex issue, but it shouldn't be considered in a Wikipedia vs AI way. In any case, it's a knowledge vs ignorance one, and by making Wikipedia acceptable to AI "fanatics" (distinct from simple AI users, but I fear those involuntary "fanatics", said with all respect to them, possibly outnumber the sum of AI users and AI non-users), knowledge can win over ignorance.
Another reason would be providing an easy to use way to query the vast Wikimedia datasets (a general purpose chatbot is not optimized for querying Wikimedia data only, and properly using it for that would be very difficult, and, while very useful, giving the enormous size of the dataset, really few people would take the needed work to do it).
WMF resources will be wasted anyway in the "AI-generated edit suggestions". MGeog2022 (talk) 21:05, 18 September 2026 (UTC)
And I'm fully against that proposal too. We're already seeing damage from the Revise Tone tasks. As a donor I have a vested interest in how funds are utilized - and WMF should be acutely aware of how their actions are perceived by donors, given the events regarding WWU.General chatbots do not need to be "optimized" to search Wikimedia. I can tell it to look for something here and it does. If users made a conscious choice to come here and utilize a built in tool they can make the same choice to tell an external tool to search for results here. Simple as. If they're not explicitly looking for results here, they won't navigate here in the first place. Wikipedia was built by humans, for humans, and people who value human knowledge come here for that purpose. The last thing we want to do is dissuade those users - especially those who are editors, or have the potential to be. Fanatics already have Grokipedia, so it's amusing that they still feel the need to come here and try to insert AI content. If it was so great everyone would flock over there instead. ChompyTheGogoat[Bleat|Munched] 21:21, 18 September 2026 (UTC)
Here, I was talking about "AI fanatics", not "X man"'s fanatics (many people, regardless of their ideology, have a blind faith in AI; they may consider any encyclopedia as unneeded in 2026, whether Wikipedia or Grokipedia). I agree with your comment 👍 MGeog2022 (talk) 21:31, 18 September 2026 (UTC)
Get links to reliable websites in a quicker way than they would with WikipediaWe're not a search engine. We only provide limited external links for additional context to article content. If people are wanting to navigate to external sites they shouldn't be utilizing Wikipedia for that purpose. ChompyTheGogoat[Bleat|Munched] 20:32, 18 September 2026 (UTC)
The WMF is not going to be able to outcompete commercial llm-companies fully dedicated to LLMs. If someone wants to overlay one of those over Wikipedia and craft a relevant prompt, that would be much simpler and sustainable way to achieve the goals above. CMD (talk) 07:13, 20 September 2026 (UTC)
The WMF is not going to be able to outcompete commercial llm-companies fully dedicated to LLMs. WMF should never try to do that, and this was never the purpose of this proposal (AI companies create LLMs: this proposal was about deploying and using an already existing, freely licensed LLM). MGeog2022 (talk) 09:30, 27 September 2026 (UTC)
[Use RAG -- gain trust] Some entity might indeed want to implement a natural language querying and summarisation/formatting of a response based on Wikipedia-specific data. It mightn't be necessary for WMF to host that facility, given (possible) additional resources above its usual search. This natural language interaction would be different from prompting a popular chatbot to "Please use exclusively Wikimedia sources to research and write a summary answer, and provide links and quotes to relevant wiki articles as appropriate". One couldn't guarantee a popular chatbot would accurately follow the prompt... however... popular chatbot (or other) could be explicitly configured to use Retrieval-Augmented Generation and low temperature based on the live Wiki data to increase reliability and leverage the naturally multilingual nature of AI embeddings. How WMF could contribute to a Wikipedia-with-AI done better I think is down to technical aspects of implementation. I believe it prudent for WMF to be proactive on how its scraped data is being used. It's not a competition between AI-easy-untrustable and Wiki-harder-high-value, it's about preserving the integrity of information and facilitation of wide access. Munnum (talk) 09:54, 26 September 2026 (UTC)
Good comment. If done, while it mightn't be necessary for WMF to host it (it would be highly convenient, though), user privacy must be fully guaranteed, and all the used software (LLM included) must be freely licensed. Wikipedia is about freely licensed content, and that's also the case with associated software such as MediaWiki. AI software can't be considered in a different way: one thing is the vast hardware resources that running it requires at this moment, so it may need to be run externally (but this should change in the future), and a very different one is to neglect its free licensing. Some years from now, good AI should be able to easily run in a normal computer or server. With AI computing, we are still like in the mainframe era of the 1960s. The AI equivalent of the 1980s and the Personal Computer will need to arrive at some moment. MGeog2022 (talk) 09:21, 27 September 2026 (UTC)
An estimated 78% of reading sessions originate from external search engines. with 90% of those coming from Google Search. ... When readers consistently find it easier to access Wikipedia’s content through third-party platforms than on Wikipedia itself, the site risks becoming a background data source rather than a destination for learning.As in, the same way readers have found their way to Wikipedia ever since it was created? This sounds like more of the slimy corporate "capture all the traffic and never ever let them leave" crap from the discussion about the app and does absolutely nothing to improve my opinion of WMF. Apparently when you reach a certain size slimy corporate behavior becomes mandatory. Very keeping up with the Joneses. ChompyTheGogoat[Bleat|Munched] 21:50, 5 October 2026 (UTC)
I actually wanted to post about a "Google AI Overviews"-like AI assisted search concept feature in here too, with the same goal of getting people to continue using Wikipedia instead of external AI tools! Looks like you've beaten me to it:)I do agree that the AI (model) used for the AI search should be open sourced, and not (necessarily) be built in-house by the WMF. Also, this feature should also be opt-in rather than opt-out. Since we're targeting readers rather than editors, if and when we conduct these tests, the AI functions would be shown to them first, rather than being shown to editors first. And of course, there must be guardrails, the information should be cited to an article so readers can learn more from there.There are some differences between your idea and my idea though. Most notably is the placement of the "AI search" button. Personally I'd rather put the AI search button at the bottom right (or bottom left) corner of the page, similar to the help panel shown to new editors, in contrast to being shown to the right of the search bar as you conceived. Also, not sure if we want cross-wiki search, but we'll see.I do have more comments, including use class and mockups (using the Codex template on Figma), which I will leave below this main comment. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 04:55, 6 October 2026 (UTC)
@Hason-LEK-SIN, thanks for your comment. Yes, I agree that the current search must always be kept, and that AI should be used only as an interface for the search of information, never for writing text for the articles. The exact placing of the button would be a minor issue, several places can be considered and debated, for sure:) MGeog2022 (talk) 11:42, 11 October 2026 (UTC)
Oppose. I feel that the people who would come to Wikipedia if this change were made would be outnumbered by the people who would leave. So many people, especially the type of people who use Wikipedia, have a strong dislike for generative AI. Those who especially enjoy AI will often not see a use for visiting many other sites, since AI can already tell them everything they'll want to hear. Siteseers (Talk/Contributions) 16:27, 6 October 2026 (UTC)
I don't argue with this, but I find it ironic, given the early days of Wikipedia itself when many people "repelled the idea of an encyclopedia that anyone could edit because it would never be as reliable as traditional sources." Sira Aspera (talk) 20:41, 6 October 2026 (UTC)
(This is the idea lab, by the way) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:25, 6 October 2026 (UTC)
Sorry, I'm new to Wikipedia, can you not oppose ideas in the Idea Lab? Siteseers (Talk/Contributions) 13:03, 7 October 2026 (UTC)
First off, welcome! Secondly, do read the top of the Village Pump, which says:
This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
Those who especially enjoy AI will often not see a use for visiting many other sites, since AI can already tell them everything they'll want to hear. And this is a big problem, and one that Wikipedia could help to solve, by using AI in helping people to find knowledge, in place of believing hallucinated trash.
So many people, especially the type of people who use Wikipedia, have a strong dislike for generative AI. Wikipedia is not written for Wikipedians, but for the public as a whole. Out there, such dislike does exist, but is not so prevalent. And we must differentiate using generative AI as a source of knowledge (which is wrong, unless looking for very basic facts) from other uses of generative AI. Making Wikipedia to look as a project for anti-AI people only would make it a fringe project. I don't want that, and I hope most of the community also doesn't want it. Wikipedia has gained a place where it is mainstream. One of the few cases where the main existing product is both a freely licensed one and one well-known to the masses (for example, Linux, while absolute leader in some types of computing, is not so well-known for many people as Wikipedia is). We believe in freely licensed content, and we should enjoy the fact that we are the leading encyclopedia. We shouldn't renounce that, much less tolerate being replaced in society by something that is not even an encyclopedia nor a proper written work (the latter point is important, because even freely licensed AI models shouldn't replace Wikipedia, since they are not true written works). And, at this moment, we need to fight for that, whether you are a pro-AI, anti-AI, or neutral Wikipedian. Maybe AI-assisted search is not the only or the best thing to do for that, but I think that Wikipedia/WMF should highlight why Wikipedia is needed by humans in the AI era, and make campaigns around it (and, no, an "all AI is evil" campaign would not be the solution: it would make the problem worse, since many people use generative AI for work, and they are happy with it: the campaign should focus on the points where Wikipedia is far better than AI: each thing has its own purpose).
I feel that the people who would come to Wikipedia if this change were made would be outnumbered by the people who would leave: really? If Wikipedia adds an AI-assisted search (I'm not talking about AI-assisted article writing, that would be another thing), many people would leave? What would they do, then? Since they are anti-AI, I suppose they would go to Encyclopaedia Britannica, and, when the information is not there, I suppose they would just accept ignorance. Fortunately, there are more things than fanaticism (pro-AI, anti-AI, or pro or anti whatever you want) in life. MGeog2022 (talk) 11:22, 11 October 2026 (UTC)
Being anti-AI isn't fringe, and keeping AI out of specific spaces that have always been written by humans, for humans certainly isn't. You can acknowledge that it has valid uses and still not want it encroaching in certain areas - and it's already causing issues where it's been inserted here without consensus, so I have precisely zero faith that giving them license for additional uses would turn out any better. Wikipedia should be upholding quality standards, not trying to win a popularity contest. People who already believe hallucinated slop aren't looking for alternatives anyway because they don't know any better. If they did, they'd use us without needing AI features as some weird form of bribery. ChompyTheGogoat[Bleat|Munched] 13:00, 11 October 2026 (UTC)
keeping AI out of specific spaces that have always been written by humans: I fully agree on keeping AI 100% out of writing any Wikipedia content: my proposal is only about a tool for querying information, but that information must be written by humans.
Wikipedia should be upholding quality standards, not trying to win a popularity contest: both things are needed: Wikipedia's quality itself would be in trouble if only a tiny minority of the people use it. It's not about getting as many visits as possible, but about continuing to be the leading source of knowledge. Visits to Wikipedia are going down, and the solution to this is not just saying that we are better and wiser: Wikipedia must not allow being silently replaced by non-free products that are not even an encyclopedia.
According to this source, in the United Kingdom, 42% of individuals deliberately limit the amount of AI they use. Only a part of them would be purely anti-AI people. I believe Wikipedia should be for everybody, not only focused on that <42% of the people: believing that Wikipedia should be specifically directed to the, let's suppose, 25% of people who oppose using AI at all, is what would make it a fringe project. A fully optional AI-powered search has nothing to do with basing Wikipedia on AI: it's just an optional tool that you use if you want, and, if you don't want, you don't use it. We can't allow AI damaging Wikipedia's quality, but we also can't allow AI making Wikipedia irrelevant for the wider public. Wikipedia should be for everybody: for people who don't like AI, for people who like AI, and for people who are indifferent about AI. And I would like to add that, as long as AI (particularly, non-free AI) threatens the usage of Wikipedia, free content and open source software, I'd belong to the anti-AI camp. We can't stop AI (no new technology has ever been suppressed), but we can stop the damage it causes to free knowledge. MGeog2022 (talk) 16:42, 11 October 2026 (UTC)
42% is hardly a "tiny minority", and you seem to be assuming that the remaining 68% who don't actively avoid it would also refuse to utilize any products that don't include AI, which is a massive leap. So is the notion that anything without AI features will become irrelevant. This is feeling more and more like obsessive POV pushing without any care for consensus. You said weeks ago What seems clear is that most of the community fully rejects any use of AI in Wikipedia, and yet you're still here arguing for it, in what should probably be a WP:SNOW close since you've seen how similar discussions turn out. ChompyTheGogoat[Bleat|Munched] 18:58, 11 October 2026 (UTC)
I hope you are right, but I don't like the "AI replaces Wikipedia" thought that I see out there, and I believe that something should be done about that. As I said, I'm not a pro-AI fanatic at all, but I don't see that a majority, or even a big minority, of people are anti-AI (42% of people "deliberately limit the amount of AI they use" is not the same as them trying not to use AI at all). And I'm not doing "obsessive POV pushing" at all: I only commented here again in response to other, new comments from other users (by the way, one of them was in support of my proposal). I took advantage of this to express my worries about the seemingly endless fall in the number of visits to Wikipedia, and to warn about the dangers of a "Wikipedia vs AI battle". We must be aware about how prevalent the use of AI is (even if we don't like it at all), and make Wikipedia the leading source of knowledge in this era, just as it was in the previous one. In fact, the problem is not how prevalent AI is, but how much it is being trusted as a source of knowledge (which it isn't), even by people with university education. The solution to this is not to "destroy AI", but to convince people to use Wikipedia for what Wikipedia is, and to use AI for what AI is. Maybe a WMF campaign could help with this, or maybe time will do it (but there is a risk in the latter case: given the current panorama, I fear that hallucinated ignorance could eventually win). MGeog2022 (talk) 19:24, 11 October 2026 (UTC)
Brittanica also has an AI. CoolDino1 (talk) 16:12, 15 October 2026 (UTC)
A DOSE OF REALITY. No one likes the smell of goats, but if they get stuck in a place with goats the small gets in their clothing and they will get used to it and not notice it. Those who do not like AI search, myself included, will eventually have that fate. AI search is everywhere and we will all be covered in it sooner or later. Sigh... Yesterday, all my dreams... (talk) 10:00, 7 October 2026 (UTC)
Most corners of the internet aren't governed by democratic consensus. This is one of the few places we actually get a say in whether or not features are implemented, rather than having them forced down our unwilling throats (for the most part). ChompyTheGogoat[Bleat|Munched] 00:22, 8 October 2026 (UTC)
Wouldn't this argument be Argumentum ad populum? You appear to be assuming that since a lot of other people are conforming to the idea of AI (for lack of a better term) then we must also conform, even though that is not the case. Siteseers (Talk/Contributions) 14:03, 8 October 2026 (UTC)
Advertisements are everywhere. Data collection is everywhere. Wikipedia doesn't have to follow the herd; we are not driven by shareholders fixated on the next quarter's earnings. Certes (talk) 20:42, 8 October 2026 (UTC)
Advertisements are contrary to Wikipedia's principle of neutrality. A freely licensed AI model isn't contrary to Wikipedia's principles. This is a bit off-topic here, but I feel that the anti-AI sentiment of many people from the free content and open source world has made non-free AI models to reign, and eventually, to free content and open source software being replaced by non-free AI, and this is really sad. I hope free AI models can eventually lead in their field some day. MGeog2022 (talk) 11:27, 11 October 2026 (UTC)
*Also the free software community. Despite common misconceptions, the open-source movement and the free software movement are different but related sides of the same coin. Free software folks like to think of freely-licensed software as being a tool of personal liberation, and don't really care for businesses as long as there's no non-commercial clauses or anything. While this approach tends to attract a lot of individual users, it has the disadvantage of scaring away businesses, who usually have more cash to blow on developers.
Open-source is a weakened version of free software, but instead of fighting for individual freedom, its selling point is that it's cheaper and more effective for businesses than proprietary software. While this is quite palatable to companies like Microsoft that wouldn't otherwise adopt freely-licensed software into their workflows, it comes at a cost, as companies generally want the right to restrict downstream usage of the software, and the developers generally agree to this.
Thank you for listening to my TED Talk. (Feel free to use this as a nerdy copypasta.) GrinningIodize (you just lost the game) (talk) 12:02, 14 October 2026 (UTC)
Certainly, while licenses are similar in both cases, free software and open-source are different philosophies. In the end, as with Wikipedia, most users don't come from philosophical but practical reasons, so FOSS is used by many people thanks to the open-source approach by companies (it would be great if most people thought in software freedom terms and that was the leading cause of FOSS usage, but, sadly, the reality is far from that). MGeog2022 (talk) 13:36, 14 October 2026 (UTC)
Collapsing friendly banter to keep things organised. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:38, 15 October 2026 (UTC)
It's only an issue at the beginning of a message because wiki markup uses regular: colons preceding comments to nest discussion replies. Simply adding a space to separate it from those resolved it. ChompyTheGogoat[Bleat|Munched] 21:36, 14 October 2026 (UTC)
I'm not convinced that a Google AI Mode alternative with a more limited domain of knowledge and open-weight models would get a lot of usage, and plus, every dollar spent on energy costs for this model would come straight out of donations that could have gone somewhere more important instead.
I suppose a trial run with a low-cost model hosted somewhere else could work, but even then, I think that it would probably stain the Wikipedia's reputation amongst the folks who thought that AI Overviews were full of poppycock when they first came out. GrinningIodize (you just lost the game) (talk) 12:33, 12 October 2026 (UTC)
Google AI Mode alternative with a more limited domain of knowledge: Wikipedia's search also has a "more limited domain of knowledge". The difference is that Wikipedia's search results (AI-assisted or not) are trusted as knowledge, while many Google results (AI-assisted or not) are not proper knowledge and/or are not trustable. We shouldn't compare Google's AI mode with the proposed "Wikipedia's AI mode": they would have very different scopes. An AI-assisted search that could locate all information about a topic that is distributed among many Wikipedia articles, would do a far better job than Google's mix of information from any kind of source (Grokipedia and social network sites included). MGeog2022 (talk) 18:15, 12 October 2026 (UTC)
Still though, the folks who search on the Wikipedia are usually people who don't want to read an LLM summary, and for those who do, they can always just ask their favorite LLM service to read Wikipedia articles. GrinningIodize (you just lost the game) (talk) 19:42, 12 October 2026 (UTC)
Additionally, Wikipedia is already one of the most cited websites by LLMs. LLMs are already pulling from WP whether it's a WMF-sponsored project or not. Shocksingularity (talk) 06:00, 14 October 2026 (UTC)
trusted as knowledge There you go again. AI results cannot be trusted to avoid hallucinations regardless of the size of the knowledge base. It's a fundamental flaw in how they operate, and people who don't understand that will fall for misinformation regardless of the source. Extrapolating Wikipedia's current reputation built on human editing to imply that local AI would be more reliable than external ones would only tarnish that reputation. ChompyTheGogoat[Bleat|Munched] 21:07, 12 October 2026 (UTC)
An AI whose literal only source was Wikipedia would not make the same errors as Google's AI (or any other general AI), but that doesn't mean it would not make errors. It would not regurgitate random misinformation (unless said misinformation was present in one of our articles, but that's a GIGO problem that affects all search engines regardless of technology), however it could still produce misinformation by e.g. incorrect synthesis or removal/misunderstanding of nuance. Thryduulf (talk) 21:16, 12 October 2026 (UTC)
You're somewhat right in the sense that hallucinations aren't regurgitation - they're hallucinations. Invented completely out of the blue regardless of sourcing, which I have personally experienced from micro models built on a single source. It doesn't have to be the result of of incorrect analyses either; the information just flat out does not exist anywhere. ChompyTheGogoat[Bleat|Munched] 21:22, 12 October 2026 (UTC)
I'm not sure there's a good way to split the distinction between the accuracy of text completion predictions made by an LLM trained on Wikipedia versus one trained on the broader Internet. An LLM isn't trying to reproduce information from its training base; it's generating text that its internal black box thinks is a suitable consequence from the prompt. So the response could still be out-of-the-blue wrong from a Wikipedia-trained LLM. isaacl (talk) 22:02, 12 October 2026 (UTC)
At least the old Google snippets were accurate reproductions from the source - just not necessarily relevant to the actual query. ChompyTheGogoat[Bleat|Munched] 22:06, 12 October 2026 (UTC)
I wasn't talking about a LLM trained on Wikipedia. I was talking about using a freely licensed LLM developed by a third party (already trained by the third party), with the appropriate setup for it to search information on Wikipedia (and maybe also its sister projects) only (related concepts: AI agent, Agent harness). LLM training is only for the LLM to have a very basic general culture, but this makes it able of giving basic information only. As I said in the Wikipedia essay I recently wrote, one could say that AI doesn't know: it knows how to do. While hallucinations are always possible, AI works far better with source texts as "raw material": its internal knowledge base is useful only for very basic concepts. To avoid problems with hallucinations or misinterpretations by the AI, I'd like to emphasize its role should be that of a search assistant, inviting the user to actually read the content in the Wikipedia articles (or other wikis or Commons media files), or, when appropriate, including a paragraph, taken verbatim from the article, with citations included, and a link to the article's section where the paragraph was taken from. My idea was to undo the "AI replaces Wikipedia" change that some people underwent, by providing the needed tools for it, while also adding new advanced search capabilities to Wikipedia and its sister projects. MGeog2022 (talk) 12:57, 13 October 2026 (UTC)
I was commenting on Thryduulf's statement An AI whose literal only source was Wikipedia ... would not regurgitate random misinformation. isaacl (talk) 18:39, 13 October 2026 (UTC)
Strong oppose: I don't use or trust AI for good seasons. AI should not be doing edits on this site and that's why people are leaving Wikipedia. You guys better think this over. BattleshipMan (talk) 06:23, 22 October 2026 (UTC)
The idea lab is not a place for Oppose or Support comments. I did the same thing. Also, this idea does not involve AI editing an article. While AI is terrible for writing articles...Siteseers (Talk/Contributions) 12:49, 22 October 2026 (UTC)
Yes, this proposal is not about AI making any edits. In addition, in case this proposal was eventually implemented, you (@BattleshipMan) would still be able to search, use and edit Wikipedia without using any AI. MGeog2022 (talk) 12:54, 22 October 2026 (UTC)
Optional Content Warnings and Collapsible Text for Exceptionally Graphic Material
Hi everyone!
I'd like to suggest introducing content warnings and optional collapsible text for exceptionally graphic descriptions in Wikipedia articles, similar to how spoiler tags work on Discord.
Recently, I was researching the Colombian serial killer Luis Alfredo Garavito and came across the descriptions in the Modus operandi section of his Wikipedia article.
I'm an adult and generally have a fairly high tolerance for graphic material. I regularly research criminal cases and understand that articles covering these subjects will inevitably contain disturbing information. However, the level of graphic detail in this particular section was something I was completely unprepared for. It genuinely shocked me, and I found myself quite distressed afterward.
This experience also made me think about younger readers. Wikipedia is accessible to everyone, including children who might stumble upon an article out of curiosity. While someone researching a serial killer should reasonably anticipate disturbing subject matter, I don't think they would necessarily anticipate descriptions of that level of severity. I'm absolutely not suggesting that Wikipedia remove, censor or omit factual information. I understand the importance of documenting these cases accurately, and I believe readers should continue to have access to complete information.
However, I wish I'd been given the opportunity to decide whether I wanted to read those particular descriptions. Had I received a warning beforehand, I likely would have chosen not to reveal them.
My Proposal:
I'd like to suggest introducing an optional feature for particularly graphic passages that includes:
A brief content warning explaining the nature of the material that follows.
Collapsible text that hides exceptionally graphic descriptions by default, with an option for readers to reveal them.
A short, non-graphic summary that remains visible so readers can understand the relevant information without having to reveal the more explicit descriptions.
This could function similarly to Discord's spoiler tags, allowing readers to make an informed decision about whether they wish to view additional details. I believe this would be particularly beneficial for younger readers, people who have experienced trauma and anyone who wishes to research difficult subjects without unexpectedly encountering extremely graphic descriptions. Content warnings wouldn't prevent people from accessing information, they would simply give readers a choice about how they encounter it.
Previous Proposals & Potential Concerns:
I've since discovered that content warnings have previously been proposed and rejected, and that Wikipedia has an existing policy concerning disclaimers. However, I believe my proposed approach is sufficiently different to warrant further discussion.
One reason cited for rejecting previous proposals was that disclaimers may appear too late, after readers have already encountered the material. My suggestion would address this concern by allowing particularly explicit passages to remain hidden until readers actively choose to reveal them. Rather than placing a general disclaimer at the beginning of an article, this approach would provide warnings immediately before specific passages containing exceptionally graphic descriptions.
I recognize that establishing criteria for which passages qualify would require careful consideration. However, I believe this approach is worth exploring separately from general article-wide disclaimers.
Ultimately, I'm not asking Wikipedia to decide what readers should or shouldn't be allowed to read. I'm suggesting that readers be given the opportunity to make that decision for themselves.
I'd be interested to hear whether this approach would be technically feasible and what the community thinks about the idea. Thank you for taking the time to read and consider my suggestion! chrissy <3 (talk) 05:44, 4 October 2026 (UTC)
While a warning template is technically feasible in theory (but see also MOS:COLLAPSE regarding accessibility issues), your suggestion does not address any of the reasons why previous proposals for similar have been unsuccessful, particularly:
Who defines what "particularly graphic" and/or "exceptionally graphic" actually means?
Who decides whether a given bit of content meets that definition?
How, in practical terms, do we assess 7,256,669 articles to apply the template so that someone browsing Wikipedia on the basis that this warning will protect them/their child from seeing "exceptionally graphic" content doesn't come across such material on an article that hasn't been looked at yet? What about if the article content has been changed since it was last assessed (vandalism, article expanded, etc)?
So, no, in practice it is not feasible. Thryduulf (talk) 11:39, 4 October 2026 (UTC)
Is there a minimal implementation that is still fits, like a template that produces a hidden comment and a User JS script that visibly warns? Interesting to consider but would likely still create disputes and suck a lot of editor time. Dw31415 (talk) 16:48, 4 October 2026 (UTC)
I'd like to clarify that I'm not suggesting Wikipedia review every existing article or guarantee that readers will never encounter disturbing material without a warning.
My suggestion is that warnings could be introduced gradually, where particularly explicit passages are identified and discussed. An imperfect system wouldn't necessarily be without value simply because it couldn't cover every article immediately. I also recognize that collapsible text presents accessibility concerns, and any implementation would need to address those.
Regarding who determines what qualifies as exceptionally graphic, I agree that this would require clearer criteria. Perhaps the feature could be limited to unusually explicit descriptions of sexual violence, torture or severe bodily injuries rather than general references to violence or death. chrissy <3 (talk) 16:55, 4 October 2026 (UTC)
Are you familiar with our RfC process? I’m guessing not based on your proposal. You might take a quick look at some of them at Wikipedia:Requests for comment/All. Experienced volunteers get triggered reading you proposal and imagining the time that will be spent debating whether this or that content qualifies. Dw31415 (talk) 09:40, 5 October 2026 (UTC)
Thanks for pointing me toward the RfC process. You're correct that I'm not particularly familiar with it — I'm relatively new to Wikipedia's internal processes, which is part of why I brought this to the Idea Lab rather than presenting it as a finished policy proposal. I'll take a look through some previous RfCs.
I do understand your concern about editors having to debate what qualifies as exceptionally graphic content. I don't have a perfect solution for where that threshold should be drawn, and I think that's something that would need community input if the idea were ever developed further. My intention here was mainly to suggest the concept and see whether there might be a workable way to implement it, because if it' a firm no on here, there's no point to take it a step further:) ~2026-53456-88 (talk) 17:24, 5 October 2026 (UTC)
I think it’s unlikely to proceed based on all the previous discussions, so I’m hesitant to encourage you to invest more time in it. Let me take the opportunity to compliment your detailed post here. That’s so much better than many of the posts which are super vague Dw31415 (talk) 17:36, 5 October 2026 (UTC)
Parents should be supervising children on Wikipedia. Adults should be aware of what they are getting into. Readers already have the opportunity to decide what they read; they are not compelled to access any particular article. Adults/parents can use methods on their end to block text. If you feel that article content is too graphic or too detailed for the average reader, that should be discussed on the talk page.
This method could be used inappropriately to censor content by deeming it "graphic". Creating a process to challenge its inappropriate use just creates more bureaucracy that we don't have volunteers to be involved in. Thank you for your suggestion, but this is not feasible. 331dot (talk) 14:48, 4 October 2026 (UTC)
My intention isn't to censor information or suggest that parents have no responsibility for supervising their children. Rather, I believe there's a meaningful distinction between knowingly choosing to research a disturbing subject and unexpectedly encountering an exceptionally explicit description within that research. chrissy <3 (talk) 16:57, 4 October 2026 (UTC)
How often do you find explicit or inappropriate descriptions unexpectedly, unpredictably from the article you're reading? If I open a sexually themed article, I can predict there will be descriptions or photos. If I search for a serial killer, there might be descriptions of his crimes. The same goes for other controversial, disturbing, or disgusting topics. However, I've never searched for Winnie the Pooh and randomly stumbled upon explicit descriptions. So, since you actually have to search for your articles on Wikipedia—there's no feed—I think it's worth the hassle.
People can have triggers from the most innocuous things: they might read a Star Wars related page and get triggered by seeing a photo of Palpatine because they have traumas related to elderly figures with dictatorial attitudes. You really don't know what can trigger a person. Furthermore, a reader reads the summary, decides based on it that they can bear to read further, becomes traumatized, and accuses Wikipedia of not adequately protecting them because the summary didn't adequately prepare them to make the decision to delve deeper. Sira Aspera (talk) 20:59, 6 October 2026 (UTC)
good idea, I support! CHIMERA2212 (talk) 15:46, 5 October 2026 (UTC)
As you noted, this is a perennial proposal (for anyone who hasn't seen it, see Wikipedia:Perennial proposals §Content warnings). For some recent discussion, see Wikipedia:Village pump (idea lab)/Archive 83 §SFW Wikipedia?. As I discussed previously, I think that content filtering is better done by a for-profit organization, to ensure ongoing funding and to allow it to tailor the filtering for its specific audience. The operational challenge for volunteers to support this is daunting. isaacl (talk) 17:44, 5 October 2026 (UTC)
+1 Also to add it’s probably our commitment to Wikipedia:Consensus that makes this near impossible. A different hypothetical nonprofit project might be able to handle this with an editorial hierarchy. Dw31415 (talk) 17:48, 5 October 2026 (UTC)
I'm sorry, but while I sometimes come across photos here that I would have gladly avoided, I can never support proposals that push Wikipedia toward a version of AO3 or Tumblr's trigger-tag paranoia. Face life, people, and learn to use the X in the top right if a photo or paragraph is really too much for you. Sira Aspera (talk) 20:55, 6 October 2026 (UTC)
Please read the section of the article I mentioned when I created this post and let me know if “pressing X” makes sense here. There is no lead up to this passage — the article is normal until the specific section I mentioned, which is a sudden jump to extreme and graphic descriptions. ~2026-54253-54 (talk) 00:14, 9 October 2026 (UTC)
Yes, I've read it, and yes, it makes sense to me that when it gets too much, you just close the page. You didn't have to read beyond the first line. Also, you can't really call it a surprise: the first few lines make it clear we're talking about a prolific pedophile serial killer known as the Beast. The section is titled "Modus Operandi": what did you expect to find there other than descriptions of how he tortured, raped, and killed? Also, how can you write a summary that gives the reader a good enough warning without mentioning anything? Most people would just click read and then blame Wikipedia because the warning wasn't worded well. Children have no sense of proportion; they would be the first to click "read". The growing expectation among people that they will never encounter anything that makes them uncomfortable and that it is the world's responsibility to ensure this is unhealthy, it is not a right, it is the "the world is shaped to my needs" egocentrism that is so trendy on social media. Sira Aspera (talk) 12:47, 9 October 2026 (UTC)
Again, the content in that section of the article is extremely descriptive and graphic. I'm not saying the information should not be included, but it does not need to be written in the way it is. It seems to almost sensationalize his actions.
If we're going to add such extreme detail, there's no loss to have a warning before the passage. I'm not sure how your feelings are so hurt by this ~2026-55818-08 (talk) 07:02, 17 October 2026 (UTC)
"I'm not saying the information should not be included, but it does not need to be written in the way it is."
The article is written the way it is for a reason: the volunteers who put in time and effort to write about this guy decided that (1) the content was worth informing people about and (2) the current phrasing is the best way to do it.
If you don't like the way it's written, the traditional answer is to WP:Be bold and propose a better phrasing yourself. I recognize that this course of action isn't exactly possible when you want to avoid thinking about the subject matter. But IMHO people with a "does it really need to be included" complaint typically underestimate the extent to which the answer is yes, some readers want to know those things.
The general Wikipedia approach is that is better to have "too much" uncomfortable information here than too little. Readers can always skip the excess information, but they can never read omitted stuff. Bernanke's Crossbow (talk) 05:12, 19 October 2026 (UTC)
And that's purely your opinion. Mine is that people need to grow thicker skin instead of expecting the world to cooperate with their desire to live under a glass bell, avoiding any discomfort. Especially those who voluntarily choose to read the section labeled "Modus Operandi" of a serial killer whose opening sentences make it clear he was extremely violent and brutal. I'd say that's a warning in itself. If this topic were covered in a paperback, would you ask for warning sections before each chapter? Sira Aspera (talk) 17:21, 20 October 2026 (UTC)
sone of these issues can be met by making sure articles are written to the principle of least astonishment WP:PLA. A reader should not be surprised by a graphic image or section of text, which means if these are necessary, they shouldnt be in ledes but in body sections that are clearly marked. But thats the best we can do, because as others have said, we dont censor outside of material illegal under US law, and for anything else, who's moral compass do we use to decide if it should be hidden? Masem (t) 21:22, 6 October 2026 (UTC)
Thank you for your reply! (this is the original poster but I am not logged in on my phone lol)
I am seriously fine with this compromise as well and think it’s a great substitute if my idea is not feasible! ~2026-54253-54 (talk) 00:11, 9 October 2026 (UTC)
Which is exactly how the page that bothered you is written. The information is contained in the section clearly labeled "Modus Operanti," after clarifying that the subject is a brutal serial child sex killer. You read it because you thought you could handle it. Would a "Warning: Sensitive Material" warning really have deterred you? Sira Aspera (talk) 17:25, 20 October 2026 (UTC)
In addition to what Masem said about the Wikipedia:Principle of least astonishment, I wonder if we could have a collapse button? It wouldn't stop you from seeing it initially, but it would give you a way to collapse it if you didn't want to keep looking at it. I think this would be particularly popular for animated gifs and for large elements (especially if the layout doesn't flow nicely on your device, and you just need to get that wide table out of your way). WhatamIdoing (talk) 23:41, 16 October 2026 (UTC)
Yes yes yes yes, this works as well! ~2026-55818-08 (talk) 07:00, 17 October 2026 (UTC)
"Articles for Replacement" or something like it
Standard disclaimer, I searched for existing threads on this and didn't find anything but I'm pretty new. If this has already been discussed to death just lmk and I'll be on my way.
I have been looking at COI edit requests a bunch recently. The queue is quite long at the moment. There's a particular kind of request that seems doomed to fail, which is when someone comes in and says they have a draft prepared in userspace or draft space or pasted right into the talk page and they want to replace the article that exists with it. What generally happens is that it sits in the queue until it's gotten thoroughly stale and then someone comes by and closes it citing WP:CHANGEXY. I think this is pretty reasonable, and is what I end up doing myself.
However, some of the articles that the edit requests are proposing to replace are, frankly, pretty bad. In some cases it seems like they would have a better chance of improvement if goblins were to sneak into the WMF datacenter and irretrievably delete the original article, allowing the user to take their draft to AfC (where still many of them are probably doomed but you've at least got people who want to look at whole articles). Have we ever considered allowing a separate review process for requests to wholesale replace a current article? It would obviously require that the existing article has major problems. But if nothing else it'd be a more satisfying thing to tell someone than "sorry, there's probably never gonna be a volunteer that wants to dissect the diff between your version and the existing version of this article. maybe see if you can get a WP:TNT deletion." Packrat3860 (talk) 02:50, 12 October 2026 (UTC)
We don't need such a process, since a contributor already can, as WP:TNT notes, rewrite an existing article from scratch. I'm not sure that having an AfD-style discussion about it would achieve much, since !voting to support something in principle won't get it done - it needs someone motivated to do it, and if they are, they don't need a vote. AndyTheGrump (talk) 03:01, 12 October 2026 (UTC)
Well, in the case of COI edits the contributor with a COI is strongly discouraged from making a significant edit. While the option is technically permitted, I think in practice that's not going to be looked at favorably. You're probably just going to get swiftly reverted and told not to do that (and again, no judgement as I have done exactly that).
I guess what I really want is a canned response to suggest that path as an alternative to a "normal" COI request that's specific. Perhaps if someone writes an essay or something it'd be easier to invoke as an official looking suggestion. It gives me some Nel Noddings shaped pause to realize that what I want is a general form to spare me the work of considering the particular scenario.
I think I will try to be bold and consider this option next time someone proposes a complete replacement for an existing article with major quality issues. And maybe also I should sit in on some AfC discussions to get a feel for accepting imperfect improvement to the encyclopedia. If that effort bears fruit I'll report back. Packrat3860 (talk) 04:44, 12 October 2026 (UTC)
Well, in the case of COI edits the contributor with a COI is strongly discouraged from making a significant edit. While the option is technically permitted, I think in practice that's not going to be looked at favorably. You're probably just going to get swiftly reverted. Sorry if I misunderstood something, but, if the article was basically trash, I don't see why the edit should be reverted. If, for whatever reason, there are objections to rewriting the full article from scratch, there should be even more objections to deleting it, so this would not be a solution. MGeog2022 (talk) 19:42, 14 October 2026 (UTC)
In re what I want is a general form to spare me the work of considering the particular scenario: Welcome to Wikipedia, @Packrat3860. Please pick up your experienced editor badge, because you clearly are one, no matter how long you've been editing. The eternal tension when patrolling or working through a backlog is between doing one complex task or ten simple ones, and the temptation is to look for a way to turn the complex tasks into simple ones, or at least to make the complex part be someone else's problem. It's not just us (see, e.g., https://xkcd.com/1319/ on automation), but this is definitely us. WhatamIdoing (talk) 00:57, 17 October 2026 (UTC)
Is there a list of articles that do need to be TNTed? Also, tgat essay always bothered me in that it’s not entirely clear how to TNT except to stubify. User:Bluethricecreamman(Talk·Contribs) 04:49, 12 October 2026 (UTC)
Stubify is pretty much it, I usually only see the TNT essay referenced when it's either that or just delete it (and optionally start again from the redlink). Alpha3031 (t • c) 14:44, 14 October 2026 (UTC)
@Bluethricecreamman, I updated WP:TNT with a more obvious step-by-step process a little while ago. Take a look? WhatamIdoing (talk) 00:59, 17 October 2026 (UTC)
When you encounter this phenomenon, what's stopping you from WP:PRODing the bad article and telling the COI editor to resubmit to AfC? Bernanke's Crossbow (talk) 04:58, 19 October 2026 (UTC)
I am not terribly familiar with WP:PROD. However one of it's criteria listed is that PROD must only be used if no opposition to the deletion is expected.. That seems like it'd be nearly impossible. In my limited experience with AfD it seems the one of the most common objections is that an article's current state is bad but it could be improved. If my intention in deleting an article is just to make space for an AfC submission then it would be hard to argue that I don't think the article could be improved.
That kinda begs the question from Andy above that if I think that stubbifying the article is truly an improvement over its existing state, perhaps I should just do that. Packrat3860 (talk) 05:27, 19 October 2026 (UTC)
Brainstorming ways to resolve the gap with TWAFI on the Main Page
You can hide the new TWAFI section by pasting #mp-afi-h2, #mp-afi { display: none; } into your common.css.
The first thing that came to my mind was to convert TFL to a half-width module. But then I realized it only runs MWF. We could do POTD, but that would sacrifice the size of the picture, which we probably don't want. We could convert one of the half-width modules to full width, but ITN, OTD, and DYK's bullet list formats are all non-conducive to that. This would leave us with TFA or AFI, which would mean removing one of them from the top of the page. Any ideas? Snowmanonahoe (talk·contribs·typos) 00:30, 19 October 2026 (UTC)
I've been informally asking for a better, dedicated spot for Recent Deaths on the main page for a while (most recently here). There are other language Wikipedias that give that section is own spot on the main page separate from ITN. It would mean that blurb and ticker discussions for RD would be separate from ITN as well. Perhaps Recent Deaths could be the project takes up that blank space? Doc Strange (talk) 00:35, 19 October 2026 (UTC)
I strongly support this idea. At ITN we’ve wanted for a while more room for RD and Ongoing. I don’t know if separating RD from ITN would be a good idea but I can certainly see it. I note also that there is an ongoing RFC workshop for ITN reform that this could be rolled in to. Chorchapu (talk|edits) 00:44, 19 October 2026 (UTC)
One of the biggest issues with giving that space to RD that I can think of is that there's no dedicated project discussion space for RD right now, beyond ITN and the talk page of the current year's Recent Deaths page (currently Talk:Deaths in 2026). But if RD is chosen for this blank spot on the main page, and a separation from ITN occurs, I'm sure something like that could be made. Doc Strange (talk) 01:08, 19 October 2026 (UTC)
I’m sure we could figure it out. Alternatively, it could just stay in the same forum as ITN. Chorchapu (talk|edits) 01:10, 19 October 2026 (UTC)
I really like this idea, RD sometimes feels out of place being such a small bar with no info about who the people were OrdinariusFingius (talk) 01:46, 19 October 2026 (UTC)
One can look at the German Wikipedia’s Main Page for an example of what this expanded RD might look like. Of course, anything is open to change and it doesn’t need to be copied exactly from dewiki. Chorchapu (talk|edits) 01:53, 19 October 2026 (UTC)
Given that he appears as simply Napoleon Bonaparte on the Main Page, I support this idea. Adding some information about who these people were would be quite helpful and is arguably, even necessary in some cases. ScienceD90 (she/her) (talk) 03:28, 19 October 2026 (UTC)
On ITNC we discussed this a bit, and seemingly eventually decided to not disambiguate it for two reasons: 1, that it would end up being too long and 2, so it would leave a funny surprise for readers. Chorchapu (talk|edits) 03:31, 19 October 2026 (UTC)
In response to #1, the idea here is to take up space. ScienceD90 (she/her) (talk) 03:47, 19 October 2026 (UTC)
Simply giving everyone some kind of blurb would also majorly help with arguments if a person is famous enough to get a get a blurb or not like with RJ Mitte or Martina Arroyo. Maybe for big cases like RJ Mitte or Martina Arroyo we can add their picture to it or even multiple pictures if a Dolly Parton - Tim Curry death happens perhaps? OrdinariusFingius (talk) 03:34, 19 October 2026 (UTC)
I would oppose this idea, as I have in the past. Having a look at the obit sections at places like dewiki, frwiki, etc. I'm under the impression that the quality and vetting process of articles featured there is of much lower priority than on here, which is a showstopper. There needs to be some sort of vetting process an I don't see the purpose of splitting it wholesale off of ITN, especially given the propensity of an RDBLURB nomination. Additionally, the RD sections on other wikis are rarely that separated from one another. The dewiki calls more or less relate to blurb noms and a brief period in summer when Ongoing was very long. — Knightoftheswords(talk) 05:13, 19 October 2026 (UTC)
I also support the idea of an RD/obituary section with a picture. This is done on the other languages such as French, German and Spanish and seems to work well.
Another option would be a Top Read section to list trending articles like the app.
Whatever is done will require an extensive RfC and planning as was done for the TWAFI change. In the meantime, white space in the desktop view is not a big deal as there is plenty of white space elsewhere on the main page and its exact appearance depends on one's browser, preferences and screen size. And most of our readers use the mobile view which has a single column in which this is a non-issue.
It's super ugly, thanks for bringing it up. Personally I think that the AFI should be horizontal so that it fills two columns, like TFP and TFL. At this discussion someone suggested using more DYK hooks at a time and making the TFA text longer but I think that's just going to put too much work onto the people at DYK. ―Panamitsu(talk) 00:36, 19 October 2026 (UTC)
Make the TFA full-width and move the improve thing (if we must have it) to below the DYK. -- Veggies (talk) 00:36, 19 October 2026 (UTC)
I think making TFA full-width would be a good thing. Can possible give the TFA people the scope to accept longer blurbs (if they were up for it). Neutral on placement of anything else, but TFA should definitely remain at the top. TarnishedPathtalk 04:28, 19 October 2026 (UTC)
I like this idea. Moving AfI to below DYK keeps the ordering the same as it is now for mobile readers, but looks much better on desktop. InfernoHues (talk) 04:33, 19 October 2026 (UTC)
We could have a "Today's Featured Vital Article" or a "Today's Featured WikiProject" section. Additionally, courtesy of User:Eman7blue42 on Discord, "Today's featured Good Article" might also be a good idea. Prost, A.Classical-Futurist (talk) 00:44, 19 October 2026 (UTC)
Ambivalent, leaning “that’s a fine idea” on the first two, but I Oppose the TGA proposal. It would decrease the value of an FA and TFA by showing GAs as well. Chorchapu (talk|edits) 00:46, 19 October 2026 (UTC)
What Wikiproject would we want to feature? I don't think we even have a week's worth. 1brianm7 (talk) 00:49, 19 October 2026 (UTC)
As the person who suggested it, I would oppose TGA. Also, there are simply not enough Wikiprojects (nor enough that would pass scrutiny to be on the main page) to make featuring them a realistic option. Eman7blue42 (talk page|recent edits) 00:55, 19 October 2026 (UTC)
Years ago, when something of that sort was suggested as a possible improvement to GA processes, one objection was that a process that only involved two people would be very vulnerable abuse and that once checks were put into place on top of the GA process it would be effectively duplicating the existing checks for GAs that appear on the main page as DYK facts. Rjjiii (talk) 01:14, 19 October 2026 (UTC)
We already have TGAs; its called DYK, so I oppose that, and I frankly don't get too much value from the first (also echo the concerns above about TGFWP). — Knightoftheswords(talk) 05:14, 19 October 2026 (UTC)
Some ideas I have 1. Widen TFA to be like TFL and TFP (I would personally keep it at the top due to its importance and value). 2. Widen OTD or HUITA and place it at the bottom, but above TFL and TFP Jon698 (talk) 00:45, 19 October 2026 (UTC)
That is the first use of HUITA on-wiki, after it was coined on the Discord! 1brianm7 (talk) 00:49, 19 October 2026 (UTC)
Pardon, but what is that? Chorchapu (talk|edits) 00:50, 19 October 2026 (UTC)
Help us improve this article (HUITA) Jon698 (talk) 00:51, 19 October 2026 (UTC)
Please don't use that. The correct acronym is TWAFI, or AFI for the wikiproject that manages it. "Help us improve this article" is just the name of the section, which is subject to change. FaviFake (talk) 13:04, 19 October 2026 (UTC)
I'm going to continue using HUITA Jon698 (talk) 01:34, 23 October 2026 (UTC)
@FaviFake: given that everyone calls Wikipedia:Selected anniversaries "OTD" and that hasn't materially impacted its mission, I don't think nomenclature policing is something TWAFI will need. (for the record, though, I pronounce TWAFI like "twahfee" with a heavy East Coast accent, and I do encourage this.) theleekycauldron (talk • she/her) 01:55, 23 October 2026 (UTC)
+1 Finally, I'm not the only one that says it that way! 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 02:46, 23 October 2026 (UTC)
Although I do think that, likely playing a part in the usage of "OTD", is the fact that having a section of the Main Page called "SA" would be... unideal and awkward at best. Chorchapu (talk|edits) 02:23, 23 October 2026 (UTC)
Yeah. Wikipedians need WP:3LA. FaviFake (talk) 11:37, 23 October 2026 (UTC)
Expand DYK to remove the rotating sets we sometimes have? Enoryt nwased lamaj (talk) 00:52, 19 October 2026 (UTC)
We've had discussions about expanding DTK at WT:DYK and there is firm opposition to the idea. TarnishedPathtalk 04:31, 19 October 2026 (UTC)
We could change the width so it could be equal, it would get rid of some of the space. There's an example here: Special:PermanentLink/1380348776.
I did suggest a "Today's Good Article" in the discord halfheartedly, but DYK essentially covers GAs on the main page.
Another idea I had is we can just move the "Welcome to Wikipedia" banner into just above TFA, having it contain a few sections describing the project. Other Wikipedias do this (e.g. French Wikipedia, which inspired this) Eman7blue42 (talk page|recent edits) 00:49, 19 October 2026 (UTC)
The width change is meant to happen, but we need an admin to perform the edit. Axolitl(talk|contribs) 00:56, 19 October 2026 (UTC)
My TLDR proposal would be to add a new column to the Main Page (which doesn't seem to be a bad idea since Classical-Futurist brought this up), and that is "Today's most viewed articles", helping to keep in sync with the mobile apps' home page (which has an autogenerated "most views articles" section). But if you know me, I like to flesh out on the details, so I'm just going to leave this for now, I will give details later (cause I need to go off-wiki now). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:52, 19 October 2026 (UTC)
I could see "yesterday's most viewed article" being a thing! Sohom (talk) 00:57, 19 October 2026 (UTC)
Yeah, I like that! I'd be like ITN on steroids. If the most viewed article had already been featured, pick the secondmost viewed, etc. FaviFake (talk) 13:06, 19 October 2026 (UTC)
I support this idea tentatively, but it would need its own RfC. And likely filters to avoid bot traffic. Bremps... 05:15, 20 October 2026 (UTC)
There's also a chance that it could be, say, the TFA, or (if a big real-world event happened) covered in ITN. Axolitl(talk|contribs) 05:17, 20 October 2026 (UTC)
Then pick the second one on the list. FaviFake (talk) 10:52, 20 October 2026 (UTC)
Okay, another idea: rotate between TFL and AFI at the bottom of the page, such that TFL remains Monday, Wednesday, and Friday, while AFI is Tuesday, Thursday, and Saturday. Sunday could either be blank or be replaced with a few entries from the Top 25 Report (the most viewed pages from the previous week, my original proposal above). This would make less people see the AFI box, though. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 03:24, 19 October 2026 (UTC)
main page sections are meant to feature the quality (or goals to improve quality) of WP, and the problem with any Top 10 read list is that there is zero quality assessments there. Its interesting but main page is not the place for that. Masem (t) 12:44, 19 October 2026 (UTC)
I was/am perhaps irrationally dissaponted that the AFI main page implementation was never presesnted (such as in the form of a banner) to casual users who liked the main page as it was, nor were said users warned about it once it was finilized. My idea, therefore, would be to move AFI to a full-width module above TFL/TFP, and put ITN and OTD back where they were. Disnewuisux (talk) 00:58, 19 October 2026 (UTC)
I could see that, but I’m concerned that that would really decrease its effectiveness. Most casual readers won’t scroll down that far. I know I didn’t before I started editing. Chorchapu (talk|edits) 01:00, 19 October 2026 (UTC)
I'm mainly concerned with the fact that ITN is no longer the other module that's visible with zero scrolling. Had I known where AFI was going to go (I had literally no idea about this until an hour ago), I would've argued against that placement in those discussions. Perhaps another way would be to list some AFIs right under the contributor and article numbers. Disnewuisux (talk) 01:11, 19 October 2026 (UTC)
As an ITN editor I’m certainly not unbiased on this matter:) but I do agree that TWAFI should not have gone here. I also don’t know if readers will see it in the grey box at top - it doesn’t stand out at all. Chorchapu (talk|edits) 01:14, 19 October 2026 (UTC)
I agree it still wouldn't be very visible, but it doesn't have to be grey like the rest of that box, and it could be a larger font size as well to stand out. I'd make a mockup of it, but I have to wake up in about 7 hours, and I'm not experienced enough to do it quickly.
P.S. Thank you for your service in ITN, it's literally my main source of world news. Disnewuisux (talk) 01:23, 19 October 2026 (UTC)
Interesting ideas… we’ll have to think on all the different plans. And thanks very much for the compliments. Chorchapu (talk|edits) 01:24, 19 October 2026 (UTC)
Having thought about it for a bit, I would support this. Axolitl(talk|contribs) 02:56, 19 October 2026 (UTC)
I support the panel because it leaves a cautionary tale for front page readers on taking Wikipedia seriously as a acceptable source of information. It informs more than a rational argument ever could ~2026-47221-77 (talk) 01:35, 21 October 2026 (UTC)
This is precisely the opposite of what we want! But it wasn't an entirely unforeseeable outcome... Chorchapu (talk|edits) 02:01, 21 October 2026 (UTC)
Note: The width of the columns were adjusted as they apparently were supposed to be (see ERRORS) and it doesn't look quite as bad anymore. It would probably need to be changed back for the addition of a half-width section to look good. Snowmanonahoe (talk·contribs·typos) 01:04, 19 October 2026 (UTC)
And with this change, I have a new idea: do we have the throughput to expand the size of the DYK set to 15 or so? Snowmanonahoe (talk·contribs·typos) 01:07, 19 October 2026 (UTC)
I don’t know if there are enough hooks or capacity for that. Chorchapu (talk|edits) 01:08, 19 October 2026 (UTC)
DYK does not have the desire or manpower to expand to 10 (from 9), let alone to 15. 1brianm7 (talk) 02:02, 19 October 2026 (UTC)
The current layout, with TWAFI causing a massive blank space under DYK, is untenable. I also feel that TWAFI should go under the other boxes which change daily; having TWAFI which by its nature only changes once a week be at the top makes the main page look more static than it is. My preference is for TFA, ITN, DYK, OTD to retain their original places, and TWAFI to be full-width (or half-width next to some other new box) between those and TFL. Davey2116 (talk) 01:08, 19 October 2026 (UTC)
I said this above, but I don’t think our readers will scroll down so far. You can read my earlier reply for more. Chorchapu (talk|edits) 01:10, 19 October 2026 (UTC)
Wow, that’s really terse and feels somewhat forced. I don’t want to cut that much, but maybe it’s necessary . Chorchapu (talk|edits) 01:13, 19 October 2026 (UTC)
OTOH if it's staying a whole week I think it would be better to not have the same thing right at the top of the mainpage for a week straight, also my (completely unfounded) assumption is that an article needing a scroll down but staying for a week would get at least the same amount of attention as TFA, if not more. With love from Maryland, charlotte👸♥ 01:16, 19 October 2026 (UTC)
Interesting. I didn’t take into account that, over the course of the week, it will garner more attention. That could work then, putting it lower. I don’t mind that. Chorchapu (talk|edits) 01:19, 19 October 2026 (UTC)
Indeed. Moreover, I do not think it was a good idea to put a section that was not on the Main Page previously right to the top. I understand that we want to garner more editors and teach everyone that Wikipedia needs their help, but still, there are ways to achieve that more slowly and succinctly without such a rapid change. At the very least, the news ought to stay at the top, as they are subject to more change.
Personally, I would append the weekly article for improvement horizontally and only under all the sections that are subject to daily (or even more frequent) change, that is, also below the featured list and featured image of the day (the two sections which could easily be subject to a further swap). BasicWriting (talk) 17:30, 19 October 2026 (UTC)
I like this reasoning as well; i.e. daily stuff on the top, weekly stuff on the bottom. Disnewuisux (talk) 01:14, 19 October 2026 (UTC)
Terrible idea, but maybe we could do a Wadde-Scheier (word barn (I assume)) like on the Pennsylvania Dutch Wikipedia. Prost, A.Classical-Futurist (talk) 02:04, 19 October 2026 (UTC)
Sorry, but what does that mean? Is it a sort of Wiktionary WOTD-esque thing? Chorchapu (talk|edits) 02:22, 19 October 2026 (UTC)
Comment (as a reader, not an editor for over a decade) - It was quite jolting to find ITN moved from its longstanding post. It has been one of my favorite sources of world-wide goings on for so long that I cannot remember when it became so. Seeing a new entry or image there is something I quite look forward to. Now a relatively random new article will appear in one of the two foremost spots on the page (what, once per week)? TFA features one of our best pieces of works and changes daily, which makes sense. Did you know features hot-off-the-press (or greatly improved) new content, which makes sense. On this day is interesting and fun. This new pseudo-recruitment junk, which is not relevant to the vast majority of readers, should be relegated to below TFP or besides TFL & TFP. There was consensus to add this to the main page in some way, sure. Doing so in the current manner is beyond the pale. Please ping me if I need to express this again elsewhere to potentially effectuate change. —Godsy(TALKCONT) 02:52, 19 October 2026 (UTC)
I think you said this a lot better than I could. This new box replaces a useful thing (ITN) in the prime real estate of the page, and shows off what is by its nature a bad article. I'm also not super thrilled that whatever consensus mechanism used for this was kept well away from readers/casual users. Joseph Zadeh (talk) 05:06, 19 October 2026 (UTC)
I agree with both of these points. TWAFI is a good thing to have on the Main Page, but I think it should be near the bottom, where it will be seen by people who have elected to keep scrolling and can be assumed to still be in search of something to do. Moonreach (talk) 20:33, 19 October 2026 (UTC)
Ooh, that’s a great angle. Consider me convinced, on moving it below the blue and green and above the TFL/TFP. Chorchapu (talk|edits) 20:36, 19 October 2026 (UTC)
I just wish I knew where I should be talking about this. I didn't see any discussion about changing the front page beforehand, so I don't know where to properly submit my complaint. Moonreach (talk) 20:38, 19 October 2026 (UTC)
I assume there’ll be a second RFC on what the hell went wrong and what we should change. It’ll most likely be posted on WP:CENT so I recommend keeping on eye on that. Chorchapu (talk|edits) 20:40, 19 October 2026 (UTC)
It's gone relatively well in my opinion. Vandalism hasn't stayed up long, new editors are actually taking an interest, and the article has improved. I think main page balance is not something casual/new readers care about to be honest, it's mainly annoying for "power users" like us. InfernoHues (talk) 20:44, 19 October 2026 (UTC)
+100 Most people won't scroll. If we move it below everything else, I believe we might risk not catching the attention of the fly-by viewers we're trying to convert into editors. FaviFake (talk) 20:46, 19 October 2026 (UTC)
I feel like inconveniencing regular users to draw in occasional users isn't a good strategy. Moonreach (talk) 20:55, 19 October 2026 (UTC)
the regular users aren't gonna be here forever, we need new ones. theleekycauldron (talk • she/her) 20:59, 19 October 2026 (UTC)
And they're not gonna leave just because they need to scroll a little to see the news. FaviFake (talk) 21:00, 19 October 2026 (UTC)
Maybe a section for the Wikipedia:Wikipedia Signpost? It’ll be interesting to see what the casual readers think of the Wiki drama. If that Signpost section makes the left column larger than the right one, then just add more blurbs/RD to ITN. Some1 (talk) 02:53, 19 October 2026 (UTC)
Not a bad idea too:) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 03:20, 19 October 2026 (UTC)
An interesting idea, but I don’t know if it would be good. Right now the Signpost is kind of a small thing, and readers I think will be entirely uninterested. But who knows, maybe it will improve its importance. Chorchapu (talk|edits) 03:22, 19 October 2026 (UTC)
I think this would be a very interesting idea, the Signpost probably should have some presence on the mainpage OrdinariusFingius (talk) 04:14, 19 October 2026 (UTC)
I don't see this being too interesting to our readers, and it comes off as being a lil WP:NAVELy. I'm also not a fan of potentially airing out Wiki controversies like that out at the open. — Knightoftheswords(talk) 05:17, 19 October 2026 (UTC)
@Knightoftheswords281: The signpost is arguably more useful to readers than AFI. The Signpost contains polished, well-written articles that are complete (at least I assume; I do not partake in it much, so I suppose it could be a partisan, yellow rag etc.). Articles for improvement features lackluster, poorly-written articles that are incomplete. I know which I would rather read to gain some sort of understanding or knowledge. Moreover, the Signpost is not asking readers to literally become a contributor like AFI is; what is more navel-gazing (in a roundabout way) than blatant overtures to join our editing corps? —Godsy(TALKCONT) 07:42, 19 October 2026 (UTC)
At least AFI is actually attempting to link the reader into the processes that make Wikipedia. I don't see how any random reader would benefit from the WP:SIGNPOST, which features a bunch of jargon, people, and institutions that they're statistically likely not not really know and frankly care too much about. Also, as part of that, I'd say that the main page should focus on highlighting encyclopedic work, which The Signpost isn't. — Knightoftheswords(talk) 07:56, 19 October 2026 (UTC)
The main page should focus on highlighting encyclopedic work; fully agreed. It seems, with the intro of AFI, that is not the standard anymore; not saying that the Signpost is a good idea but just that it is a better one than AFI. —Godsy(TALKCONT) 08:14, 19 October 2026 (UTC)
+1 I'm an admin who spends a lot of time around here and I find the Signpost inscrutable much of the time. Dclemens1971 (talk) 20:47, 19 October 2026 (UTC)
This should have been all sorted out prior to TWAFI going live. TarnishedPathtalk 04:24, 19 October 2026 (UTC)
As far as I can see, the blank space has only switched sides. I also think this section title fails the requirement to have a neutral opening statement to a discussion. I will say one thing - it's a bit strange to see the main article still locked while the collaboration article is open to editing. Some may not remember, but it used to be the case that editing the main article was actively encouraged, and the rule was that the main article should not be locked unless the vandalism could not be dealt with by reverts/rollback/undo, and even then preferably for a few minutes or hours max. Don't take this as me disagreeing with putting the collaboration of the week at the top and leaving it open (I think it's great), it's just that the split reality strikes me as odd. ~2026-55913-20 (talk) 04:30, 19 October 2026 (UTC)
This is not an RfC, so it doesn't need a neutral opening statement. Axolitl(talk|contribs) 04:32, 19 October 2026 (UTC)
I see what you mean. I was confused by you saying fails the requirement to have a neutral opening statement to a discussion, which is the language used for RfCs. Axolitl(talk|contribs) 04:39, 19 October 2026 (UTC)
IMHO the simplest option is to make HUITA full-width like tFL and tFP, but leave it at top so it's the first thing newbies read.
Digression: do newbies ever visit WP:MAIN? It strikes me as something only an insider would find.
A nice ancillary benefit is that experienced users can then slot the ITN section into where their eyeballs habitually expect it by just scrolling down. Bernanke's Crossbow (talk) 04:55, 19 October 2026 (UTC)
This was such a dumb idea, even if it gets a handful of people editing Wikipedia. The visual balance is completely thrown off one of the most famous front pages on the internet. It obviously should go below the featured image to fix the space issue. All the other material featured on the front page is the product of a significant amount of time of thousands of people. I find it insulting personally that such a poor quality article shares such a space and I am even more skeptical as the chosen article is so insignificant and so juvenile. The image used is basically an advertisement for IT'SUGAR, a shit overpriced American mall store. Disappointed that this is the best this community can come up with to draw more people into the club, which has pretty obvious solutions, some of which are being followed already. Thriley (talk) 05:21, 19 October 2026 (UTC)
As somebody who doesn't understand it, I don't think it's fair (or necessary) to say "a dumb idea". You have some good points about the image though (and I personally think it's a bit cluttered); I think if you'd like, you can raise them at WP:ERRORS? GreenLipstickLesbian💌🧸 05:25, 19 October 2026 (UTC)
I think it was a bad idea. In my culture we often call those dumb ideas. I wanted to use a stronger form of bad. Thriley (talk) 05:27, 19 October 2026 (UTC)
An image being featured doesn't mean its an advertisement, but I do agree that it is kind of iffy having TFA, DYK, OTD, and ITN dominating the front page and then having an article explicitly of poor quality take up so much space. I understand that's sort of the point, but man... especially with the points I raised below relating to its week long duration. — Knightoftheswords(talk) 05:30, 19 October 2026 (UTC)
Dinner comes first. You stuff yourself with poor quality candy in private. Thriley (talk) 05:38, 19 October 2026 (UTC)
... What? FaviFake (talk) 00:02, 21 October 2026 (UTC)
I think AFI should be placed in between DYK and TFA OrdinariusFingius (talk) 05:39, 19 October 2026 (UTC)
I feel like notifying the relevant WikiProject(s) was enough already (example). Most people read Wikipedia, not edit it. Yes, it may attract new editors, but shoving this in the faces of readers is too much in my opinion. Either move it below On this day or entirely remove it from the Main Page. Fortek67 (talk) 19:44, 19 October 2026 (UTC)
Given that HUITA is going to appear for a full week, rather than a day, I frankly don't buy the argument that pushing it say, above TFL/TFP will mean that it will be less effective. That's an argument that only really compares to the other sections of the MP, which (even ITN) changes on a daily basis. I don't think that's a bad idea. Alternatively, maybe putting it up in the welcome box as some have stated, though I have no idea how that would work aesthetically or what not. Perhaps I'm biased as a regular ITN contributor, but as indicated above, there's clearly a lot of people that see harm being done in pushing it and OTD down the page.
I can easily see the article being changed more than weekly. The weekly time was mainly chosen because that's how AfI already worked, but it was brought up in the RfC that a faster pace should probably be done if all went well. InfernoHues (talk) 05:33, 19 October 2026 (UTC)
ITN has had plenty of notice of this. For example, see New-look main page opportunity for ITN. The reaction in that discussion was to wait upon the TWAFI implementation and so here we are. In the meantime, ITN has been preparing its own RfC for an extensive internal reform which starts with a proposal to abolish ITN altogether. That would be a quick fix for the white space! Andrew🐉(talk) 07:21, 19 October 2026 (UTC)
The AFI section contains a lot of unnecessary text. Firstly, there's absolutely no need to explain what the article is about when it's linked. Secondly, pointing out to what sections should be improved is a bit weird because it requires live updates as those parts of the article may have already been dealt with. Thirdly, WPAFI, which is also linked, is clear enough so that the last sentence seems redundant. While the idea to highlight content for improvement on the main page is good, its implementation looks poor and misaligned with the brevity and conciseness of all other sections on the main page. --Kiril Simeonovski (talk) 07:14, 19 October 2026 (UTC)
While it was clear that there was consensus to put TWAFI on the main page, the closer acknowledged the consensus about its placement on the page was “weak”. A weak consensus should have never been the basis for the biggest change to the main page in ages. The addition of TWAFI should be temporarily suspended and a new RFC should take place specifically to decide on TWAFI’s main page placement, widely advertised to ensure participation from all interested parties. Dclemens1971 (talk) 10:22, 19 October 2026 (UTC)
I feel like repeating this sentence because it sums up this whole discussion quite nicely: A weak consensus should have never been the basis for the biggest change to the main page in ages. There should have been more time, and much more awareness by the casual reader about this process. Disnewuisux (talk) 10:40, 19 October 2026 (UTC)
+1 Given that this is not open to normal challenges through the editing cycle (i.e. one must be an interface administrator to alter the main page), a strong consensus is [warranted] before implementation especially on our most prominent page. The decision to implement was poor; thus, [I]t should be pulled. It may have been implemented because [T]here is no easy way to overturn it and [this serves to] to diminish the [immediate] outrage discontenment through a false faux-status quo and to deprive us of a proper discussion; this is so wrong! Such possibilities would not need to be speculated upon if this had been handled properly.Clear proponents of AFI are even gatekeeping at WP:ERRORS to diminish the chance this is remedied through a quick removal. —Godsy(TALKCONT) 21:59, 19 October 2026 (UTC)
Wtf? I'm not "gatekeeping" anything. The rules of WP:ERRORS are as clear as day. "Removing a section" is not an ongoing error. Did you expect your complaint to remain there indefinitely?Only three editors out of at least a hundred think TWAFI should be pulled outright. Good luck getting consensus for that, on a page which has no archives. FaviFake (talk) 22:09, 19 October 2026 (UTC)
You are not a regular participant at WP:ERRORS. You are obviously a strong proponent of main-page AFI (evident here in this thread). You could have left that for anyone to remove if it was appropriate to do so (you also technically 'declined' something you do not even have the ability to carry out). Instead you remove it with a drawn-out edit summary, a seeming ostensible attempt to insulate the action. If it truly was not gatekeeping, it certainly easily lends itself to appearing that way. —Godsy(TALKCONT) 22:30, 19 October 2026 (UTC)
So I can't perform basic maintenance by removing blatantly off-topic discussions because I supported the RfC? Where is that written? FaviFake (talk) 22:37, 19 October 2026 (UTC)
Inability is different from advisability. —Godsy(TALKCONT) 22:48, 19 October 2026 (UTC)
Godsy participated in the RfC and so had their say. I participated too and voted B like them too. But, given the outcome of the RfC, its result should be given a fair trial. The rush of editors to the article is much greater than I expected and we should continue to observe how this works out. Making hasty changes would confuse the issue and there's no pressing need as the side effects such as a bit of white space seem to be entirely cosmetic. And a technical option has been provided for those who can't bear to look at a bit of white space. Andrew🐉(talk) 22:17, 19 October 2026 (UTC)
Noting that administrators, not exclusively interface administrators, can edit the main page. Regarding the decision to implement, it came from this closure of a month-long discussion, which found that:There is a consensus in favor of adding This Week's Article For Improvement to the Main page. However, a consensus to change the main page layout in this significant of a way reached with under 100 participants is, under policy, a relatively modest one. Given this, and given a consensus that ranges from ambiguous to "no consensus" for one of the necessary subquestions, the decisions reached in this RfC may be ripe for revisiting in a few months.I wouldn't have made the change on the Main Page if there wasn't community backing behind it, i.e. pushing a fait accompli. Yes, the consensus is of a relatively low level compared to the magnitude of the change, and consensus can change, but absent an implementation of TWAFI, there wouldn't be any reason to except more participation in another discussion on the exact same points. However, we should absolutely be conscious of the fact that putting it into a much broader light, and allowing people to see the impact of the change, will lead to many editors reconsidering their position (in one way or the other), and new editors/readers being drawn into participating in a future discussion over whether to keep TWAFI on the Main Page.This future discussion is necessary, as stated in the closure itself, if we want a broader discussion with more concrete evidence to establish a stronger consensus for or against this section, but it can't proceed if we stall the initial implementation that followed up from the existing discussion. Chaotic Enby (in solidarity · talk · contribs) 22:58, 19 October 2026 (UTC)
Feline Image Lengthening Lines Enough Retroactively (of the day). CMD (talk) 11:01, 19 October 2026 (UTC)
I strongly oppose having AFI at the top of the main page; I don't think we should be messing with the top of the main page without largescale community consensus. I support having it stretching across the whole screen like TFL or TFP, below TFA/ITN/DYK/OTD; being on the main page for a full week should get it enough exposure, even if it's further down. Skarmory(talk •contribs) 11:06, 19 October 2026 (UTC)
Perhaps we could have a space advertising wikievents such as editathons. I do think that the AFI needs some moving around so the main page is recognizable, but I definitely think that its inclusion is an amazing idea (just look at how many edits have been made to the article, it's bound to get some people into editing). Gaismagorm(talk) 11:32, 19 October 2026 (UTC)
a space advertising wikievents such as editathons We have that at community portal on the sidebar, which feels the right place for it.I definitely think that its inclusion is an amazing idea (just look at how many edits have been made to the article, it's bound to get some people into editing). Yes, absolutely! And so many of them are not registered! TWAFI is working exactly as intended, and moving below anything else will totally defeat its purpose. FaviFake (talk) 13:17, 19 October 2026 (UTC)
No evidence is provided for the claim that a lower position would not result in attention for TWAFI. Dclemens1971 (talk) 13:40, 19 October 2026 (UTC)
If I remembered the RFC correctly, there was a group of editors that said that putting AFI below the four other sections would reduce the success of AFI. I'll be glad if someone were to correct me if I'm wrong, though. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 13:44, 19 October 2026 (UTC)
You don't need "evidence" to reach the conclusion that if something is in the middle of a page rather than at the very top, fewer people will see it. This is precisely why P2 was chosen in the RfC. FaviFake (talk) 13:48, 19 October 2026 (UTC)
If TWAFI were somewhere else on the page, it would still be getting vastly more clicks than it was before it was on the main page. It doesn't need to be in P2 to get clicks. Dclemens1971 (talk) 20:29, 19 October 2026 (UTC)
Yeah, I guess that's true. But it's clear we'll need an RfC to decide where to place it, so i don't see the point in continuing this discussion. FaviFake (talk) 20:31, 19 October 2026 (UTC)
Yes, the point (that I made above, hours ago) is that we will need a separate RFC on where to place TWAFI on the Main Page. Your claim that moving below anything else will totally defeat its purpose is unsupported. Dclemens1971 (talk) 20:50, 19 October 2026 (UTC)
Sure. I think I'm just tired. FaviFake (talk) 20:51, 19 October 2026 (UTC)
Frankly I'm now of the opinion we should trash our Main Page and rebuilt it from scratch![Joke] Okay that's maybe a bit much, but I do think we should continue tinkering with the Main Page. I don't think that it should be something that is set in stone for all time; Wikipedia is an evolving project, and our Main Page should be evolving alongside it. I looked at other language Wikipedias for some inspiration and I recommend other editors do as well. Here are a few I found interesting: French Wikipedia (which has an explanation of what Wikipedia is and how users can contribute), Tagalog Wikipedia (not a fan of the color scheme, but it has an explanation of what Wikipedia is and how users can contribute), Vietnamese Wikipedia (has boxes of what needs to be improved), Italian Wikipedia (they have a section for the Nobel Prize winners and feature the image/quote/source/desination of the day/month from a few of our sister projects), and Farsi Wikipedia (looks essentially the same to our Main Page, but they have a box describing Wikipedia below their FA and DYK equivalents). There are few that are radically different from ours too, like Basque Wikipedia (they have a lot educational videos!). I found it kind of funny that a few of these have uneven columns leading to whitespace.
I really think that some sort of box describing Wikipedia would be good, like something along the lines of French Wikipedia and Tagalong Wikipedia. All we have is the banner reading "Welcome to Wikipedia, the free encyclopedia that anyone can edit". We should actually explain what that means to readers. Maybe it goes above FA, or below DYK, or somewhere else, but we should really have something like this on the Main Page.
Regarding readers not liking AFI being there, this was decided in an RFC months ago. If readers are looking for ITN, its still there, and I imagine its not going away anytime soon (unless the crazy proposal being workshopped at this RFC happens...). Eman7blue42 (talk page|recent edits) 15:04, 19 October 2026 (UTC)
Community Feed choices for the home screen of the Wikipedia iOS app
You should try the Wikipedia app which provides a variety of novel sections on its home page besides the usual ones. It also lets users decide which of these will or won't be displayed and in which languages. So you can build your own custom home page. Andrew🐉(talk) 20:14, 19 October 2026 (UTC)
That’s very cool. Unfortunately, other than that the app is crap, so I’ll never use it. Chorchapu (talk|edits) 20:22, 19 October 2026 (UTC)
I think the app is pretty good for reading. For editing, it's awful. InfernoHues (talk) 20:24, 19 October 2026 (UTC)
Im inclined to agree, but I never use it; I tried editing on it once or twice many months back (maybe over a year ago by now) and was so disgusted I’ve not touched it since. Chorchapu (talk|edits) 20:27, 19 October 2026 (UTC)
Can confirm. FaviFake (talk) 20:30, 19 October 2026 (UTC)
I am familiar with the Wikipedia app, it is what I use to read Wikipedia on mobile. I would not like the Main Page on web to be customizable for users. Eman7blue42 (talk page|recent edits) 23:58, 19 October 2026 (UTC)
We could make OTD full-width and split it into 2+ columns of bullets? theleekycauldron (talk • she/her) 16:45, 19 October 2026 (UTC)
It would make more sense to divide DYK which has 9 bullets to OTD's 4. Nine hooks in a block are too much of a wall of text visually and so would benefit from more structure. For example, the GA's might be separated from the new articles with a sub-heading or two. And this might provide an opportunity to add another picture: one for each sub-section.
So, I suggest that DYK experiment with such expansion while the white space provides room for growth.
It might make sense aesthetically, but DYK seemed pretty strapped at the moment, and regulars would likely reject the extra formatting work. Rjjiii (talk) 17:00, 19 October 2026 (UTC)
Separating out the GAs from the new/expanded articles when building and queuing sets is an extra layer of tedium for it's not clear what gain. Dclemens1971 (talk) 20:30, 19 October 2026 (UTC)
Also, what about making TFA full-width? It's a big block of text and certainly deserves the prominence; it might be a bit shorter but it can still fill the space and restore balance to the ForceMain Page. theleekycauldron (talk • she/her) 22:33, 19 October 2026 (UTC)
This is an equally good idea which I think should have just as much support behind it. FaviFake (talk) 22:35, 19 October 2026 (UTC)
Hello, i support withdrawing it completely, push it below in the news, it's very out of place, thank you MazurTutejszy (talk) 15:15, 20 October 2026 (UTC)
push it below in the news withdrawing it completely What? FaviFake (talk) 15:17, 20 October 2026 (UTC)
Not commenting on the placement on the main page, but it does appear that adding the feature to the main page is working. I just checked this week's article for improvement and there are hundreds of edits. So it appears to be working as intended. --Enos733 (talk) 15:11, 19 October 2026 (UTC)
Silly idea which might have some merits: put our centralized discussion (maybe with links described in a more beginner-friendly version) on the Main Page in that blank space. Helps with three main aspects in my opinion:
Filling the blank space, obviously
Keeping more casual editors/readers informed of major changes, and in turn allowing them to provide input
Showing readers a quick way to see "the other side" and understand how community discussions shape Wikipedia
And a bonus consequence of these latter two points is that we open another point of entry for readers to get involved with the community and maybe become editors themselves! Chaotic Enby (in solidarity · talk · contribs) 17:46, 19 October 2026 (UTC)
@Chaotic Enby: There is an instant fix (and you are uniquely positioned to carry it out). You could [now] revert your implementation of main-page AFI based on weak placement consensus which is causing an obvious aesthetic issue on our most prominent page. It seems obvious now (even just through the existence of this long thread) that a proper follow-up discussion regarding placement etc. [would be better pre-implementation] and that the implementation was inappropriately early. As it stands now, your suggestion above is just proposing a cure to a disease that you created. —Godsy(TALKCONT) 22:16, 19 October 2026 (UTC)
Please see note b in the RfC close. InfernoHues (talk) 22:27, 19 October 2026 (UTC)
A discussion not being mandatory does not mean it is not a good idea and consensus can change. —Godsy(TALKCONT) 22:46, 19 October 2026 (UTC)
The closer did not merely say a discussion is not mandatory. FaviFake (talk) 22:54, 19 October 2026 (UTC)
You are treating the note (which you solely quote from below) as mutually exclusive from the statement it amends, which has led you to poor conclusions. —Godsy(TALKCONT) 02:02, 20 October 2026 (UTC)
I think it's deeply unfair to blame Chaotic Enby for a consensus they neither created nor assessed. They couldn't reverse their implementation even if they wanted to, because that's what the community chose (as found by the closer). Attacking Chaotic Enby for others' choices is counterproductive and language like "disease" is, imo, needlessly inflammatory. theleekycauldron (talk • she/her) 22:31, 19 October 2026 (UTC)
@Theleekycauldron: Fair enough. I have striken parts of my statement above. I stand by the language itself as a metaphor, but admit that perhaps the direction it was sent was not entirely due. —Godsy(TALKCONT) 22:46, 19 October 2026 (UTC)
There is a world where establishing firm consensus on this crucial matter would be required, and thus the implementation would be delayed. This was not the case here. Given the commentary for this proposal overall, even by those who expressed serious concerns about P2 and/or who wanted an alternative not originally listed, there seemed to be enthusiasm for moving forward, and thus no consensus to delay pending a firm decision on this issue.
If you disagree with @Barkeep49's closure, you are welcome to contest it at WP:AN. FaviFake (talk) 22:32, 19 October 2026 (UTC)
FWIW, I completely agree with the sentiment in this discussion that the main page now looks off-keel and that having AFI so prominently featured is jarring and not ideal. I hope this brainstorm thread results in a more formal RFC so that we can restore balance to the main page. FlipandFlopped㋡ 22:02, 19 October 2026 (UTC)
That is the end goal, yes. FaviFake (talk) 22:10, 19 October 2026 (UTC)
Just wanted to let everyone know that they can help write the next AFI template at {{Article for improvement/data/2026/44}} before Sunday when it is protected. Feel free to add and improve the information there before it is protected, so that there aren't so many ERRORS reports about it. Axolitl(talk|contribs) 01:08, 20 October 2026 (UTC)
Meta meme to lighten the chaos:) Added 01:34Looks shorter which might help with MP balance. Also doesnt need to be that long because, if you know what Wikipedia is, then you know what an online encyclopedia is.Meta moment 🤣 But could someone help me add next week's box into the Wikipedia:Main Page/sandbox to test how this shortened blurb would look like? Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:26, 20 October 2026 (UTC)
Haha. It isn't actually going to be that short, it's just missing the article suggestions. Axolitl(talk|contribs) 01:28, 20 October 2026 (UTC)
I kept the description short and added only two bullet points to try and minimise the space it takes up. Chorchapu (talk|edits) 01:38, 20 October 2026 (UTC)
Attempts to shorten the currently running TWAFI blurb at ERRORS have been opposed on the basis that the RfC locked in a set format. 1brianm7 (talk) 01:46, 20 October 2026 (UTC)
Nothing in the RfC stops us from removing a bullet point. The wording "starting template" was specifically chosen for this reason. We can't change the entire format, but shortening the description and removing a bullet point should be fine. InfernoHues (talk) 01:49, 20 October 2026 (UTC)
The RfC selected a layout, but minor tweaks should really be feasible. No plan survives first contact, to paraphrase Moltke. Chaotic Enby (in solidarity · talk · contribs) 01:51, 20 October 2026 (UTC)
What happens if we add the TWAFI to the main page right now? [...] Would anything break in a serious way? Or would it be broken but in a manageable way? If it's the latter, then I say we do it. Once it's on the main page, more people will come, enraged that the project is in such bad shape, and they'll help fix everything. – FaviFake (anchor link)(diff link)
Did the Main Page "break"? Yes, but only marginally, and we've already have a temporary fix for that using the column width adjustments. Was it done haphazardly? Probably. Were all the automations and templates not set up properly? True. But was the overarching goal of improving an article and getting new editors achieved? One. Thousand. Percent.And regarding "Community consensus certainly never endorsed that idea in the RfC", no? The RfC concluded that there is consensus to add TWAFI onto the main page, and new approaches must be tried in order to convert readers into editors. Even if consensus for the design and placement are weaker, remember, these are starting templates, and we will most likely change them in a future RfC. The reason why we decided to go ahead and boldly add it is to allow more editors to give their feedback on the new section of the Main Page (and it worked!). In other words, if not now, when? Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 02:56, 20 October 2026 (UTC)
Although "wiki" comes from a Hawaiian word, "wikiwiki", meaning to be quick, these days "break things" isn't in favour with the community, given the current size and scope of English Wikipedia. That being said, it's willing to weigh pros and cons and accept practical compromises. isaacl (talk) 02:30, 21 October 2026 (UTC)
But being bold is part of the WP:BRD cycle. I don't think anyone had the chance to revert it did they? Main page is protected by administrators. Bait30Talk 2 me pls? 19:52, 25 October 2026 (UTC)
WP:Be bold also literally says Making major changes to the graphical layout of certain pages that are not articles requires caution... You should establish consensus before making design edits to these types of pages. Examples include the Main Page (which in any case is permanently protected), the Community Portal, the Featured content group of pages, and the group consisting of Wikipedia:Contents and its subpages, as well as Portal:Current eventsBait30Talk 2 me pls? 19:56, 25 October 2026 (UTC)
Most main page content changes every day. There's a standard process for getting corrections and reversions done; it's WP:ERRORS and the introduction of TWAFI was raised there. Andrew🐉(talk) 20:01, 25 October 2026 (UTC)
Speaking as someone who reads Wikipedia far more than edits, I do think that this haphazard approach to adding it is explicitly not a good thing.
I feel as though lot of people in here are sort of blind to the fact that the average wikipedia user (as in, someone who edits infrequently or just reads the site) has absolutely no idea that the RFQs exist. I certainly didn't (I've since learned - quickly, and much against my will), and even if I had, it seems like almost nobody knew about the one to add TWAFI to the main page. There was no banner or popup, no indication that anyone was even asking for opinions. (Based on the weak consensus given, it seems like even those who did know didn't seem to care)
This is what makes the inclusion so much more jarring and galling: Not only did it appear with no notice, displaced more steadfast (and, in my personal opinion, desirable) things like ITN and OTD, purposefully showed off a sub-par article, created a massive gap at the bottom of DYK, and generally cluttered up the main page of one of the biggest sites on the English-language internet, but it happened because a very small group of people made an RFQ that nobody read, and then decided "well why not?" put it front-and-center. This is not how a major reference site should be run. I recognize that there is always the argument of "if not now, when?" but this isn't a small blog, it's Wikipedia. To quote @Godsy up above, "We know it is bad; put it on the main page anyway" is not how things should be conducted. Joseph Zadeh (talk) 03:10, 21 October 2026 (UTC)
There was a notice at Talk:Main Page and Wikipedia:Village pump (technical), but for people who don't go on noticeboards often there isn't a great way to notify them. Also, the RfC was by no means a very small group of people (albeit not a huge group of people), with there being over 250 comments. Also, if we "knew it was bad", we wouldn't have in fact put it on the Main Page. The templates were prepared, being as close as possible to the RfC mockup. The way FaviFake put it wasn't necessarily ideal and I think it kind of misrepresents the situation, because really most of it was ready. Axolitl(talk|contribs) 03:22, 21 October 2026 (UTC)
Very true, although I do still agree that, down the line, a more visible notice (either as a sitenotice or a Main Page-specific one) could be a good thing to get feedback from a broader variety of readers and editors for major changes like this one. Chaotic Enby (in solidarity · talk · contribs) 08:02, 21 October 2026 (UTC)
Forgive me, but 250 people on the scale of wikipedia is a tiny number. The main page alone sees over 23 million viewers a day, and hasn't been meaningfully changed in, what, almost 15 years? For there not to have been a notice, of any kind, on the main page is frankly absurd. It didn't even have to be anything big or obtrusive, but something should have been done. Joseph Zadeh (talk) 15:40, 22 October 2026 (UTC)
Yes, it is a tiny number on the scale of Wikipedia readership, but for formal Wikipedia discussions it's quite a lot. That discrepancy is kind of the reason we went for this. We need more readers editing! –Maltazarianᚾparleyinvestigateᛅ 15:53, 22 October 2026 (UTC)
The way FaviFake put it wasn't necessarily ideal and I think it kind of misrepresents the situation, because really most of it was ready. That's true. I came in rather late and didn't realise how much stuff had already been finished. We really just had to make a few fixes. FaviFake (talk) 12:26, 23 October 2026 (UTC)
I will say that I thought that was in poor taste to try and rush Main Page implementation (see: Even though the enthusiasm is great, I think we should push this at the earliest on Sunday (as a natural day to start) and post an announcement to some noticeboards about the changes, with a space to suggest changes and provide feedback.) I don't think we ended up really rushing it too much though. Axolitl(talk|contribs) 03:01, 20 October 2026 (UTC)
I fully stand by my comments. The implementation on the Main Page had stalled and the only way we could get enough eyes was to actually do it. As Axolitl pointed out, we didn't really rush anything because we mostly already had everything that we needed.But it sounds like you're upset with its placement more than the way it was implemented. The placement would've remained the same even if we had meticulously planned everything. FaviFake (talk) 10:52, 20 October 2026 (UTC)
I agree that we could have been slower to get to the Main Page, per WP:NODEADLINE; there were still things that I wanted to discuss that were left as fait accompli, not to mention that it could have slowed the onslaught of comments (I'm up to about 1 notification a minute). At the same time, when we spend practically all of September in a slow-mo discussion of page styling, NODEADLINE starts looking like NEVERWILLBEDEADLINE. 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 01:34, 21 October 2026 (UTC)
In 2009, a widely-attended RfC was closed with strong consensus in favour of merging WP:PAM into AfD, but it wasn't implemented due to technical difficulties and inertia. It took us 15 years to do it all over again, this time successfully. (See WP:RENAMEAFD)I just like to keep that in mind when it comes to implementing the result of an RfC. FaviFake (talk) 16:47, 21 October 2026 (UTC)
I still think TWAFI needs to come before all other boxes:
100% agreed. This would clearly convey that we're first and foremost a Wikipedia written by volunteers for free. Start with that, and then show off our greatest and most relevant works that we wrote as volunteers. FaviFake (talk) 16:40, 21 October 2026 (UTC)
On the other hand, this pushes featured lists even further down than they are now, which goes against the idea of showing off our greatest and most relevant works. I'd prefer something like:
TWAFI
TFA
DYK
TFL
ITN
OTD
TFL, when it is being run, would poke up from the bottom inviting readers to scroll down and see it, and because ITN generally has entries for longer than a day the non-consecutive days that a TFL is shown would not affect it that much. OTD gets sidelined a bit, but it's a lower priority as far as I'm concerned. –Maltazarianᚾparleyinvestigateᛅ 17:58, 21 October 2026 (UTC)
Pushing ITN so far down definitely won't work. FaviFake (talk) 18:28, 21 October 2026 (UTC)
Why not? It would be a more visible situation than what we are giving some of our best content right now, and after all, that's quite a lot considering we are WP:NOTNEWS. –Maltazarianᚾparleyinvestigateᛅ 18:45, 21 October 2026 (UTC)
The majority of placement complaints have been from people who have built up muscle memory to check ITN daily. While I'm sure similar memories have been built around the other sections as well, I think the other sections would be more amenable to being moved around. InfernoHues (talk) 18:47, 21 October 2026 (UTC)
Alright, no touchy the ITN, got it.
TWAFI
TWAFI
TFA
ITN
TFA
ITN
DYK
TFL
DYK
TFP
OTD
TFP
OTD
TBD
TBD
Give the TBD slot to the thing being cooked up in the #CENT on the main page? section. Eh? Out with the old (OTD, in more ways than one) and in with the new, and most things stay in similar places. I guess I'm essentially just calling for revolution against OTD at this point, but hey, I don't mind that. Too much classical music! –Maltazarianᚾparleyinvestigateᛅ 19:38, 21 October 2026 (UTC)
Yeah, OTD has very few defenders. It's generally my guess that this ensuing RFC could end in, at its most revolutionary outcome, the end of OTD and marginalization of one of DYK, ITN, or TWAFI. I think anything that marginalizes two of the latter will be unable to gain consensus.I've dedicated some thought to the matter, but I can't think of way to give OTD buy-in from the editor community. It's the only section of the page that lacks any substantial editor interest and only serves readers, especially considering the desolate wasteland that is year articles (it appears they had more interest in the earlier years). TBH, I think if you significantly reduced it to like three blurbs that have less than 300 characters in total, there would be literally no pushback from readers or anyone. 1brianm7 (talk) 20:13, 21 October 2026 (UTC)
I'm fine with pushing OTD down. As a reader though it still has to exist. In solidarity, Aaron Liu (talk) 20:48, 21 October 2026 (UTC)
@Aaron Liu: I believe the WMF's mobile game is also scrubbing OTD for dates. Rjjiii (talk) 20:50, 21 October 2026 (UTC)
I'd imagine it just uses the articles for the days (like October 21) but I'm not sure. Axolitl(talk|contribs) 21:51, 21 October 2026 (UTC)
If we push down OTD I don't think we need to marginalize TWAFI or ITN (or DYK, but that wasn't happening anyways, obviously). –Maltazarianᚾparleyinvestigateᛅ 21:19, 21 October 2026 (UTC)
Has nobody raised that TFP features panoramas yet? In solidarity, Aaron Liu (talk) 20:47, 21 October 2026 (UTC)
Uhhh, the options would be to run TFP as a wide one below DYK and TFL when TFL is running, with OTN and TBD below that, or to do it as we do now, with OTD in the slot to the right of DYK (if we do that I suppose we should consider sticking OTD under TFL when TFL is running). –Maltazarianᚾparleyinvestigateᛅ 21:26, 21 October 2026 (UTC)
@Maltazarian What did you use to make these cute tables? I wanted to try using that compact design for the next RfC. FaviFake (talk) 20:44, 28 October 2026 (UTC)
Sorry to disappoint but it's ad hoc raw CSS. I just put it together on the fly. –Maltazarianᚾparleyinvestigateᛅ 21:40, 28 October 2026 (UTC)
nooooooo:( FaviFake (talk) 21:44, 28 October 2026 (UTC)
I expected the layout to not have that much of an effect (since we'd mostly be shuffling blank space around, from below DYK to TWAFI's right). After testing, with the current 46/54 balance, it does push TFL down by four lines, although switching back to 50/50 brings it to only three lines. Surprisingly, 55/45 doesn't help more, and is in fact slightly more unbalanced than 50/50 right now. Chaotic Enby (in solidarity · talk · contribs) 19:19, 21 October 2026 (UTC)
I highly agree with this layout OrdinariusFingius (talk) 22:21, 21 October 2026 (UTC)
Not sure where to add this comment, but if we are creating a full row, why aren't we considering ITN to have the full row? - Enos733 (talk) 17:00, 22 October 2026 (UTC)
How about TFA? After all, it is the best Wikipedia has to offer. 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 17:06, 22 October 2026 (UTC)
ITN already has enough strife and difficulty to fill the few spots it already has. In solidarity, Aaron Liu (talk) 21:40, 22 October 2026 (UTC)
This looks nice, but for colour balance I'd like the AFI box to be grey, instead of green. I assume though that this is just a mockup, so the colours and such aren't meant to be accurate here. Chorchapu (talk|edits) 22:39, 21 October 2026 (UTC)
Well, either way, something has to be done to fix the piss-poor placement of TWAFI penal. BattleshipMan (talk) 01:20, 22 October 2026 (UTC)
Strongly oppose giving TWAFI any placement priority over TFA, ITN, or OTD and do not understand the current push to bury OTD, nor do I see any P&G-based reason to do so being proposed. ―"GraveDragon-X"(hihi) 05:58, 22 October 2026 (UTC)
... Are there any P&G-based reason to keep TFA, ITN, or OTD on top? FaviFake (talk) 11:39, 23 October 2026 (UTC)
Are there any P&G-based reasons against? When there's none, then it's the wild west. In solidarity, Aaron Liu (talk) 00:32, 24 October 2026 (UTC)
I propose we delete the main page per excessive and insurmountable WP:SELFREF violations. FaviFake (talk) 00:36, 24 October 2026 (UTC)
I think a better reply would have been to help me understand why there's an active push to bury these things to begin with. ―"GraveDragon-X"(hihi) 02:28, 25 October 2026 (UTC)
There isn't. There is, however, an active push to add TWAFI to the main page, and unless we're gonna add it at the very bottom of the page, some things have to change for that to happen. FaviFake (talk) 11:09, 25 October 2026 (UTC)
I'm seeing comments like Out with the old (OTD, in more ways than one), OTD has very few defenders...[T]his ensuing RFC could end in...the end of OTD...I think if you significantly reduced it...there would be literally no pushback from readers or anyone., and I'm fine with pushing OTD down. and now I'm being told that there isn't a push to bury OTD. Am I being gaslit here? ―"GraveDragon-X"(hihi) 16:23, 25 October 2026 (UTC)
As one of the quoted, OTD was not really in my mind when I voted to place TWAFI at the top. ITN was, and I thought that giving it a scare and showing that it needs to not be so dysfunctional if it wants the community to give it such billing would be desirable, but even then my position mellowed before the RfC ended and I withdrew that position. OTD does exactly nothing for editors, and has routinely decided that showing quality content, complying with copyright, and other such infantile matters were below it (look at the history of Serbia appearing on OTD...). I have no love for it, a sentiment shared by almost all editors. Did you know that, in the entire history of Wikipedia, about one hundred editors have said they or someone else were a DYK editor. About two dozen at ITN. Exactly 1 editor has combined the phrases "OTD" and "editor". There isn't a push to bury OTD--that implies controversy or subterfuge. There is a common recognition that nobody cares about OTD. 1brianm7 (talk) 17:20, 25 October 2026 (UTC)
Get this straight. We should figure out a way to move TWAFI anywhere else that is not above ITN. BattleshipMan (talk) 18:14, 25 October 2026 (UTC)
We have a RfC prep ongoing here, if you'd like to weigh in. 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 18:24, 25 October 2026 (UTC)
OTD does exactly nothing for editors
Wikipedia is an encyclopedia for readers first and foremost, especially its front cover. The OTD column performs Wikipedia:Featured content's purpose of surfacing quality content quite well by pageviews. I don't see reason to believe Serbia represents bigger issues with quality control.
Exactly 1 editor has combined the phrases "OTD" and "editor".
Unlike the other columns, OTD does not have a set regular frequency where it needs edits, because it is a portal like 366 mini-articles that only needs an article frequency of editing. In solidarity, Aaron Liu (talk) 18:30, 25 October 2026 (UTC)
Strong oppose. Putting a static updating weekly) element with a poor-quality article over everything else on wikipedia is outrageous. Put it below OTD and TFA along with TFP, if it has to stay on the main page at all Joseph Zadeh (talk) 15:43, 22 October 2026 (UTC)
Strong oppose: The placement on it is extremely stupid and it should've been above the news penal and such. It's very inconvenient for many users and it should not be the main part of the Main Page. That has to be moved elsewhere on it or never have it there. BattleshipMan (talk) 06:19, 22 October 2026 (UTC)
Could you clarify whether you think the AFI panel should be above or below the ITN panel, and hopefully why (such as how it is an inconvenience)? In solidarity, Aaron Liu (talk) 21:38, 22 October 2026 (UTC)
That new TWAFI penal does not belong above the news penal and it's makes thing difficult inconvenient for desktop users. They would have to scroll down to see the news penal and "To this Day panel" which are traditional spots for many veteran users. BattleshipMan (talk) 03:52, 23 October 2026 (UTC)
Update and summary
The column widths have been adjusted again (see ERRORS again) to 46%/54%, removing the gap entirely. Personally, I don't think these width changes are ideal long-term (short-term this is for sure the right decision) as I beileve TFA should be the most prominent MP element. I've been following the discussion, and here is my attemptedly-neutral shortlist of ideas that seem to be gaining traction:
46%/54% columns (status quo)
New module for recent deaths
Make AFI full-width and put it below the columns somewhere
Make TFA full-width and put it on top
Shorten AFI
And noting that DYK regulars are firmly against expanding DYK. Snowmanonahoe (talk·contribs·typos) 23:41, 19 October 2026 (UTC)
We would accept and use whatever was given us at TFA. Trimming from a lede which is often twice the length we are allowed is one of the difficult parts of the job. Wehwalt (talk) 13:02, 20 October 2026 (UTC)
Lovely! Once a new discussion continuing this has been created at the Proposals village pump, I would support a full width TFA, with TWAFI taking its current place (top left). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 13:17, 20 October 2026 (UTC)
I would much prefer TWAFI to be made full width and placed at the top of the page, with TFA retaining its longstanding place below. The prose content of TFA won't be well suited to a wide view where readers have to scan across the whole page (which is usually wider than a typical article page) to read it. TWAFI is much more of an information box without direct prose, and will be noticed most if it's top and full width. Cheers —Amakuru (talk) 17:10, 22 October 2026 (UTC)
Note if any section were to be made full-width, it could still be laid out with multiple internal columns if desired to improve legibility. isaacl (talk) 02:29, 23 October 2026 (UTC)
Honestly this topic needs to be more organised, there's both people who are actually responding to the question (brainstorming), and there's people who are complaining about TWAFI as a whole (even though the aftermath of confectionery store being on the main page says otherwise). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:53, 19 October 2026 (UTC)
The 46/54 change was explicitly made as a temporary measure until something more could be resolved. The status quo for a decade plus is 55/45. The change from that to 50/50 in the immediate wake of TWAFI was also explicitly made as a temporary measure; I was the only person who expressed an opinion on it in the RfC, which was opposition. Personally, unless TFA wants it (and we already know DYK doesn't), I'd say that ITN, TWAFI, and OTD should work out how they each reduce or move out of the top to fit in size (this position doesn't account for whatever the idea of splitting RD is). 1brianm7 (talk) 23:54, 19 October 2026 (UTC)
@Snowmanonahoe: As a group, I don't think we have discussed this yet. One of us will post here if we have a consensus opinion about this specific proposal. If anyone has questions about any idea's implementation (like how it could work logistically or technically) feel free to also ping us. Z1720 (talk) 00:39, 20 October 2026 (UTC)
I think a combination of changing the column widths and shortening the AfI template would work. That's not my preferred option, but it's the easiest one to implement. InfernoHues (talk) 01:34, 20 October 2026 (UTC)
And also keeps TWAFI visible without scrolling, which would otherwise reduce its effectiveness. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:45, 20 October 2026 (UTC)
Anything but the 46%/54% columns (it looks worse to me than having the gap below DYK). I'll also throw in my suggestion again for a new module that just explains what the English Wikipedia is.
For now, we can shorten AFI, but I don't think we should be moving AFI below the columns, as it is not in the spirit of the original proposal. Eman7blue42 (talk page|recent edits) 02:01, 20 October 2026 (UTC)
I don't think this was proposed yet, but what about slightly longer TFA summaries going forward?
Just add a sentence or two and I think we'd be good. Bremps... 05:20, 20 October 2026 (UTC)
I don't see it as particularly desirable to expand TFA to take up more space as a solution, considering TFL/TFP are already getting stuffed away underneath the rest of the main page, despite being featured content. Especially for FLs I think we are doing a disservice by sidelining it; it's some of our best content after all. If we're discussing an overhaul of the main page is in order, I would like us to do something about that, like putting TFL/TFP up alongside TFA, DYK underneath TFA and AFI under TFL/TFP. Prioritizing showing off good stuff and getting more people to edit, essentially. –Maltazarianᚾparleyinvestigateᛅ 18:20, 20 October 2026 (UTC)
46/54 is ugly. The eye just can tell something is off. I get it as an emergency measure, but it can't stay like that long-term. The 50/50 mockup was nice. CaptainEekEdits Ho Cap'n!⚓ 06:10, 22 October 2026 (UTC)
I agree that 50/50 is the natural horizontal balance and making it lopsided looks odd. Making it lopsided has technical side-effects too -- on my phone, the browser uses different font sizes for the uneven sides and this tends to cause more white space rather than less. Andrew🐉(talk) 08:39, 26 October 2026 (UTC)
That's interesting. On a phone, there should be no columns at all. In solidarity, Aaron Liu (talk) 22:01, 26 October 2026 (UTC)
I often use the desktop view on my phone as it shows more details and it's reasonably easy to read. Phones come in a variety of screen shapes and sizes now and there are intermediate devices like tablets. Andrew🐉(talk) 22:22, 26 October 2026 (UTC)
I assume he's talking about using Desktop mode on mobile. I do as well, because the mobile mode looks awful and is terrible for editing. But it does cause a few strange issues, such as that one which I experience as well. Chorchapu (talk|edits) 22:22, 26 October 2026 (UTC)
With this week’s new article for improvement (Mechanic) live on the main page, the gap is now in the right column. Some1 (talk) 04:20, 26 October 2026 (UTC)
It's also because ITN has reduced to three news reports, and OTD has been reduced from five days to four. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 04:22, 26 October 2026 (UTC)
I don’t think we need to fill the “gap” with anything then, and readers will just have to accept that these two main page columns can sometimes be uneven. Some1 (talk) 04:30, 26 October 2026 (UTC)
I think featuring an article for improvement at the top of the main page may cause that article to become a target of unintentionally disruptive editing by inexperienced users like the ones who would treat the newcomer tasks like a game they should try to win at. For example, an editor who wants to expand the article might ask an LLM to generate paragraphs to add to the article, and they might paste all that text into the article without checking for flaws. – MrPersonHumanGuy(talk) 11:19, 20 October 2026 (UTC)
That specific scenario has already happened a couple of times. People noticed it pretty quickly and reverted with an explanation. The edit notice shown to new users also mentions not using LLMs. InfernoHues (talk) 12:13, 20 October 2026 (UTC)
Really a stupid idea from the get go, and clutters the main page but it does attract a lot of edits. Kind of like adding a game show atmosphere to a professional looking main page of an encyclopedia (how soon do we get the daily WikiCrosswordPuzzle?). Either just remove it or move it well below the news section at the top, and cut back on some of the excess text and instructions (which can better be placed atop the article itself). Didn't follow where this idea came from but it may be one of those "running out of things to do on Wikipedia" make-work suggestions. Randy Kryn (talk) 14:17, 20 October 2026 (UTC)
On the topic of game show atmospheres, today's prize for unnecessarily disparaging comment goes to...! ~~ AirshipJungleman29 (talk) 15:15, 20 October 2026 (UTC)
How about one or two days a week and not daily. You're right AirshipJungleman29. What put me off earlier was the exclamation point, like a supermarket sale, but upon looking at the history page of the article of the week it seems lots of editors responded to this appeal and have edited the page. Also noted that many editors support this idea. It's still a gimic play, but I see more benefit to the plan. But not everyday, please. So, how about one day a week at the top and remove it from the daily main page the other six days. Best of both worlds. Randy Kryn (talk) 23:32, 20 October 2026 (UTC)
It's only been there for two days as of now. In solidarity, Aaron Liu (talk) 01:05, 21 October 2026 (UTC)
"but it does attract a lot of edits. Kind of like adding a game show atmosphere to a professional looking main page of an encyclopedia (how soon do we get the daily WikiCrosswordPuzzle?)" IMHO we should prefer more content and a less professional look (it worked well enough back in 2003!). I do recognize that other people may have a different ideal point on the tradeoff. Not clear to me how a daily crossword puzzle would help with either though. Bernanke's Crossbow (talk) 00:05, 21 October 2026 (UTC)
IMHO we should prefer more content and a less professional look A thousand percent. We're the encyclopedia that anyone can edit, not the encyclopedia that only has high-quality articles. FaviFake (talk) 00:09, 21 October 2026 (UTC)
A professional look for the doorway to the world's most read and representative encyclopedia is not something to disregard or change lightly. One day a week seems enough and would not keep putting the major attention of the top of the page on the same article every day for a week (maybe the ultimate in "undue"). Randy Kryn (talk) 00:12, 21 October 2026 (UTC)
The only way it became the most read and representative encyclopedia to begin with is because it was one that anyone could edit. We can't have one without the other, and we can't give the impression that it is a perfect reference work frozen in time at a point when it is in a dire need of new editors. Chaotic Enby (in solidarity · talk · contribs) 08:04, 21 October 2026 (UTC)
I think the point was not as much "running out of things to do on Wikipedia" as it was "running out of Wikipedians to do things". –Maltazarianᚾparleyinvestigateᛅ 13:05, 21 October 2026 (UTC)
I think we should rotate it more frequently. Once a week is too long, especially when it occupies prime real estate. Change it to daily improvement article or something like that. OhanaUnitedTalk page 18:45, 22 October 2026 (UTC)
Fully agree with that. As the article grows, we enter a state of diminishing returns, and it becomes harder for newcomers to find anchor places they can work on. Plus, it can easily look stale next to three Main Page sections receiving daily updates. Chaotic Enby (in solidarity · talk · contribs) 19:31, 22 October 2026 (UTC)
For ease of access, here is the article after each day: Day 0 (510 words, ORES score of 3.39), Day 1 (2407 words, ORES score of 3.92), Day 2 (2752 words, ORES score of 4.22), Day 3 (3109 words, ORES score of 4.2). Given the diminishing returns after day 1, and the appearance, I think daily would be best. Although we only have a sample of 1 and many experienced editors have been editing this, which is an outcome that was undesired by many in the RfC and which may not hold in future weeks. 1brianm7 (talk) 20:00, 22 October 2026 (UTC)
We're still improving the article, just that it's not the newcomers that are dong so. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:35, 22 October 2026 (UTC)
I held this position at the RfC. We are dedicating a week to one article. In that same period of time, DYK encourages the improvement of between 63 and 126 articles. ITN probably gets 20-30 articles worth of improvement (and a few tomats of bile). TFA gets 7. The numbers are slightly different because those processes have alternative goals, but it's undeniable that TWAFI is easily the least efficient (besides OTD, whose preference for abolition I have otherwise indicated). So... unless that alternative goal (attracting new editors) is succeeding, I will vote to make way for something else. We are giving it about equal visibility with TFA--it has to be doing something. I have largely refrained from editing the article because doing so will harm the primary purpose of this project, and every edit by an experienced user (besides reverts to vandalism and whatnot) makes it likelier that this project will fail. 1brianm7 (talk) 02:12, 23 October 2026 (UTC)
You want to get rid of OTD? Why? It's honestly one of the more entertaining and interesting things on the main page. Might as well get rid of DYK as well at that point. Joseph Zadeh (talk) 03:44, 23 October 2026 (UTC)
OTD is broken. It barely has enough people that work to maintain it, frequently falling into fits of disrepair. It does not drive any article improvement or activity in the project. The quality standards it enforces means that, when an editor reports that an article contains copyvio or is an unsourced stub, no action is taken because that meets the quality standards. With TFL, DYK, TFA, TFP, TFL, and even ITN we have created sections that are of interest to readers, while also providing motivation for editors and having some quality standards (not withstanding the bus factor that TFL struggles with). I would be supportive of an OTD that manages to encourage editors somehow and drive them to participate in it. I have theorized ways to do that and I have come up with nothing. Scrap it and let a new idea take its place. 1brianm7 (talk) 04:11, 23 October 2026 (UTC)
It is still getting additions, therefore I disagree. In solidarity, Aaron Liu (talk) 05:47, 23 October 2026 (UTC)
Hot take: OTD is only for the history nerds. I would have picked OTD to be thing I would work on the Main Page the last. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 05:20, 23 October 2026 (UTC)
20–30 articles for ITN is a bit optimistic, from my count. Right now, the fourth and last item dates back to October 11, for a total of 4 bolded and 5 non-bolded articles in 12 days, a little less than one per day.If you're counting RDs, the number gets closer, with the first two of the current batch of 6 having been added 4 days ago, or a little more than one RD per day. All in all, counting every link update, we'd get something like 15 per week? With many of them (especially on the RD side) already being in a good state when the death is announced, and the non-bolded links in blurbs having less quality control – I'd wager something like half of these are actually updated for ITN.Still, around one per day is a relatively good metric, and making TWAFI daily rather than weekly to match it would be ideal. Chaotic Enby (in solidarity · talk · contribs) 08:24, 23 October 2026 (UTC)
It's worth noting on this point that virtually everyone finds ITN's slow pace of posting to be a failure that we are constantly trying to fix. GreatCaesarsGhost 13:40, 25 October 2026 (UTC)
I do not think ORES should be our target end-all-be-all. The article can gain a very well-crafted section on confectionery stores in Canada without it affecting the article rating by a tenth. I disagree that these are diminishing returns. In solidarity, Aaron Liu (talk) 00:35, 24 October 2026 (UTC)
ORES definitely should not be the end all be all. Anybody can take a closer look at the article to see whether it has improved substantially in those 24 hours. I did not in writing a 5 minute comment. The 4 large expansions of article content in the fourth day, two by experienced users, doesn't seem worth such prominence on the main page, and its unclear whether we are getting many new users with this limitation. We could be giving new users another page in disrepair that some would have the capability to improve. The page views data is also in: a nosedive after about 30,000 views in the first day, and by the fourth day we only have half of that. So... in a few word, diminishing returns. 1brianm7 (talk) 04:45, 24 October 2026 (UTC)
I think that 4 large expansions that make the article better are 4 large expansions that make the article better, and 7 days gives everyone around the world a chance to participate. I value having those expansions more than quickly doing the first two days across every article, which may not even replicate those two days thanks to people's weekly schedules. In solidarity, Aaron Liu (talk) 18:33, 25 October 2026 (UTC)
+1, though I feel like two days or so would be best, so there's enough time for the article to settle before a new one appears. 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 20:30, 22 October 2026 (UTC)
Agreed. Bob the Builder is scheduled to be the AFI in a few weeks. There are a million TV shows out there and of all the articles that deserve to be highlighted for improvement on this project, it's ridiculous to put that one on the main page for a whole week. Let's please implement some change before then. I was thinking we could have like three articles in different topics running at the same time since the chances that any single article is in a reader's area of interest/expertise is low. Come on, of the millions of potential editors reading the main page, how many could possibly be that interested in a children's TV show? —Reywas92Talk 18:45, 23 October 2026 (UTC)
I'm still convinced that franchises, licensed IP, brands, companies or products aren't appropriate for TWAFI, both because of the specificity and the appearance of promoting them. Unlike a situation like TFA where we are promoting editorial work on the article rather than the subject itself, TWAFI's choice to feature a specific commercial topic as "to be improved" is a lot harder to justify from a neutrality standpoint. Chaotic Enby (in solidarity · talk · contribs) 18:55, 23 October 2026 (UTC)
I am similarly iffy about seeming to WP:PROMOte a television show on the main page, especially if for a whole week. Maybe later on when this AFI situation gets ironed out, but certainly not in the new month or two while we clean up its rocky start. Chorchapu (talk|edits) 19:14, 23 October 2026 (UTC)
Agreed. It has a chance of being seen as sponsored or paid in some way, and while that's not true we should avoid even the impression. Also, per asilvering on the AfI page, there's a sock master targeting that specific page, which is why it's EC protected. InfernoHues (talk) 19:17, 23 October 2026 (UTC)
Oh, the socking annd protection iseven a bigger problem. Chorchapu (talk|edits) 20:05, 23 October 2026 (UTC)
We definitely need to make it one day or half a week, but we still need consensus to change that, which I'll ask in a post-implementation RFC. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:36, 22 October 2026 (UTC)
I agree that it should rotate more than weekly. When it wasn't on the main page, AFIs didn't get all that much traffic. But now, we can summon a swarm of folks to improve pages every day. Daily, or at least every few days, makes sense. CaptainEekEdits Ho Cap'n!⚓ 03:00, 24 October 2026 (UTC)
The RfC probably also needs to parse out a possible relationship between position and duration. I imagine the proportion of editors preferring one week at AFI will be higher, the lower down on the page the section is placed. Rjjiii (talk) 03:57, 24 October 2026 (UTC)
Targeted discussion on proper position placement of TWAFI
I think we need a more targeted brainstorm discussion on the actual position/placement within the main page itself. Contrary to some above, I don't think TWAFI is a "stupid idea" and I think there's a fairly good consensus that it should go somewhere. The question which lacks consensus is where it should float (at the top, mid-section, or bottom)?
I agree that having it be at the very top both (a) confuses people who have been used to, for decades, seeing ITN at the top and (b) is more likely to attract unhelpful or disruptive edits. Screening out users who just click the first thing they see when they open Wikipedia, and thinning down the pool of people editing the article to only those who take the time to actually 'scroll through' the entire main page, would likely significantly reduce the number of disruptive edits. Opening up to thoughts from the community on this. FlipandFlopped㋡ 15:14, 20 October 2026 (UTC)
Given that TfA coordinators said they'd be willing to do a top bar, I think doing that and putting TWAFI below DYK would be nice. InfernoHues (talk) 15:18, 20 October 2026 (UTC)
I think putting TFA as a top bar would lead to the same criticisms from ITN folk (ITN would still be moved down, this time below TFA). I think there should be an option of simply extending the TFA space vertically to make the space needed. Eman7blue42 (talk page|recent edits) 16:35, 20 October 2026 (UTC)
Yes, making the TFA box deeper rather than wider makes sense. The main reason that the desktop view has columns is that long lines of text are not easy to read and so the TFA blurb wouldn't look good if stretched across the page horizontally. Andrew🐉(talk) 16:47, 20 October 2026 (UTC)
My preference is still to put TWAFI between the blue/green sections and TFP. Chorchapu (talk|edits) 16:50, 20 October 2026 (UTC)
I think that we should start thinking about how to format a proper RFC on that. I think there would probably be two questions: Where to put it, and how? Chorchapu (talk|edits) 15:50, 20 October 2026 (UTC)
If putting it at the top isn't an option, then our options are putting TWAFI between ITN and OTD, below OTD (still in the column), or below the columns entirely. If we choose to put it below the columns entirely, we'd then have to figure out where it goes among TFL and TFP. The AFI editors would be willing to work with any of these options I'd imagine, though a higher placement on the page would probably be preferred by them. Eman7blue42 (talk page|recent edits) 17:08, 20 October 2026 (UTC)
If we're going to do a placement RfC, all the options should be discussed. So to your list we can add below DYK, above DYK, filling the gap with a new RD section, etc. InfernoHues (talk) 17:11, 20 October 2026 (UTC)
All those are conditional on a consensus for a new RD section. I'm gonna make a list of each scenario:
New Recent Deaths section or TFA made wide and moved up - allows TWAFI to be placed under TFA or under DYK. I do not think a clear consensus would be found for moving TFA up though.
TFA expanded - allows TWAFI to be placed in the blue column either under ITN or under OTD. Since TFA is willing to work with whatever space is given I'd imagine they'd be okay with this.
TWAFI made wide and placed under columns - keeps TFA, DYK, ITN, and OTD the same as they were before. Further discussion would be had about its placement among TFP and TFL.
Perhaps this would be better worked as a main page RfC. Many options are planned to significantly impact TFA. ITN is already workshopping a megaRfC, so options in that that are not internal to ITN could be added. 1brianm7 (talk) 18:12, 20 October 2026 (UTC)
From what I can tell, these are all the serious proposals that have been set out so far:
TWAFI to the left side; expanded RD on the right side (we'd have to figure out where exactly)
TFA expanded to full width and placed at the top; TWAFI to the left side
TWAFI full-width below the blue/green columns, above TFL/TFP
Remove TWAFI altogether (unlikely, since it has unambiguously worked)
Another module on the left side (the Signpost, WP:CENT, or something else?)
Status quo of 46/54 columns
AFI above all, with white background
All featured content together (TFL/TFP to the top); total reoganisation of the page
There's also Special:GoToComment/c-Aaron Liu-20260702174700-Aaron Liu-20260702173800, AFI above TFA and with a white background. This had a handful but only a handful of supporters in the initial TFAFI RfC. (To Andrew's concern about desktop unlimited width, this would solve that as the AFI box's sentences are short anyways.)We would likely need to remove some of the options for a coherent RfC. In solidarity, Aaron Liu (talk) 20:26, 20 October 2026 (UTC)
I really liked that one, because it solves the spacing problem, places TWAFI right below "anyone can edit", and works on both desktop and mobile. 7amiþ = reform(solidarity).__init__(t, c) 20:32, 20 October 2026 (UTC)
I like it too! FaviFake (talk) 20:39, 20 October 2026 (UTC)
Yes, I forgot about that one but that works too. And I agree that we should slim down the options before going to a formal RFC. Chorchapu (talk|edits) 20:34, 20 October 2026 (UTC)
I suggest a maximum of five (including the "no" option), based on preliminary consensus found here. 7amiþ = reform(solidarity).__init__(t, c) 21:09, 20 October 2026 (UTC)
I'm not sure putting TWAFI above everything that would get enough support, especially with the reaction against its current position we've seen here already. I think the RFC is going to see a lot of pushback against TWAFI at the top of the page due to any variation of it pushing either ITN or TFA down.
Regarding trimming options, given what I've said, I don't think we should consider Option 2 (wide TFA) or Option 5 (adding something new). Adding something new without defining what that thing is first is probably always going to fail. Not that I am against adding something else new to the Main Page, but it should be an entirely different RFC discussion.
Honestly any change to the Main Page should be minimal (we've already added TWAFI to it we shouldn't go too overboard). I'd also add just expanding the TFA blurb as an option. Eman7blue42 (talk page|recent edits) 21:05, 20 October 2026 (UTC)
I also suggested having TFA and TFL/TFP side-by-side now that we're messing with the main page anyways. TFL/TFP has been marginalized to keep the status quo, but now that we're messing with the main page anyways it's two birds with one stone; fix the layout of the main page by moving featured content to where it is visible. –Maltazarianᚾparleyinvestigateᛅ 20:46, 20 October 2026 (UTC)
Another good idea! Looks like I'll need to make a new list:) Chorchapu (talk|edits) 20:50, 20 October 2026 (UTC)
TFL is only three days a week, so making it no longer a line would effectively require two different layouts. And making TFP a half-box would also shrink the picture. I do not think a proposal that simultaneously marginalizes TWAFI, ITN, OTD, and DYK has a snowball's chance in hell of succeeding. 1brianm7 (talk) 20:57, 20 October 2026 (UTC)
I like this! I've always wondered why those featured thinghies were all over the place. FaviFake (talk) 21:04, 20 October 2026 (UTC)
I agree with 1brianm7's reasoning here. Anyways, this RFC should be focused on how to better incorporate TWAFI onto the Main Page with minimal disruption. Moving TFL and TFP around are out of scope of this discussion should be left for another day. Eman7blue42 (talk page|recent edits) 21:09, 20 October 2026 (UTC)
We can just propose them as an option, if we can develop a layout that kills two birds with one RfC. FaviFake (talk) 21:11, 20 October 2026 (UTC)
I was just reminded by someone elsewhere (I see now 1brianm7 has also astutely pointed this out here) that TFL and TFP do not take turns, because TFP is every day. That was somewhat of an oversight, as it scuppers my whole idea. Whoops! –Maltazarianᚾparleyinvestigateᛅ 21:58, 20 October 2026 (UTC)
My preference is ITN, then TWAFI, for one column. - Enos733 (talk) 01:24, 21 October 2026 (UTC)
Hello, relatively new to editing but long-time reader here. Exact placement aside, my thought on TWAFI is that its box should be a different colour (perhaps light grey) to visually differentiate it from the rest of the column it sits in, since TWAFI is thematically at odds with the rest of the column's content. I get the impression that the green column's theme is curated info extracted from articles (TFA, DYK), while the blue column is for date-specific info (ITN, OTD). TWAFI is very different from either of these themes, so it would make sense for it to be colour-coded accordingly. I therefore also think it'd be logical for TWAFI to be at the bottom or top of the column, not in the middle. 𝕬𝖎𝖉𝖔𝖜𝖑(hoot!) 00:02, 21 October 2026 (UTC)
I completely agree with this, especially if TWAFI is moved up to its own row. I personally prefer the white background found at User:Aaron Liu/sandbox. With a white or light grey background, TWAFI will still be noticed by new editors, while regular MP viewers will be able to quickly scan down to the colored content that they may be more interested in. --Leviavery (talk) 22:18, 21 October 2026 (UTC)
Placing it higher increases the rate at which it attracts naïve users. You presume that it also increases the rate of disruptive edits, but has anyone from e.g. WP:CVU complained? If it's not requiring excessive (relative to the rate at which it converts readers to editors) counter-vandalism, then top seems best to me. Bernanke's Crossbow (talk) 00:13, 21 October 2026 (UTC)
Making this a standalone section as it quickly got sidetracked due to more pressing issues: what about putting a beginner-friendly version of our centralized discussion on the Main Page in that blank space?
Besides filling the space, it would help keep casual editors/readers informed of major changes being discussed, and provide input from demographics that wouldn't really have contributed otherwise, but would be just as affected by many of these changes. And, by showing a glimpse into Wikipedia's very community-based decisionmaking to more casual readers, it could help dispel myths or misunderstandings about how Wikipedia as a whole functions, and put some of them on the road to becoming more trustful of Wikipedia, or even to start editing themselves! Chaotic Enby (in solidarity · talk · contribs) 14:47, 21 October 2026 (UTC)
What I'm afraid of is broadcasting our internal strife out to the world via the Main Page. For example, many of the previous few months' discusisons related to the WWU dispute, and while the media did latch on to that, it would have been a much bigger deal if that had been placed on the Main Page, and it would certainly have hurt our reputation. We could simply omit that from the reader-facing version of CENT, but I'd be uneasy about such blatant whitewashing of internal discussions. Chorchapu (talk|edits) 14:57, 21 October 2026 (UTC)
You could add a "Full list..." link though. Also, don't forget about the Dashboard. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:14, 22 October 2026 (UTC)
There are a lot of things on TCENT that we don't really want or need input from new/non-editors on. Big RfCs restructuring backend processes, RfAs, and almost anything in the meta section ever come to mind. Like right now for example--it would take a solid 10-15 minutes to explain the context behind all three proposals up there, and they're not really ideas that would benefit from this kind of fresh perspective.
But I do really like one of your projected benefits—dispelling the myths about how our decision-making works. And there are decisions where reader opinions really do matter. I think WP:RBV22 is a good case study to look at here. It attracted a dozen or two readers that looked into our discussion processes just enough to stumble on it and complain about it. But that's a completely useless sample, right? What are we supposed to do with the information that twenty people did that? It doesn't tell us how many readers liked it or didn't notice and silently did nothing? Advertising these discussions on the main page could get us a better sample.
There are two problems with this, though. First, there are still sampling bias problems with this, and the WMF is probably better at conducting this kind of research. Second, how often do we have discussions like this? I literally can't think of any between V22 and TWAFI. Perhaps SiteNotices could be a better place for this idea. Snowmanonahoe (talk·contribs·typos) 15:02, 21 October 2026 (UTC)
I would strongly agree with any proposal that would dispel myths or misunderstandings about how Wikipedia as a whole functions, as I remember being utterly fascinated by the first RfCs and AfDs I saw. But CENT sounds like a terrible way to do that. Maybe the section could rotate between common questions that non-Wikipedians often have, like "Who decides which articles are featured here?", "Does Wikipedia have an editorial team?", "If no one is in charge, how are controversial decisions made?". FaviFake (talk) 16:32, 21 October 2026 (UTC)
That could work too! To clarify, what I had in mind was a more reader-friendly version of CENT, not the whole template. It's unusually empty right now (with only one non-meta discussion), but we quite often have discussions that would stand to involve readers more, even if it's not an immediate, massive interface change.Take some of this year's big debates. Would readers be comfortable with AI-generated Wikipedia articles? Do casual ITN readers want to see blurbs for recent deaths? Is Birthday Mode a distraction to the average reader, or a fun perk? Or, probably the one that would have benefited from reader participation the most: what to do with the Image Carousel?A lot of these, as you can see, are about features or policy changes that would directly impact readers, and often are envisioned for them. And yet, that has historically been the hardest demographic to poll, simply because readers won't be likely to stumble their way into our internal processes. We don't need every single CENT discussion up there, but we do want to prominently display those which would matter to many of our readers. Chaotic Enby (in solidarity · talk · contribs) 16:40, 21 October 2026 (UTC)
In fact, I think we could have both: a section with common questions, which readers can learn about, and the end of the section inviting readers to participate in currently debated "questions", if there are any suitable ones.P.S.: your proposal of rotating through common questions would also be a great motivation to make many of our help and explanatory essay pages more accessible, which is always a win! Chaotic Enby (in solidarity · talk · contribs) 16:43, 21 October 2026 (UTC)
My prediction is that FAQs make the target audience (skeptics) defensive, for lack of a better word. I'd rather not have an FAQ on the main page save for a single link. In solidarity, Aaron Liu (talk) 20:50, 21 October 2026 (UTC)
The flaw in this suggestion is "beginner-friendly version of our centralized discussion", which probably doesn't exist for the reasons Snowmanonahoe covers. The benefits FaviFake mentions are sort of what the "the free encyclopedia that anyone can edit" tagline and links are supposed to do, so the question I'd have for any proposal is what that proposal conveys additionally to that tagline, and whether it would stand out more than the tagline does. I think WMF does poll things like the birthday mode. CMD (talk) 01:16, 22 October 2026 (UTC)
Big no. I appreciate the brainstorming, but our inside baseball should not be advertised to 100 million people. Also, what goes on CENT is...an imprecise art. Right now, admins kind of have discretion to put things on there. But if it was on the main page, we'd need to reform the process of adding things, and I'm not sure that helps with the purpose of CENT. CaptainEekEdits Ho Cap'n!⚓ 06:03, 22 October 2026 (UTC)
Though for what its worth, I do like the thought process that is going here: could some other small thing be added that would help balance the main page? Maybe not CENT...but something... CaptainEekEdits Ho Cap'n!⚓ 06:04, 22 October 2026 (UTC)
Re. the imprecise art part, I fully agree, and that's why I suggested a "beginner-friendly version" (i.e. curated to some extent, to focus on questions accessible to the everyday reader, while still maintaining freedom of action on CENT itself). The argument made by Snowmanonahoe and CMD above (that such a beginner-friendly version couldn't work for a big part of CENT) is certainly convincing, and I'm open to more curation than I imagined initially, but I do still believe some of these questions can be made open to our readers' input.Where I strongly disagree is on the claim that our inside baseball should not be advertised to 100 million people. These people are our readers, and what makes Wikipedia unique is that every reader can be an editor, and participate in this inside baseball. We shouldn't be gatekeeping it, but showing readers how they can involve themselves and what takes place behind the scenes. The fact that these discussions are so closed-off to begin with is a dissonance with Wikipedia's core principles, not something we should preserve. Chaotic Enby (in solidarity · talk · contribs) 14:05, 22 October 2026 (UTC)
If there is only one or two entries to CENT (assuming this section of the MP requires three curated ongoing discussions), would also adding some from Wikipedia:Requests for comment/All work? Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 14:14, 22 October 2026 (UTC)
Presumably yes, assuming some of them are broad changes that will affect many readers/editors (e.g. not RfCs on individual articles). CENT is a guide on what could be relevant discussions, but the specific entries for the Main Page can absolutely be adjusted one way or the other.As I think about it more, the biggest weakness of this proposal is that we often won't have a lot of entries to list, so combining it with something like @FaviFake's rotating FAQ makes the most sense. Chaotic Enby (in solidarity · talk · contribs) 14:30, 22 October 2026 (UTC)
Maybe ones that are only being held because a broad consensus is needed, but other than that I'd think twice about advertizing to prospective editors disputes that are so entrenched that they require RfCs to resolve. –Maltazarianᚾparleyinvestigateᛅ 14:45, 22 October 2026 (UTC)
Readers who are unfamiliar with the backend of WP will perceive RfCs as opinion polls. When they engage in the RfC from that perspective, at best they will be ignored but more likely they will be scolded for not basing their comments on PAGs. Schazjmd(talk) 14:56, 22 October 2026 (UTC)
For that reason we should add a link to "before you add your comments" section to explain that RFCs or other forms of discussion are not a vote. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:40, 22 October 2026 (UTC)
I hope I'm not being over-cynical when I say, that there's not a chance that casual readers will click through the instructions before giving their opinions of things shown at them. Chorchapu (talk|edits) 23:45, 22 October 2026 (UTC)
I agree we need to be realisitic in expectations. As a future politician said (will say?), just because we can do a thing, it does not necessarily mean that we must do that thing. We should guard against the instinct to gatekeep discussions, but we should also not lead newcomers unaware into an environment where they are expected to have a certain base knowledge of community guidance and norms. That's just setting them up to fail and to become discouraged from further participation. isaacl (talk) 02:45, 23 October 2026 (UTC)
"Wikipedia has some new thing on the front page where the WMF asked for my opinion on Palestine and when I gave it, a mod banned me?!"Rjjiii (talk) 05:08, 23 October 2026 (UTC)
I do hope that we wouldn't be putting RfCs on ECR-restricted CTOPs (or for that matter any CTOPs) on the Main Page, for obvious reasons.Regarding the "before you add your comments" part, we do have {{not a vote}}, but banner blindness has to be taken into account. At the same time, we do want to provide newcomers with a learning environment where they can participate in discussions that matter while learning these community norms, and that's a space we don't really have right now. Chaotic Enby (in solidarity · talk · contribs) 08:27, 23 October 2026 (UTC)
So create new discussion spaces for that purpose, not shove newbies into high-level backend RfCs, doing a disservice to both sides. It could be "discussion forum on the layout, strengths, and weaknesses of the Main Page"/"do you regularly look at all main page sections", it could be "what do you most enjoy about Wikipedia/what do you think could be most improved", etc. Readers naturally curious enough to comment on or read these pages will be far more likely to fall down the rabbit hole, and all we need to do is show them an opening, not drag them straight to meeting the Queen of Hearts sorry for the increasingly-involved Alice analogy. ~~ AirshipJungleman29 (talk) 11:25, 23 October 2026 (UTC)
What, is @Queen of Hearts scary to newcomers now that she got her admin bit back? :pMore seriously, I do agree with the need to create new discussion spaces for aspects like the Main Page or everyday site layout that matter for readers, and that is exactly what I meant to say. Currently, these discussions aren't really solved through the usual P&G-based arguments (like, say, content discussions are), but by editors guessing what would benefit readers the most. Holding them in a reader-accessible place (maybe a prominently linked Wikipedia:Village pump (readers)?) could be very helpful.I'd love to boldly create it, but sadly, it does sound like the kind of idea that will need to go through unending consensus discussions to gain approval, before ever getting any feedback from readers about whether it would be helpful. Chaotic Enby (in solidarity · talk · contribs) 12:59, 23 October 2026 (UTC)
"new discussion spaces for aspects like the Main Page or everyday site layout that matter for readers," Ah, then disregard my somewhat flippant comment. I was thinking of putting the existing WP:CENT discussions on the main page. One of the current ones is about what article content is acceptable to transclude and how. One of the first examples brought up was {{Gaza war casualties}}, and I was imagining a reader new to editing, trying to join in on that discussion. Rjjiii (talk) 14:33, 23 October 2026 (UTC)
Sorry! My original proposal was indeed for a curated version of CENT (i.e. discussions relevant to your average reader and in which they could contribute constructively), but I've come to realize even these more accessible discussions operate in places where a baseline P&G knowledge is expected, which is not great as many of them do want to consider the benefit for readers, and I've moved to think that they might need a separate approach entirely. Chaotic Enby (in solidarity · talk · contribs) 14:55, 23 October 2026 (UTC)
I'm not sure if centralizing discussion is needed. Two important things I think we should get newcomers to know are that every (non-talk) page has an associated talk page for related discussion, and (just like communities offline) it's helpful to follow discussions on a given talk page first to get a sense of community norms. Once they understand these two things, they'll be self-empowered to find discussions in which they are interested, rather than having to rely on a curated feed, which risks gatekeeping. From the opposite side, the community should strive to be welcoming to those who skip the familiarization step and jump in with loudly expressing their (self-evidently obvious in their minds) view. isaacl (talk) 15:42, 23 October 2026 (UTC)
And newcomers who do make their way to talk pages often run into WP:NOTFORUM. I know I have been quick to revert and slap a Twinkle notice on the user's talk page. I am trying to provide a fuller explanation for such cases when I am not in a rush, but I need to work on doing better. Donald Albury 18:35, 23 October 2026 (UTC)
Banner blindness is definitely a very real and very big problem for new users. A friend of mine who I introduced to Wikipedia described {{uw-coi}} as “hate mail” - they just don’t read what’s written and either see nothing or a boring box with angry words. Dropping new users or readers right into the messy internal discussions would I fear do more harm than good. Chorchapu (talk|edits) 12:09, 23 October 2026 (UTC)
I've just had a totally different idea: what if we just made DYK longer? There's no reason we have to run X number of hooks a day, what if we just ran more in a go? Wouldn't that help fill space? CaptainEekEdits Ho Cap'n!⚓ 03:05, 24 October 2026 (UTC)
DYK has said pretty strongly that they don't have the manpower to run any more hooks than they already do. InfernoHues (talk) 03:10, 24 October 2026 (UTC)
Notes
↑and yes, that's a possibility! Seriously, ask your non-Wikipedia friends if they noticed that Wikipedia drastically changed its appearance three years ago, and the vast majority of them will say "no". This was even the case when I asked people two weeks after the rollout.
Watchlist: Titles and button names
On the Watchlist page, it would be nice to improve the button names to better match the content they display once pressed. In addition, page titles can be modified for better consistency. The default watchlist shows the title as "Watchlist" and the button as "View watchlist", while the content shows recent changes in the watchlist, not the watchlist itself. Then, when the "Edit watchlist" button is pressed, the title switches to "Edit watchlist", while the content displays the actual watchlist with the option to edit. Therefore, the following changes are proposed to the titles and button names. With these changes, the position of the word "Watchlist" is kept at the beginning of the title when switching between buttons; it is followed by a colon; and the word "Watchlist" is removed from all buttons. This makes titles and buttons more consistent. Also, the word "raw", which is somewhat vague, is replaced by the phrase "text version" to better reflect the content.
Title "Watchlist" and button "View watchlist" to be changed to "Watchlist" and "Changes", respectively. (i.e., no change to the title for the default case)
Title "Edit watchlist" and button "Edit watchlist" to be changed to "Watchlist: Edit" and "Edit", respectively.
Title "Manage watchlist labels" and button "Manage labels" to be changed to "Watchlist: Labels" and "Labels", respectively.
Title "Edit raw watchlist" and button "Edit raw watchlist" to be changed to "Watchlist: Edit text version" and "Edit text version", respectively.
Title "Clear watchlist" and button "Clear watchlist" to be changed to "Watchlist: Clear" and "Clear", respectively.
The end result at the default case is changed from: Watchlist
View watchlist; Edit watchlist; Manage labels; Edit raw watchlist; Clear watchlist
to: Watchlist
Changes; Edit; Labels; Edit text version; Clear
I don't find the Watchlist: Verb construction more informative. I actually find it more confusing. Schazjmd(talk) 22:39, 19 October 2026 (UTC)
I agree with Schazjmd, I find the current labels clearer than the proposed ones. Thryduulf (talk) 22:43, 19 October 2026 (UTC)
That's a great point by @Schazjmd about the titles. The idea is to fix the position of the page name Watchlist when switching between buttons. Right now it is floating when buttons are pressed. To address your point, we can do this: Watchlist ⇒ Short description. The updated result for five titles would be:
Watchlist
Watchlist ⇒ Edit watchlist (visual version)
Watchlist ⇒ Manage watchlist labels
Watchlist ⇒ Edit watchlist (text version)
Watchlist ⇒ Clear watchlist
The button labels remain the same as originally proposed (i.e., Changes; Edit; Labels; Edit text version; and Clear). Is it better now? PrinceTehran (talk) 03:50, 20 October 2026 (UTC)
I appreciate you taking on the feedback, @PrinceTehran. I had hoped other editors would offer their opinions after your changes before I replied again. To be honest, I don't really see a problem with the current version, and so I don't see any value in these changes. Schazjmd(talk) 20:22, 21 October 2026 (UTC)
I don't think they're 'buttons'. I think they're technically 'tabs'.
They already work the way I expect them to, and I already know what to expect from them. I have to agree with @Schazjmd: I don't really see a problem with the current version, and these changes would not be improvements for me. WhatamIdoing (talk) 03:31, 25 October 2026 (UTC)
First level documentation for "newish" editors
Is there a working group to reduce the learning curve for "newish" editors (say 100+ edits) to which I can contribute?
I've been editing daily for hours for almost a year. Once I went beyond simple tasks (upload an image, create a table, etc.), I faced a VERY steep learning curve to navigate the complex documentation for wiki syntax and policies. And I am still struggling even being a tech person.
The idea in a nutshell would be to extend the minuscule first layer of documentation so that "newish" editors can find what they need, via simpler instructions, better indexing to the more detailed content, etc.
I have checked the tabs and (lightly) checked the archives ("new editors") and found nothing on this topic, except for the mw:Edit check initiative which is focused on improving the Visual Editor.
Regards,
JPJp1008 (talk) 00:14, 21 October 2026 (UTC)
I think a WikiProject for folks to collaborate on easing the introduction to Wikipedia editing would be fantastic. Pinging Femke, who has done lots of work on this issue:) HouseBlaster (talk • edits • he/they) 00:20, 21 October 2026 (UTC)
Wikipedia:Help Project is a longstanding project. Updating documentation has been challenging over the years: since it's usually easier to reach a compromise agreement that includes more suggestions, help pages tend to expand with many additions. Subsequently, different pages, sections, and paragraphs gain their adherents and it becomes hard to find a way to restructure documentation. But the only way for improvements to happen is for someone to draft a new proposed page for others to discuss, so more power to anyone writing something up. isaacl (talk) 02:04, 21 October 2026 (UTC)
I've watchlistedb the wikiproject, so let's work together there. I'm very keen on making help pages easier to digest and more importantly, make the interface easier to understand. One thing I'll be proposing soonish is to make the 2017 wikitext editor the default source editor, so that people have an easier time learning the source editor if they prefer it over VE. In solidarity, —Femke (talk) 🐦 07:06, 21 October 2026 (UTC)
Isn't that the one that doesn't even have syntax highlighting? FaviFake (talk) 15:59, 21 October 2026 (UTC)
WP:2017 wikitext editor: it's simply the source editor with access to the VE toolbar. That means you can add tables with a few clicks and have the automated citation creator. In solidarity, —Femke (talk) 🐦 17:06, 21 October 2026 (UTC)
I find that to be much less important than syntax highlighting, especially if we want to help editors understand what those curly braces, angle brackets, and weird pipes are. Even I would be lost without it. FaviFake (talk) 18:15, 21 October 2026 (UTC)
I use the 2017 editor and it has syntax highlighting of some form. E.g., equal signs are bigger, things inside ref tags are green, things inside brackets are pink, most text is purple. 1brianm7 (talk) 19:16, 21 October 2026 (UTC)
So the image at mw:2017 wikitext editor is utterly outdated? It sounds like you're using the modern source editor or you have a syntax highlighting gadget enabled. Needless to say, I don't think we should make users enable such gadgets CodeMirror's syntax highlighting is already on by default. FaviFake (talk) 20:15, 21 October 2026 (UTC)
Syntax highlighting is a different setting. On mediawiki for me, syntax highlighting is off for both the old source editor and the 2017 editor. On enwiki, it's on for both. In solidarity, —Femke (talk) 🐦 20:27, 21 October 2026 (UTC)
Thanks! But wasn't syntax highlighting supposed to be turned on by default on enwiki? FaviFake (talk) 11:10, 25 October 2026 (UTC)
The syntax highlighting is off in the mobile source editor. I think that's what FaviFake is referring to. The 2017 wikitext editor is pure Desktop. In solidarity, —Femke (talk) 🐦 19:19, 21 October 2026 (UTC)
I love this idea! FaviFake (talk) 00:29, 21 October 2026 (UTC)
The need for a much better "multi-level" introduction to how to edit or query Wikipedia is more than obvious. The fact that it does not currently exist after decades is an interesting issue with the limitations of crowd sourcing. My suggestion: Let a brave and experienced user with plenty of free time produce one quietly without saying a word. Then announce it after it is 99% complete. Small suggestions will then be incorporated and something will emerge. That has a better chance of success than a decade of debate. Crowd sourcing can be effective, but has limitations. So let us use a crowd of one as a start, then invite comments. At this point we need a Wiki version of a Claude Monet to quietly produce something without suggestions from 12 other artists from the start. He would have never produced anything that way. Let us try that please. Yesterday, all my dreams... (talk) 13:55, 21 October 2026 (UTC)
Users won't enjoy spending their free time on something that might be rejected by a crowd of people who don't like making Wikipedia better for newbies. I know that from experience. FaviFake (talk) 15:58, 21 October 2026 (UTC)
Hence my use of the word brave above. But you could have also said that to Monet. Why spend effort on producing a painting in a controversial new style that might be rejected by the art world. Why not just do the usual? We know the answer. That is how Impressionism came about. He was brave enough to create it. Yesterday, all my dreams... (talk) 16:37, 21 October 2026 (UTC)
I'm optimistic enough to believe the vast majority of Wikipedia editors would be happy with making more accessible introductions, and certainly wouldn't reject it for that reason alone. Yes, some are quite the elitist bunch, but they are certainly not representative of the community as a whole. Chaotic Enby (in solidarity · talk · contribs) 16:45, 21 October 2026 (UTC)
I guess the elitist are by definition a small group, and all they usually get by participating in crowd sourced discussions is frustration. They are Wiki useful in editing complex subjects that the general public would not touch. But the Monet in this case would have to be very middle ground to relate to the new users. Yesterday, all my dreams... (talk) 18:11, 21 October 2026 (UTC)
Hi, I've started sketching out this essay as I see we don't really have any advice pages for ESL/EFL editors, and a large amount of the cases AINB gets are editors using LLMs to compensate for a lack of fluency. Ofc it's a sensitive topic (as any issues to do with competency are), and having something carefully and considerately worded would be so useful. Would be interested in hearing people's thoughts, especially what people have found useful themselves. Thanks Kowal2701 (talk, contribs) 19:33, 23 October 2026 (UTC)
WP:NOLLM already allows for machine assisted translation… although Editors who use such assistance still need to review it to make sure the program is translating accurately. Blueboar (talk) 20:07, 23 October 2026 (UTC)
(WP:LLMT is only for translating from other language Wikipedias, not for translating normal edits) Kowal2701 (talk, contribs) 20:23, 23 October 2026 (UTC)
I was referring to point 1 in WP:NOLLM, which states: “Editors are permitted to use LLMs to suggest corrections to their own writing, and to incorporate them after human review. This is limited to spelling, punctuation, capitalisation, grammar, and other simple mistakes.”Blueboar (talk) 21:34, 23 October 2026 (UTC)
CIR can be a bit scary to mention, but something like "ask more fluent users if you're unsure"? One way or the other, false confidence in one's own competence is a dangerous friend, and I've had more than my fair share of improper Gallicisms when learning English. Chaotic Enby (in solidarity · talk · contribs) 21:06, 23 October 2026 (UTC)
Good idea. I responded at Talk. Mathglot (talk) 21:45, 24 October 2026 (UTC)
I hope my reply isn't so late that nobody will read it. I've seen a few users, after apologising for their English or saying they used AI to fix their grammar, be told that if their English isn't good enough they should try editing their own language's Wikipedia but in all of these cases that I've seen (though I haven't seen that many) their English was perfectly comprehensible. The essay might even be more useful as a reminder to maybe say something like "but your English seems good enough to me" when pointing people to their native Wikipediae.
I don't know what the minimum standard is for English competency is on the 'pedia but I think as long as it's comprehensible native speakers can fix non-native grammar far more quickly than they can plausible, seemingly-sourced hallucinations. As Chaotic Enby said, assessing one's own skill in a language one doesn't speak is unreliable, but I think the essay shouldn't be too discouraging to those who aren't sure if their English is good enough since we could get more constructive editors (and less AI users) and the few who are actually incomprehensible can be easily dealt with. Wicker Mode (talk | contribs) 16:05, 26 October 2026 (UTC)
Totally agree with your first sentence in ¶2. I don't know what the standard is either (and maybe that should be addressed in a guideline) but imho it should be something like, "Any native speaker can understand unambiguously what you meant, so that they can adjust it to a native English standard." A possible problem there, is the number of native English speakers who write ambiguously and might get caught up in the guideline. Otoh, maybe they should be. If worded carefully, a guideline might address English competence while avoiding any mention of native language or second-language speakers, and just apply to everyone equally.
Reminder to self: once the essay is mature, we should consider linking to it from {{Welcome-foreign}}. Mathglot (talk) 17:36, 26 October 2026 (UTC)
Agree with focusing on English competence more, with native/non-native status as a special case. Many non-native English speakers have a native-like fluency in the language, and we wouldn't want to stigmatize them with a blanket assumption that non-native speakers are necessarily less capable. Chaotic Enby (in solidarity · talk · contribs) 18:11, 27 October 2026 (UTC)
Agreed. A fluent English speaker engaging in a topic with unfamiliar jargon could run into the same sorts of LLM-fluency challenges. Not sure how to word that off the topic of my head though. CMD (talk) 22:48, 27 October 2026 (UTC)
The 2017 wikitext editor as default source editor?
When you look at recent changes, about half of newer Desktop editors still use source editor . If you look at a language that has had VE as a default for longer , the percentage is only slightly higher. I don't quite understand why this is (maybe someone in @PPelberg (WMF)'s team can shed light, maybe the tags don't fully capture everything).
One way to make life easier for editors using source editor, is to enable the WP:2017 wikitext editor as the default source editor, which shows the VE toolbar on top of the source editor. The biggest advantage is that adding sources and reusing sources is much much easier. In the 2010 editor, there is a small 'cite button', which requires editors to know to click 'templates' next, and then select the right templates, before being overwhelmed with options. In the VE toolbar, it's often as simple as copying the url in the toolbar. The biggest disadvantage is speed, even though I'm not experiencing any trouble editing big pages with it.
In reviewing G15s, I often come across editors that make a claim they're just using AI for formatting reasons only. Not sure what share of these claims is true. To prevent the need for formatting help, we should make editing easier (the carrot). On the 'stick' side of things, the editing team believes it's possible to implement paste check in the 2017 source editor (see related wish). That likely is only worth their time if we are willing to make the 2017 editor the source default in some way.
I'm considering opening an RfC with four options:
Keep the 2010 wikitext editor (current default)
Make the 2017 wikitext editor the default source editor for non-EC editorseditors who are not extended confirmed at the moment of the switch
Make the 2017 wikitext editor the default for all editors
Make the 2017 wikitext editor the default for non-EC editors conditional on Paste Check being developed.
There's other options, like making it the default only for new editors, but since it's a smaller change in interface and I'd like to capture a bigger group with easier editor, my intuition is to make the RfC a bit bolder. Keen to hear opinions. In solidarity, —Femke (talk) 🐦 08:45, 24 October 2026 (UTC)
Please also provide an option that says: Do nothing, leave things as they are. I would support that. Thanks Yesterday, all my dreams... (talk) 10:48, 24 October 2026 (UTC)
That's option 1:). I've clarified the text. What makes you prefer option 1 even for newer editors? In solidarity, —Femke (talk) 🐦 11:18, 24 October 2026 (UTC)
Femke, first please let me perform a type of Wiki-heresy by asking you what an Rfc may be. It is, of course, a limited form of an Argumentum ad populum. Secondly let me point out that you are not a new user and your guess about what new users might prefer is exactly that: a guess. Most of those participating in the Rfc are also not new users. They will be guessing of course. Rfcs can be very useful in deciding on the reliability of sources or NPOV issues, but not newcomer expectations. When it came to data analysis I used to tell people: ask yourself "what would John Tukey do?" In this case, would he rely on an experiment or not? You know the answer: you need an experiment not guesswork. Please try that first. Thanks. Yesterday, all my dreams... (talk) 18:18, 24 October 2026 (UTC)
I've been asking for communities to get the ability to A/B test abilities ourselves (meta:Community Wishlist/W436), but the current state of affairs is that we cannot, and have to ask the Foundation for each individual test to be run. And with the teams at the Foundation having their own priorities, it is not always possible to get these requests turned into action. So we need to use some commons sense, and collectively think of plausible advantages and disadvantages, and only A/B test where it is unlikely we can make a good guess after discussion.
As an aside, I find your comment rather condescending; please assume people are aware of basic principles of design. In solidarity, —Femke (talk) 🐦 18:49, 24 October 2026 (UTC)
Sorry, but rule number 1 says: make no assumptions. Anyway, I will say no more, so as not to upset you. I have said all I needed to say. Bye bye. Yesterday, all my dreams... (talk) 20:12, 24 October 2026 (UTC)
I would support making the 2017 editor the default for all editors. ThadeusOfNazereth(he/him)Talk to Me! 16:30, 24 October 2026 (UTC)
Support for option 3. EC-editors who don't like the 2017 wikitext editor should be experienced enough to chose their preferred editor themselves, so it is not important which editor is default for them. Lova Falk (talk) 16:43, 24 October 2026 (UTC)
@Lova Falk: this is not the RfC itself, but the discussion about what the RfC should say:). In solidarity, —Femke (talk) 🐦 16:53, 24 October 2026 (UTC)
Ah okay! Lova Falk (talk) 18:29, 24 October 2026 (UTC)
Option 4 is way too conditional. My idea of "option 4" should be this: "Make 2017 wikitext editor the default for logged-out editors".
My idea for Option 5: "Make 2017 wikitext editor the default for non-(auto)confirmed editors" —George Ho (talk) 17:32, 24 October 2026 (UTC)
I don't believe it's likely people would want to split the group of new editors into two (logged-out vs new accounts). That would make updating all our documentation a pain. I can see people wanting a conservative option and only enable it for nonconfirmed editors. In solidarity, —Femke (talk) 🐦 18:53, 24 October 2026 (UTC)
I doubt that trying to split based on extended-confirmed will work out. As soon as someone reaches EC, suddenly their editor changes?Overall, I think you'd have better luck asking for a change that affects TAs and any accounts registered after the change, rather than proposing changing the default for everyone and (if it goes through) having a flood of complaints come in from people who missed the RFC and like their current editor. Anomie⚔ 19:16, 24 October 2026 (UTC)
My idea is to switch it once, for a group that is non-EC at the moment of enabling it, and not to give them the old software once they reach EC. This is a group of editors unlikely to be married to the idea of their editor, and likely to paste AI slop.
I often encounter very experienced editors who are unaware of the 2017 editor and prefer it, but I completely agree with the risk of a flood of complaints. And maybe it would need a temporary 'one-click' button to revert to the old wikitext editor to assuage these concerns. In solidarity, —Femke (talk) 🐦 19:51, 24 October 2026 (UTC)
I agree, the default should not change for anybody who registered before the change. I actually think a more useful change would be to make it as easy to switch between source editors as it is to switch between source and visual editing (and not temporarily either). Personally, I don't have a use for the 2017 editor as it sits in gap between the 2010 editor and visual editor that just doesn't exist for me. Thryduulf (talk) 19:56, 24 October 2026 (UTC)
I'd like to keep the overall options to 4 just to keep it simple, and might switch the 'new editors only' option in instead of the conditional option 4. Would that make sense, or do you believe that there is a group of editors who would mostly want this conditional on paste check being available in the source editor?
My preference is likely for the current option 2, as we desperately need to reduce editor's 'need' for LLMs by making editing easier, and rolling it out to new editors is an incredibly slow process. I'm surprised that we're only hitting 50% of new editors on VE a month(?) after enabling it. In solidarity, —Femke (talk) 🐦 20:05, 24 October 2026 (UTC)
The way to make editing easier for new editors is to present them with the visual editor first. I'm not convinced the halfway house of the 2017 editors has any value over that. Thryduulf (talk) 21:09, 24 October 2026 (UTC)
The problem is that a lot of new editors don't use VE, or are asked by LLMs to switch to the source editor. User:Toadspike and me flagged a couple of odd behaviours today to WMF that can lead to people being forced into source without their intent: e.g. if their first action onwiki is to 'Edit' on a talk page, it will remember their editor, and use source editor going forward. The VE-like 'Add topic' is not super prominent compared to 'Edit'. Even if they start off with VE, they will still encounter source editor in many places, as VE is not fully supported. Having the 2017 editor makes this a more smooth experience. You cannot edit completely without source, so to me, there is a value in choosing a modern source editor that feels intuitive. The default editor should stay VE of course. In solidarity, —Femke (talk) 🐦 21:48, 24 October 2026 (UTC)
are asked by LLMs to switch to the source editor There's little we can do about that, and VE will drop a user into whichever source editor is provided, so this is not a point in favor of using specifically the 2017 editor.
As recently as a few months ago, there wasn't even a way to add <nowiki> in 2017 WTE unless you already knew it existed. Izno (talk) 02:59, 25 October 2026 (UTC)
To me it's a small point in favour without paste check: llms dropping the user into an editor where they're not completely lost will make it more likely they'll try to edit themselves. The biggest difference would be if paste check were to be developed, so that we have that solution to AI slop in source too. In solidarity, —Femke (talk) 🐦 03:22, 25 October 2026 (UTC)
Thanks for the ping. A longer version: Clicking "view source" on any protected page, including the main page, most high-profile pop-culture topics, most templates or even Draft:Example, switches the user's default editor to source. Weirdly, though, this doesn't seem to happen with noticeboards, like AIV or ANI, or user talk pages, which also default to source editor. Seems to specifically be the "view source" button. Toadspike[Talk] 11:45, 25 October 2026 (UTC)
Not sure what I did wrong yesterday with testing, but you're right that it's only the 'view source' that produces this. In solidarity, —Femke (talk) 🐦 12:06, 25 October 2026 (UTC)
I cannot replicate in template space. To me, it looks like it mostly happens for the three namespaces where VE is enabled (user, draft, mainspace, but also the mainpage). I've opened phab:T442310. In solidarity, —Femke (talk) 🐦 12:28, 25 October 2026 (UTC)
I used to use the Wikitext 2017 editor but I found it made it impossible to edit on any mobile device on the desktop view. It would do this weird thing where it would offset all text selection like 4 paragraphs after where the text actually was. PARAKANYAA (talk) 19:57, 24 October 2026 (UTC)
That is really annoying. Did you open a bug report on phab? Do you know if that bug is still there? In solidarity, —Femke (talk) 🐦 20:06, 24 October 2026 (UTC)
No, though maybe I should have. I think it was probably a byproduct of how slow it was overall. PARAKANYAA (talk) 15:46, 25 October 2026 (UTC)
As someone who's used the 2017 wte, it is not ready to be the default source editor and may never be. It's always been slow, and it's not particularly friendly for mobile browsers on any given day. And basically, it hasn't been worked on since it rolled out to our general surprise in 2017. Izno (talk) 02:56, 25 October 2026 (UTC)
In terms of mobile: I was under the impression it was a desktop only editor? I don't see any toolbar when I'm editing mobile.. In solidarity, —Femke (talk) 🐦 03:03, 25 October 2026 (UTC)
@Femke You can go into the desktop view on mobile. I've done a decent bit of editing while out of the house this way. Normal source editing works totally fine, but 2017 lags to hell and back and has that weird error I mentioned above. PARAKANYAA (talk) 15:45, 25 October 2026 (UTC)
Yes, for a significant time I used Timeless while using mobile (Firefox browser on Android). It was routinely buggy at the time.
And remember, as always, that not everyone has got networks with our speeds or phones with our speeds. There needs to be a trivially accessed alternative for the masses that is actually faster than VE or 2017. Izno (talk) 06:35, 25 October 2026 (UTC)
I did a reasonable amount of outside-work-hours work on it over the last few months for the codemirror improvements (thus it having autocomplete built in for T432400 now), alongside which there've been a bunch of general VisualEditor performance improvements, so if you've not tried it in the last six months you might want to look again. DLynch (WMF) (talk) 20:32, 26 October 2026 (UTC)
@DLynch (WMF) I've noticed 2017 wikitext being considerably faster recently, thanks for your work! However when using Safari on long pages and with syntax highlighting enabled both 2017 wte and the reply tool still struggle a bit... Johannnes89 (talk) 09:46, 29 October 2026 (UTC)
On the question of stats:
If you use the Undo button on desktop, you use the 2010WTE no matter what your settings are (2003 if you have Javascript turned off).
I wasn't sure whether I was using the 2017 editor already and had to review my preferences to figure it out (I wasn't). I've turned it on now and will see how it goes for a bit.
What I recommend is that the text editors identify themselves when you're using them so that users can understand the alternatives better. Currently, I'm aware of at least four different editors now.
1. The current default text editor which seems to be a 2010 version
2. The 2017 text editor, as proposed, which has some relation to the Visual Editor
3. The Visual Editor proper
4. The editor which is invoked when you use the reply function (which is what I'm currently using).
I wouldn't be surprised if there are other editors out there too. Ideally these alternatives should be rationalised and simplified but, in the meantime, we need help in understanding which one(s) we're using.
All the editors are listed with a brief description at mw:Editor, there are currently 16 current editors although some are very specialised (e.g ContentTranslatoin), some are mobile only (e.g. iOS app), and not all are available at en.wp (e.g. Wikivoyage Listing Editor). Thryduulf (talk) 19:03, 25 October 2026 (UTC)
Thanks. My count of that table is 17 plus 2 deprecated editors. See feature creep and the KISS principle... Andrew🐉(talk) 19:34, 25 October 2026 (UTC)
The basic distinction is that the 2017 editor is editing wikitext but using the VE toolbar. Sdkbtalk 21:06, 26 October 2026 (UTC)
One problem with the 2017 editor is that it breaks with any edit window that prefills something. For some of those, such as requesting at WP:PERM, it only makes it impossible to add an edit summary, while in other places, such at at WP:AINB, it is not really possible to file a report. 1brianm7 (talk) 19:06, 26 October 2026 (UTC)
I don't love the 2017 editor. I think the current one works just fine. Axolitl(talk|contribs) 05:11, 29 October 2026 (UTC)
What would you like to see improved in the 2017 editor, @Axolitl? In solidarity, —Femke (talk) 🐦 07:47, 29 October 2026 (UTC)
I like the proposal. It might nudge the WMF to make further improvements to 2017 wte:) --Johannnes89 (talk) 10:09, 29 October 2026 (UTC)
Uk politics as CTOP?
Iirc there is a community procedure to declare certain topic areas as CTOPs. In many cases, having a topic as CTOP can help with filing AE reports, and reminding folks to be wxtra careful, even without additional remedies applied to the topic area. Unfortunately, i feel its time to designate contemporary UK politics as CTOP; its not adequately covered by current restrictions, and is so contentious in many articles as to confuse many editors that it isnt already a CTOP.
Wrt this, i want to gauge community interest in pursuing this and how to specify contemporary Uk politics? User:Bluethricecreamman(Talk·Contribs) 03:22, 25 October 2026 (UTC)
Can you name several problematic articles that aren't already covered by existing CTOPs? WhatamIdoing (talk) 06:58, 25 October 2026 (UTC)
I'd argue that the issue is less "British politics broadly construed" and more "far-right politics broadly construed" since that's also been a noticeable issue in the AP topic area since forever. —Jéské Courianov^_^vThrillerNight! 16:17, 25 October 2026 (UTC)
Far-right is a nebulous definition enough that its the exact subject of these debates. Actually, more broadly, there are constant arguments about what is far-right, far-left, and if wikipedia can use such labels anyways.User:Bluethricecreamman(Talk·Contribs) 16:25, 25 October 2026 (UTC)
Obviously more precise wording would be required if far right politics were to be designated a contentious topic, one possibility would be "people, organisations (including political parties and campaign groups) and policies who/that have been described as "far right" in at least one reliable source, broadly interpreted" (although that could likely be improved). This would include people/organisations where consensus is that we should not describe them as "far right" in the article, but that is intentional so as to cover debates about whether they are or are not far right.
Note that I'm explicitly not supporting (or opposing) a CTOP with this comment, just pointing out that one would be possible. Thryduulf (talk) 17:05, 25 October 2026 (UTC)
@Bluethricecreamman can you provide some examples of articles that are contentious, are being disrupted and where the available processes are not stemming that disruption? Thryduulf (talk) 11:02, 25 October 2026 (UTC)
My original impetus for this, I filed an AE report covered by R/I, but thought the pattern of behavior could reflect more broadly UK politics. one admin suggests that if behavior doesn't stop there may be need for a hand crafted solution. Another here [2] points out that an originally proposed eventual restriction around AP2 probably is incorrect.I think many of the articles i placed above Wikipedia:Village pump (idea lab)#c-Bluethricecreamman-20261025154300-WhatamIdoing-20261025065800 in this reply to WAID have a controversial article talk page banner but aren't necessarily linked any other way.My understanding for the designation of a ctop is not necessarily that there needs to be additional remedies, only that being able to group this together makes it easier to file AE reports, or to direct users to be additionally careful in the topic area. User:Bluethricecreamman(Talk·Contribs) 15:53, 25 October 2026 (UTC)
Designating a topic as falling within the contentious topic framework allows admins to enact more types of restrictions on their own initiative, without requiring community consensus. These restrictions cannot be reversed by another individual admin for the first year. This slows down quick enact restriction/remove restriction cycles, since a consensus of admins or the community will have to be established to change the restriction. The use of the arbitration enforcement noticeboard to discuss these restrictions or request that a restriction be enacted is just a consequence of this. As for asking users to be careful, anyone can do that with any topic. Editors should be following the same community norms with any page; there's just a risk with contentious topics that an individual admin/consensus of admins may enact a restriction that would ordinarily take a community discussion to be enacted. isaacl (talk) 17:19, 25 October 2026 (UTC)
Its not immediately clear to me that quick enact/remove restrictions occur in this area anyways? And in many cases, posting on AN/I becomes a pile-on of various actors, compared to the well-structured aspect of AE. Agree there is that risk ofc of bureaucracy blocking admin actions. User:Bluethricecreamman(Talk·Contribs) 17:33, 25 October 2026 (UTC)
If restrictions are getting enacted without being reversed, then that is a factor against designating the topic as a contentious topic, since restrictions are holding. If the community is unable to agree upon enacting restrictions, then yes, it could delegate some responsibility to admins through a contentious topic designation. Just noting within the current framework, using the arbitration enforcement noticeboard isn't something that happens on its own; it's a direct consequence of delegating responsibility. isaacl (talk) 17:59, 25 October 2026 (UTC)
So I want to concur in part and disagree in part with what @Jéské Couriano said about how the issue is the far right topic in general.
I agree that is a more correct aproach as it captures a general core issue, but I would go further. While far right is contentious, so are political position questions in general. I don't think it will serve the interests of Wikipedia that political classification discussions towards one direction are allowed to have a lower participation treshold than the other. I think that risks cementing existing bias among editors by favouring experienced editors in politics topics in an uneven manner. So in what I disagree is leaving it just at far right. I don't think I would support doing just that. Finfixer (talk) 17:11, 25 October 2026 (UTC)
I don't usually create templates, so I'm not sure if this is a good place to have this discussion, but I've been considering creating a caution template to use on the talk pages of users who appear to have introduced content to articles that may violate WP:BLPCRIME, ie. the full names names of low-profile living individuals suspected or accused of committing a crime but who have not been convicted. Articles covering recent events are frequently inundated by the addition of information provided in preliminary reports on crime suspects, but there is no warning template for use in this situation, and I think there ought to be. Based on Template:Uw-biog-not (which serves a similar but less specific purpose), I've come up with the following text:
I have reverted your edit at [article] as it appears to include material which suggests a living person has committed a crime, in violation of Wikipedia's policy on living persons. Caution must be exercised when considering the publication of the names of low profile individuals accused or suspected of crimes. Living persons accused of crimes are presumed innocent until convicted by a court of law, and the names of individuals identified as persons of interest in a crime should not be included in articles. Please note that accusations, investigations, arrests and charges do not amount to a conviction and care should be taken to avoid the publication of potentially libelous material.
Criminal allegations and the names of suspects, even if referenced, should be added only if noteworthy, relevant, and documented in multiple high quality reliable independent sources. Wikipedia is not a newspaper and material should not be added if it is only gossip, or if the only sourcing is tabloid journalism.
If challenged, the onus is on the editor who adds the content to justify its retention. Thank you.
I would appreciate honest feedback on both the wording and the idea of the template itself as this is not my usual area at all. Cheers, Ethmostigmus 🌿 (talk|contribs) 08:42, 25 October 2026 (UTC)
I like this idea. I would suggest making the explanation much simpler, because people will gloss over anything that's more than a few sentences. Thebiguglyalien (talk) 02:16, 26 October 2026 (UTC)
I like this idea too. I agree with User:Thebiguglyalien above, the explanation should be concise. I had a go making it slightly less wordy:
I have reverted your edit at [article] as it appears to violate Wikipedia's policy on living persons accused of crimes. People are presumed innocent until convicted by a court of law, and the names of low profile individuals identified as persons of interest in crimes should not be published. Accusations, investigations, arrests and charges do not amount to conviction. Criminal allegations (even if referenced) should only be added if they are noteworthy, relevant and documented in multiple reliable independent sources. Wikipedia is not a newspaper and care should be taken to avoid libel. If you disagree, the onus is on you to justify retaining this content. Thank you.
Could probably be simplified further, but let me know what you think. 𝕬𝖎𝖉𝖔𝖜𝖑(hoot!) 03:20, 26 October 2026 (UTC)
Ha, yes, being overly wordy is a personal fault that I am well aware of - I think this shorter version looks great! Ethmostigmus 🌿 (talk|contribs) 06:48, 26 October 2026 (UTC)
I'd personally axe mentions of 'libel' for being more confusing than clarifying; the definition of libel or defamation has a real world meaning, but our Wiki-dialect's definition doesn't map neatly onto the real-world USA definition of libel. We welcome facts which would be considered libel in some countries and, conversely, I've seen us revdel comments under the BLP policy which would not be considered defamatory under US law. GreenLipstickLesbian💌🧸 08:15, 26 October 2026 (UTC)
This is better. I'd remove Wikipedia is not a newspaper and care should be taken to avoid libel. If you disagree, the onus is on you to justify retaining this content. and (even if referenced), the latter is redundant and reads awkwardly. Per GLL and because the last line is inviting a discussion in the wrong place. A discussion to include contested BLP content needs to occur on the relevant talk page, not a usertalk page. Or otherwise better worded as such. Also would be worth revisiting the wording of Template:BLPCRIME editnotice and Template:BLPCRIME talk notice while we're here, the focus appears a bit outdated. CNCin solidarity (talk) 08:53, 26 October 2026 (UTC)
Thanks all, these are all good points. What do we think of:
I have reverted your edit at [article] as it appears to violate Wikipedia's policy on living persons accused of crimes. People are presumed innocent until convicted by a court of law, and the names of low profile individuals identified as persons of interest in crimes should not be published. Accusations, investigations, arrests and charges do not amount to conviction. Criminal allegations should only be added if they are noteworthy, relevant and documented in multiple reliable independent sources. If you would like to discuss this matter further, you may open a discussion at the relevant article talk page. Thank you.
A “where am I?” map for readers: showing how an article fits into its subject
Notice: This proposal is believed to have been generated with the use/assistance of an LLM. The author is encouraged to rephrase it in their own words (after which point this notice can be removed), but it has been uncollapsed to allow discussion to continue unhindered. CSGinger14 (talk) 22:14, 26 October 2026 (UTC)
Hi all, I’m a long-time reader and new to posting, so apologies if this has been discussed before. Links to past discussions would be very welcome.
The problem. Most readers arrive at an article from a search engine, in the middle of a subject. The article is usually excellent, but nothing on the page tells them:
where this topic sits in the wider subject (is it foundational or a niche detail?)
what they’d need to understand first for it to make sense
where to go next if they want more depth
Wikipedia already holds most of the information needed to answer those questions. It just isn’t visible at the point of reading.
What already exists. I’m aware of several pieces that point this way:
Vital Articles, with its levels of 10, 100, 1,000, 10,000 and 50,000 articles, which is in effect a ranking from core to detail
“Outline of …” pages, which are branching trees of a field
Portals, Simple English Wikipedia, Wikiversity and Wikibooks
As far as I can tell, none of these is connected to the article a reader is actually looking at.
The idea. An optional, collapsible panel on each article, showing:
Broader: the parent topics, taken from the Outline pages and Vital Articles level
Foundations: a few “read this first” articles
Deeper: narrower or more specialised articles
Items 1 and 3 could mostly be generated from existing structure. Item 2 is the new part. It would need some kind of lightweight “prerequisite” link that editors can add, possibly stored in Wikidata.
Why it matters. It would turn Wikipedia from something you look things up in into something you can also learn a subject through, from the ground up, without changing a word of any article.
Questions for the community:
Has something like this been proposed or tried before, and what happened to it?
Would a prerequisite relationship be workable, or too contested to maintain?
Is this better as a gadget or user script first, as a proof of concept?
Thanks for reading. I’m happy to help build a prototype if there’s interest.
Grant from RepHleX
PS Primary affected users:
Readers, especially students and self-learners who arrive on an article from a search engine in the middle of a subject. Nothing on the page tells them how central the topic is, what they need to understand first, or where to go next for more depth, so many either bounce off articles that assume background knowledge or never find the foundational ones. Secondary: editors in WikiProjects, who would add and maintain the “read this first” links for their subject area, building on the Vital Articles levels and Outline pages they already curate.
Whether or not the idea was written with the assistance of a large language model (it doesn't come across that way to me, but I could be wrong), it seems reasonably concise, states a clear problem and proposal for addressing it, and to me feels like some consideration has gone into the words, in contrast to the vapidness that some generated text has. Thus I don't agree with collapsing the text (and, as at the moment it's just an idea raised for discussion, building consensus is not yet a consideration). isaacl (talk) 21:58, 26 October 2026 (UTC)
I agree. There are far worse things that LLMs are used for here, and I frankly think that, more than anything else, this just builds resentment among newbies who were otherwise making a good faith effort to communicate something that they may not have been able to easily put into words. If they can, I might encourage the original author to rephrase their original proposal, but I think that if the intention is to ultimately make a useful proposition to the community (that isn't immediately veiled in controversy) then there's little conceivable harm. Just don't use it for your next response.
No one cares about how eloquent you sound. Frankly my experience is that being overly articulate over the course of a long discussion can tire some community members out. I promise we're not grossly judgmental, and those that are usually aren't all that articulate anyway, so they've got little room to talk.
To me, it doesn't sound overly eloquent. And I don't think we should set expectations that we prefer to engage with editors that are less articulate. isaacl (talk) 22:28, 26 October 2026 (UTC)
That's exactly my point, but from what I can tell a lot of the time people use AI as a substitute or complement to their own personal prose because they lack confidence in their writing abilities, and fear the consequence for their ultimate goals. Eloquence is extremely subjective, and oftentimes what you consider to be a standard composition is high-flung and nigh unintelligible to someone else, particularly if they're coming in as a non-native speaker of the language of reference.
My point is that personally I don't feel that the initial post reaches a level of eloquence on any reasonable scale such that someone should use it as a reason to ask the original poster not to use an LLM "for your next response". isaacl (talk) 01:50, 28 October 2026 (UTC)
@Isaacl That response had much less to do with any personal problem I had with the quality of their writing than the fact our site doesn't allow for the use of AI to generate text.
I think it would be interesting to see a proof-of-concept/mock-up for an article (or small set of related articles). Schazjmd(talk) 22:30, 26 October 2026 (UTC)
I second this. This is actually something I've thought would be useful for a long time, glad that someone finally put forth the effort to flesh out a proposal.
Parent and child topics are usually shown as wikilinks within an article. These may be structured in templated panels such as infoboxes and navigation templates. See 2026 Iran War, for example, which has numerous links to related topics.
There are also categories which have a tree structure but they are buried at the bottom of an article page and not so easy to navigate.
@~2026-57277-75, Wikipedia has struggled with this for a long time. In the technical area we have Wikipedia:Make technical articles understandable which is quite similar to what you are saying. In its section on writing the article lead it says, among other things, the lead of the article should tell a general reader the field of study of the topic, the place the topic holds in its field of study, what (if anything) the topic is good for, and what needs to be learned first in order to understand the article.
However articles are written by volunteers, and implementing this has always been an issue. I think an approach such as you suggest might be helpful. However, while we have articles that might be considered "Foundations" we have few editors capable of writing ones which are really introductory, and the ones that exist often get don't remain that way as other things get added. Referring a reader of a hard to understand article to parent or foundation articles that are equally difficult may not help. StarryGrandma (talk) 22:41, 26 October 2026 (UTC)
Regardless of the question of LLM use to compose this post, this does sound like an interesting idea to explore. One reason why, at the beginning of Wikipedia, subpages weren't enabled in articles was specifically that one article can have several parents (for example, History of France could be a child topic of both History of Europe and France). Having a way to show all of them prominently for navigation could be helpful, especially if it can be managed without having to overload the top hatnotes. My only worry is for articles with many, many child topics – e.g. Donald Trump or Aedes (with nearly a thousand species!) – in these case, showing all child topics would be quite unwieldy for the average reader, and the current approach with wikilinks and navboxes would be preferable.
I'm less convinced about the "Vital Articles" level as a helpful tool for the average reader. This system has already been criticized as pretty arbitrary by the community, especially at levels 4 and 5. A "read this first" panel could be more helpful, and build upon the aforementioned technical article lead guideline in a more structured way. Chaotic Enby (in solidarity · talk · contribs) 04:21, 28 October 2026 (UTC)
@Chaotic Enby I think reasonably speaking this is the sort of thing we start out small with. Experimental and then expand as the community is able. Like I can imagine this would do wonders for the communicability of math and foundational science topics on here. Next could come things like trades, humanities, history, and the social sciences, then we can get to things like politics, philosophy, literary movements, (etc.). Frankly the blue links tend to be pretty clear on those last ones anyway, and you’d figure a fair proportion of the people checking those out have the most surface level background on them to start with anyway.
I feel like it would be cool to add a today's unusual article to the main page. Timmy8426 (talk) 23:59, 27 October 2026 (UTC)
WP:DYK is supposed to be for interesting new content. Perhaps most are not unusual or interesting though! On April Fools Day you can expect unusual DYK content on the main page. Graeme Bartlett (talk) 00:22, 28 October 2026 (UTC)
Fair point, but it could still be a decent idea. Timmy8426 (talk) 00:39, 28 October 2026 (UTC)
Do you mean something like Depths of Wikipedia? I follow it on Bluesky, but I'm not so sure it should be on the main page. Donald Albury 15:28, 28 October 2026 (UTC)
Never heard of it. Timmy8426 (talk) 21:12, 28 October 2026 (UTC)
Hey, I’m trying to develop an infobox and I would like some feedback.
So, I’ve noticed that Wikipedia has a lack of Infoboxes for internet content. Most articles about internet videos either use the film infobox or one of the television infoboxes. Below, I have an outline for an internet video infobox. I even have a link so you can preview it in your sandbox and try it yourself.
image= Pretty obvious, works the same as every other infobox.
caption= Also self-explanatory, caption for the image.
alt-title= If the video goes by another name.
platform(1-3)= The site that the video was originally uploaded on. Multiplied in case the original uploader put it on other sites.
upload_date(1-3)= The date the video was uploaded. Multiplied alongside the platform. If it’s a live stream use stream_date= instead.
stream_date= The date the video was livestreamed. If it isn’t a live stream, use upload_date= instead.
time= The amount of time the video runs for.
chan= The name of the channel the video was uploaded to.
url= The URL to the video.
quality= The quality of the video (measured by p)
feat= People in the video.
place= The location the video was filmed at.
camman= The person recording the video.
Thanks for your time. If this infobox goes over well, I’d also like to make some for webseries and webseries episodes. Iconoclasty (talk) 02:00, 28 October 2026 (UTC)
Looks great! Not sure if it's necessary to show the full URL by default. URLs can get very long. Nitpicks about parameter names: time= should be duration=. chan= is overvaluing concision, just use channel=. camman= is sexist, use cam_operator= or videographer= something else if you have a better idea. Joe vom Titan (talk) 01:06, 29 October 2026 (UTC)
updated
chan > channel
time > duration
camman > camera_op Iconoclasty (talk) 01:14, 29 October 2026 (UTC)
Actually, it would be even better to use the same parameter names as in the film infobox where that makes sense. Joe vom Titan (talk) 01:15, 29 October 2026 (UTC)
Can you give an example of an article this could be used on, please? Halbared (talk) 09:05, 29 October 2026 (UTC)
Small list I made. Iconoclasty (talk) 13:32, 29 October 2026 (UTC)
I have an idea. When reading an article about a piece of media that contains spoilers it blurs it, you then click on show spoiler. This might be nice as an optional feature that’s off by default Kerman64 (talk) 05:40, 28 October 2026 (UTC)
Since a WP-article about a piece of fiction is supposed to contain something about the plot, that would be pretty much all articles about works of fiction, fictional characters etc. WP:SPOILER may be of interest. Gråbergs Gråa Sång (talk) 08:57, 28 October 2026 (UTC)
Related: (that last one makes some interesting claims about Wikipedia)
Was this $42K well spent? Who benefited? What was accomplished?
Was this the sort of thing that the donation banners describe your contributions as funding?
Why are some of the links at dead or useless? Are we not capable of posting these publications on WMF servers? --Guy Macon (talk) 18:38, 28 September 2026 (UTC)
Takeaways from the linked paper at [14]:
Theory Section
- The power to shape consensus on Wikipedia is not evenly distributed. Even aside from groups like ArbCom, things like technical knowledge, access to bots, and understanding of the site's jargon gives the small slice of the community with mastery over them ("experienced users") an overwhelming presence in policy discussions.
- The rules pages act as entrenched technical authority that can be used by experienced users against outsiders, not merely as consensus records.
- As proof of the above, most policy pages are very old. If a page survives its first year of official status, it gains enough momentum to be effectively permanent. 11 of the 15 sampled policy pages were fully stabilized by 2011.
- The rules pages are very stable, and that's good. However, they are resistant to change in a way that discourages any new user that isn't already aligned with Wikipedia's way of thinking. Such users don't become experienced users with the ability to shape discussion, and so can't reform the very rules preventing their participation. This is a barrier to gaining new editors from outside the spheres Wikipedia originated in (American male tech nerds).
- Wikipedia's policies, both content and social, can be used as a cudgel against users who threaten local consensus and/or individual editors' worldviews. Examples cited.
- All of the above to say, Wikipedia's current policies fail to reflect actual community consensus due to how they empower users who already agree with them.
There's more stuff about the actual form said empowerment takes, lot of sociology jargon and such. It records the various levels of authority a rules page can have, including unofficial levels like "essay endorsed by popular community members."
Data Section
- The number of individual users involved in creating each policy is very low. It's mostly the same handful of people talking to each other. There were more "critical discursive moments" identified in the sample than unique editors.
- enwiki prefers discussion among a few people with strong opinons and arguments over the flatter voting system of eswiki. The other three languages didn't have much of either, and just kind of trusted whoever was writing the rules.
- Recommendation made that the processes used to define and change policy be adjusted to better reflect actual editor consensus rather than consensus among the technocratically empowered few. No hard suggestion included.
Overall I think it's a useful study, if not for Wikipedia itself then certainly for the history and sociology of internet communities. I'm not mad about it having been funded. ~2026-52337-89 (talk) 23:56, 28 September 2026 (UTC)
The promise (when they were asking for $42K) was "identifying gaps in policy that are necessary for the needs of all English Wikipedians." Please name a gap in policy that was identified, and how we can fix that gap.
Thinking on how to resolve this, perhaps that's the solution - we establish a consensus that donations banners run on enwiki must accurately detail where the money is going. If something is beyond the scope of what donation banners said the WMF is spending money on, then either the WMF needs to cut the program, or not run banners on enwiki. BilledMammal (talk) 02:19, 29 September 2026 (UTC)
@Guy Macon, I don't think expecting research to "succeed" in doing something 100% of the time is a reasonable expectation to have. Research can and does "fail" even with the best effort. Doing research on policies on Wikipedia is within Wikimedia Foundation's overarching programmatic goals to better the community to which donators donate to. There was a certain amount of funding allocated to the researchers, they tried to gain some useful information, they failed in the overall goal but found some interesting findings about internet communities which got published in a (what I assume) is a well respected journal. Sohom (talk) 02:55, 29 September 2026 (UTC)
No need to ping me. I have a watchlist and know how to use it.
Useful? Sure. $42,356 USD of the donor's contributions useful? Not so much. A lot of those donors are living in poverty and sacrifice to give because they were told that this was needed to keep Wikipedia free.
There are many, many researchers who have published papers on Wikipedia in well respected journals. I question why only a handful of insiders get funding for doing that from the WMF. --Guy Macon (talk) 03:06, 29 September 2026 (UTC)
seful? Sure. $42,356 USD of the donor's contributions useful?, that's how research works??? You provide a chunk of funding so that a group of researchers can try different methodologies and techniques and build prototypes to see if any work. If anything, 42K is fairly cheap in the research world for the length of time the project took (2022-2025) actually since if you think about it, a single grad student's yearly tuition and stipend in CS (being paid barely enough to sustain themselves, while also being one of the most funding rich areas) amounts to roughly that number.
I question why only a handful of insiders get funding for doing that from the WMF.. Guy Macon, I would suggest looking at the page for the dissemination of research funds which provides full transparency into who is allowed to put in proposals, how much money WMF is willing to give for research projects, the proposals submitted and rejected, the folks who decide who to fund (who are well respected researchers within the Wikimedia Research community). I don't think characterizing this as "insiders get funding" is a correct characterization. Sohom (talk) 03:22, 29 September 2026 (UTC)
As I have said many times, I think that everyone at the WMF -- from engineers to the people who decide who and what to to fund, are doing a great job at what they are trying to do. I have zero doubt that you are really looking hard at who you decide to pay to do research, and by "insiders" I don't mean "your buddies" or anything implying corruption or malfeasance. I believe you are like the fine people back in the 1960s who were managing the war in Vietnam. They did seriously great work deciding whether to fund more jeeps or more tanks, whether the jungle boots could be made better, etc. Thousands of good decisions were being made by dedicated individuals doing a great job, but never once considering or even being allowed to consider whether we should be fighting a war in Vietnam at all.
Now consider the entire world population of people who have published research on Wikipedia. All of them. They all get paid by someone, usually their university. What percentage get WMF grants? Do an honest estimate. One in a thousand? What differentiates the two groups? One group knows how to craft a proposal that will get them funding in the usual ways academics get funding. The other has learned how to work the system to get WMF funding. How many of each group get free travel and lodging to go to Paris and spend time with Wikimedia staff and Wikipedia editors? How many in each group know the names of multiple WMF employees? How can you call the tiny minority that get grants anything other than insiders? --Guy Macon (talk) 06:47, 29 September 2026 (UTC)
And again I ask, was this the sort of thing that the donation banners describe your contributions as funding? --Guy Macon (talk) 06:47, 29 September 2026 (UTC)
There's lots of things the WMF is doing badly, but I don't think this particular funding decision is one of them. The article seems to be of good quality to me, and seems in line with the research questions in the application. TietoTeekkari (talk) 07:56, 29 September 2026 (UTC)
And I fully agree, just as I agree that the military made some great decisions about funding jungle boots during the Vietnam war. They were great boots. I still have a pair and they look like new. And, just as I think that same military made those great boot decisions without even considering whether we should be there we should be fighting a war is Vietnam, I think the WMF did a fine job of picking which researcher to fund while never even considering whether we should be funding academic papers at all. And again I ask, was this the sort of thing that the donation banners describe your contributions as funding? Is there some special feature in Wikipedia's software that makes the preceding words invisible when I write them? --Guy Macon (talk) 13:50, 29 September 2026 (UTC)
Not Tieto, but the last time I donated to Wikipedia I recall the banner saying something about "supporting and defending open knowledge projects." I'm probably not getting the phrasing exactly right. This research seems very relevant to Wikipedia and how our internal community and governance systems operate, along with how community-based open knowledge projects operate more broadly. ThadeusOfNazereth(he/him)Talk to Me! 19:17, 29 September 2026 (UTC)
You mean this banner? The actual promise was "Please join the 2% of readers who give what they can to to help keep this valuable resource ad-free, up-to-date, and available for all". Nothing about supporting and defending open knowledge projects. The banner also talks about what you are doing when you visit Wikipedia, which I thought was a nice addition. Please note that something can be "very relevant to Wikipedia" without being what the donors were told their donations were funding.
You can see a bunch of fundraising banners here. I couldn't find any documentation as to which were shown when and to who. Perhaps someone else can find that information. --Guy Macon (talk) 23:45, 29 September 2026 (UTC)
Guy, it sounds to me that you want the WMF to support Wikimedia and open knowledge projects but to do no research into how to support those projects, no research into how effective support for those projects is, whether support would be better directed towards maintaining existing (governance) structures or implementing different (governance) structures? If so, why do you think that? If not, please try explaining what I'm getting wrong. Thryduulf (talk) 19:47, 29 September 2026 (UTC)
Not at all. The choice is not between "funding no research" and believing without evidence that this particular research actually ended up "maintaining/implementing governance structures". Can you name a single governance structure that was maintained or implemented by this research? Look at the results of this research again: The first two results are trivial and the third is just plain wrong.
In the banner at the donors -- many of whom live in poverty -- were not told that they were funding research, just as they were never told that they were funding trips to talk about Wikipedia in exotic vacation destinations. They were told that they were keeping Wikipedia ad-free, up-to-date, and available for all. I am fine with donors funding any research that has a reasonable chance of advancing those goals, but they should be told that some of their donations will be given to other individuals and organizations. --Guy Macon (talk) 23:45, 29 September 2026 (UTC)
Research does not have to be successful to have been valuable, and if you only fund research that produces the results that you want it to then that's not research. Please explain how funding people and projects that write and maintain the projects, write and maintain the sources we use, research how the project can be improved, research how best to support the projects, etc. are not "keeping Wikipedia ad-free, up-to-date and available for all" either directly or indirectly? Thryduulf (talk) 00:04, 30 September 2026 (UTC)
By those criteria I can't think of a single thing that the WMF spends money on that doesn't keep Wikipedia ad-free, up-to-date and available for all either directly or indirectly. I can't see any plausible way that not funding this sort of thing could possibly result in Wikipedia being ad supported, stop the volunteers from updating it, or make it unavailable, but you clearly do so I won't waste your time with further disagreement. --Guy Macon (talk) 00:18, 30 September 2026 (UTC)
Can you name a single governance structure that was maintained or implemented by this research? To this among other research appears to be part of a body of research into policies that eventually led to the establishment of the NPOV Working Group and the subsequent implementation of the global baseline NPOV policy. Sohom (talk) 00:27, 30 September 2026 (UTC)
Just to be clear: I think that Wikiresearch is in general a good thing, and funding some of this by WMF seems reasonable. The specifics of funding, methods, and transparency and ethics of the coordination of the research should, of course, be subject to transparent debate (apart from privacy issues). I'm not judging the validity of funding for this particular project. Boud (talk) 11:39, 30 September 2026 (UTC)
I found meta:Baseline NPOV policy (a baseline NPOV policy for the Wikipedias which do not yet have an NPOV policy) to be a fine document. The question is whether it is worth the $42,356.25 USD ($88.43 per word) it cost the donors.
I would be interested in how many Wikipedias did not yet have an NPOV policy when it was created and how many have adopted it. If the donor is paying for "governance structures implemented by this research" it would seem reasonable to ask how many actual governance structures were implemented, not just a web page that seems like it would be useful to someone doing that.
I also noticed that it is only in English and French. One would think that some of that $42,356.25 USD would have been spent on translating it to the languages of the Wikipedias which do not yet have an NPOV policy. I'm just saying. --Guy Macon (talk) 16:14, 30 September 2026 (UTC)
Couldn't small wikis just copy the NPOV policy from English, French or any other well-scrutinised Wikipedia, gratis, and alter any bits they deem inappropriate for their project? Certes (talk) 16:23, 30 September 2026 (UTC)
@Certes, I would suggest looking at Serbian, Bosnian Wikipedia situations where despite copying the policy text over over they've had multiple significant issues surrounding the enforcement of said policies. Similar issues exists to smaller extent on other projects as well. Even on the rather bare-bones baseline policy, smaller communities have pushed back on the baseline policy due to concerns over the fact that it often constrains smaller language wikis in multiple ways in terms of prioritizing spoken history vs colonial written sources or preferring accounts in local language sources over the broader international consensus on a topic. Sohom (talk) 16:38, 30 September 2026 (UTC)
Certes, the real problem in searching for worldwide solutions is that in my experience different language Wikis are effectively different planets with totally different climates. I sometimes look at the Italian, French, German and Spanish wikis, and their culture and customs are strikingly different, and range from those with a highly controlled system (eg German) to others with freewheeling on non-crucial topics. Their wiki cultures adre as different as the foods they eat. You can not give them a universal cookbook. Yesterday, all my dreams... (talk) 18:02, 30 September 2026 (UTC)
@Guy Macon The policy hasn't yet gone into effect. It is still in proposal phase. Also re cost, 42K (and more actually) spent on building policy to avoiding incidents where Wikimedia project's credibility is called into question is imo money fairly well spent. Sohom (talk) 16:40, 30 September 2026 (UTC)
That would indeed be money well spent if that's what the $42K bought. A bargain, I would say. The problem is that you have offered no examples where having One More Web Page On Meta actually avoided any incident where any Wikimedia project's credibility was called into question. Not even a plausible path where that might happen in the future. You seem to be saying that money spent on goals without any hint of a way to actually accomplish those goals is money well spent. I say that $88.43 per word is way above the going price for good intentions, which are currently so cheap that they pave roads with them. --Guy Macon (talk) 22:34, 30 September 2026 (UTC)
The problem is that you have offered no examples where having One More Web Page On Meta actually avoided any incident where any Wikimedia project's credibility was called into question - The m:CheckUser policy and the m:UCoC would be prominent examples of the a "page on meta fixes problems" effect. Sohom (talk) 00:21, 1 October 2026 (UTC)
Please accept my apologies in advance for saying this, but with phrasing like "Wikimedia Foundation's overarching programmatic goals to better the community" you could run for senate. The problem with their research results was similar. Too many words, too little substance. Sorry, but bluntness was needed here. Yesterday, all my dreams... (talk) 15:07, 30 September 2026 (UTC)
Foundation's overall goal of making the wiki community better is what I meant. Ignore the word programmatic, it's a reference to the way WMF and other non-profits calculates it's budget, (as programmatic expenses and non programmatic expenses). Sohom (talk) 16:28, 30 September 2026 (UTC)
Guy, I think $42,355.25 was wasted on the word salad they produced. The other $1 was useful, given that it made me laugh. Yesterday, all my dreams... (talk) 14:56, 30 September 2026 (UTC)
In this edit, Guy Macon wrote, The first two results are trivial and the third is just plain wrong. I think it would be good if Textaural, who is an experienced enwiki editor, could respond here. The peer-reviewed research paper is technically a WP:RS, so usable in enwiki articles, but peer review does not guarantee correctness.
I agree that the third key resultThe status of rules [on these 5 Wikipedias is] established largely by individual decisions and rarely through collective decision making is extremely dubious for at least enwiki and frwiki. The strings !vote and not vote seem to be completely absent from the published paper. In a nutshell: If I'm the individual to first write the enwiki policy that 1+1=2 is a fact and nobody contests that, it's not due to my dictatorial authority; it's due to the WP:!VOTE decision-making algorithm and the nature of 1+1=2 being widely considered as reasonable, without anybody needing to argue about it (leaving aside modern foundations of mathematics). The whole point of not holding a vote on my hypothetical new policy is that getting 10,000 votes (not !votes) with a likely result of 99.9% in favour would be a huge waste of time. @Textaural: How do you justify your extraordinary conclusion that Within the English-language rules, the authority of rules was based on the editorial authority of one user, who may have found support through limited deliberation without having studied the role of WP:!VOTEs in the establishment of enwiki rules? !VOTEs are a form consensus decision-making, which is a form of collective decision-making. The authority of rules is not based on the editorial authority of one user; it's based (often) on the ability of one user to successfully describe and summarise the current consensus or predict the likely consensus.
Textaural: do you have any evidence for this claim that you and your authors assert in the paper? The Methods section of your paper says nothing about how you quantify the unexpressed non-objections to enwiki rules (a possible method would be to obtain permission to do a survey of Wikipedians to see how much they agree with existing rules and whether or not they have tried objecting to rules they disagree with; but you don't seem to have done that). Boud (talk) 11:07, 30 September 2026 (UTC)
"Rules"!== policies to my understanding. Sohom (talk) 11:23, 30 September 2026 (UTC)
Fair enough, my understanding is that the paper discusses the individual rules inside the policies instead of the policy as a whole but I can see it being taken in both ways Sohom (talk) 14:04, 30 September 2026 (UTC)
I also noticed that the author uses https://artandfeminism.org/resources/research/unreliable-guidelines/ as a source. Artandfeminism.org appears to be funded by the WMF through WikiCed ( https://www.wikicred.org/). I can't find any record of how much the WMF gave artandfeminism.org to say "This research project identifies the ways that organizational values and processes around reliability and the reliable source guidelines are implicated in maintaining hierarchies and excluding marginalized knowledges and communities" and "Ultimately, the Reliable Source guidelines are an unreliable and incomplete guide to provide editors with a meaningful understanding of how to assess source reliability".
So what are we supposed to replace our reliable source guidelines with? "Triangulation". If anyone can understand what (cited by artandfeminism.org) is talking about please explain it to me. --Guy Macon (talk) 13:16, 30 September 2026 (UTC)
I don't disagree that Art+Feminism is funded to a certain extent by the Foundation, but last I checked, it wasn't through WikiCred? WikiCred organizes meetups in the West Coast and builds tools for media reliability on Wikipedia, Art+Feminism advocates for better coverage of topics related to gender, feminism and art (among other things). They were one of the advocates for a global UCoC and and have long advocated for changing our guidelines to be more inclusive towards marginalized communities and better enforcement of civility policies. I don't think there is a correlation between WMF funding Art+Feminism, Art+Feminism being cited as community criticism of the reliability guidelines and WikiCred organizing conferences. Sohom (talk) 16:25, 30 September 2026 (UTC)
Re: "last I checked, it wasn't through WikiCred?" you need to do a better job of checking. Look at Read the funding section. What we have here is an informal community of organizations united in the goal of writing proposals that will result in the WMF giving them grant money. If only the WMF would check to see if the goals in the proposal were actually met and, if not, find some other applicant to award the next round of grants to. --Guy Macon (talk) 23:00, 30 September 2026 (UTC)
To quote the paper, Unreliable Guidelines, a project of Reading Together: Reliability and Multilingual Global Communities, is an inaugural Art+Feminism research report partially funded by WikiCred, which supports research, software projects and Wikimedia events about information reliability and credibility. WikiCred and Art+Feminism are together funding the paper with At+Feminism being the primary sponsor and WikiCred being a partial sponsor. The Funding section in particular say The expertise of the main researchers was partially funded by WikiCred and Art+Feminism. i.e. that this project was a collaboration between AF and WikiCred. Nowhere does it say that the Art+Feminism is funded by WikiCred. Sohom (talk) 00:27, 1 October 2026 (UTC)
When I skimmed that paper yesterday, I also had several qualms with the methodology leading to those conclusions: off the top of my head, they ignored pages with a creation date before 2005; they only looked at edits which change the label (between essay, guideline, policy, etc.); and they only looked talk pages when explicitly mentioned in an edit summary.
To expound a little: if I'm reading it correctly, it would ignore (to list a few non-exhaustive examples), talk discussions not mentioned in the edit summary; discussions which affirm the status quo; changes which align content to community consensus without changing the "label" of a page; and implicit consensus where thousands of people have read a page and no one has found reason to change it. LittlePuppers (talk) 21:56, 30 September 2026 (UTC)
Well hello there! I've been meaning to respond for a while and just got the chance to do so and thanks for notifying me that this conversation was happening. I'm replying to @Boud here, but it is more of a general response to the discussion.
First, the goal as a researcher is to have your research read and discussed and if for anything else, I am grateful for that happening here. And I appreciate those of you who have defended my work (and "research" in general), but also Guy who is asking some hard questions that should be answered. I will break down my response to answer three questions: Why did it cost 42K to produce one paper? Is the research worth it to those who donate to Wikipedia? Are the results of this research interesting, valid, and valuable to the community? Textaural (talk) 13:13, 19 October 2026 (UTC)
Why did it cost 42K to produce one paper?
The most direct answer for this is that the university that manages the money also sets the pay scale for research time, and so that cost is actually somewhat outside of the individual grantee's hands. For some background, The WMF was interested in ensuring that the project I conducted covered as many possible language editions as possible because there is so little research done on policy itself, let alone Arabic, Spanish, and Dutch policies. To do this, I also needed to hire more researchers to do this work, and two of the researchers were multilingual (which did helped to limit the number of people involved). But to meet those requests by the WMF and to draw from the university's labour pool I did have to hire two post-docs.
In the end, a significant proportion of money went to paying all the researchers for their labour in accordance with university's own pay scale for research time. The secondary cost, but far far less than the cost of labour, was travel to one conference. We attended other conferences that we attended, but these were online conferences which incurred no extra cost for the grant. We also published with New Media & Society which is a top ranking journal in the field, but importantly, has an agreement with the university where the costs of publishing open access is covered by the university, and not individual researchers. This meant that the open access publishing cost (which can be about $4000-$5000 depending on the journal) was paid for by the university and itself, and not the WMF. As surprising as this may seem, in comparison to other research projects, my project was quite frugal.
That being said, the project was supposed to last only one year, I extended it for a second year because the research required it (but with no increase in grant money) and I ended up working many hours on it in my free time into a third year. So in fact, this project would have cost more if the entire research time was paid for. So while we are accustomed to thinking of knowledge as free here on Wikipedia, research itself in general is quite expensive.
So that is some of the details on the cost. Textaural (talk) 13:13, 19 October 2026 (UTC)
Is the research worth it to those who donate to Wikipedia?
I understand the reasoning of this kind of question, and I have two considerations of it. The first is that the WMF funds do not just come from the community. From the 2024–2025 Annual Report, 22 corporations (Google, Microsoft, Rockafeller, etc) and private citizens donated _at least_ over 50,000 each. A conservative estimate puts this group of major donors donating a minimum of 1.1 million. 47+ donated 15K-49K; another 108+ donated 5K-14K. This is missing sustaining donations and one-time donations. So a very conservative calculation is that at least 2.3 million of the donations in 2024-2025 came from organizations or wealthy individuals. What I'm trying to say is that Wikimedia's funding is diverse. So perhaps, if you are less keen on research like mine, the consolation prize is that we can consider that Google paid for it, not Wikipedians. But I obviously think this research does has value (see final question).
One thing I'd like to add is that the WMF continually highlights in the grant process that they expect researchers to connect with the community during the research phase. On this front I'll admit that I should have done better. But I was also a bit unsure at the time exactly how to go about it and where is the right place to notify Wikipedians that I was historically analyzing policy and what kind of feedback the research required. Despite my uncertainty, I should have tired. I am now more aware of how research can be communicated, and I at least know who to ask now when I start my next project. But any further advice would be welcome. Textaural (talk) 13:13, 19 October 2026 (UTC)
Are the results of this research interesting, valid, and valuable to the community?
First, this research is historical in nature, looking at how policies first emerged and gained their authoritative status in the form of policy templates, and so the immediate outcome for the community is to gain an additional view on how the encyclopedia developed. Second, one critique was that some of the results were trivial, and one was wrong. The two "trivial" conclusions are (at least from my perspective) descriptive conclusions, they are facts. Making facts that are rooted in empirical evidence is difficult, time-consuming and painstaking work, something that all Wikipedians are aware of. So now there is a reliable source for these facts.
It was also pointed out that this research was framed on its meta page as wanting to find gaps in the policies. On this front, what we identified is that a the explicit authority of policies (as it is advertised in the policy template at the top of the page: "This is a policy") was itself often not created out of a consensus process, but was created through the decisions of a very few users. In the language of gaps, I see our research as indicating the ways that some things that we think are made through consensus on Wikipedia, are assumed to be, when in fact a close inspection shows this not to be the case. As such, our article makes a small but substantial argument: that here, in the specific cases of how early policies were tagged as policy, guidelines, etc, was not itself derived through a process of consensus. This does not mean other parts of a rule were not created through consensus, just this specific part that tells everyone on Wikipedia which wikipages are policies and which ones are not.
The evidence was based on looking at 15 rule pages, and examined their development (usually the late 2000s; early 2010s), tracking who said and did what around the times when the status of a policy changed. We have a clear We found that some fundamental policies were given the authority of a "policy" adding the policy template, rather than a coherent and explicit deliberation of many users. As such, I argue that this does not qualify as consensus as broadly imagined. Indeed, trying to understand what consensus is and how it manifests on Wikipedia is an interesting question that is a focus of my research (here and here and here) and this paper extends these ideas.
So why does it matter? There are cases where the process where a rule gains its authority as a policy is not in keeping with the ethos of consensus. The application of a template of "This is a policy" is self-reinforcing. In other words, the article asks that we actual examine how the authority of these policies were designated in the first place, rather than taking it for granted: something that I think is important to consider for all policies. And I hope leads to making Wikipedia get even closer to its ideals.
And if you are more curious about the argument, I encourage you to read it, and if you have questions about the empirical side of the argument, the dataset is also available. Textaural (talk) 13:14, 19 October 2026 (UTC)
Hi Textaural, thanks for the response. I'm curious how you would respond to my initial conclusions from skimming that paper: basically, that (as far as I could tell from reading your methodology) only looking at changes specifically to the page and those directly referenced in edit summaries ignores many forms of consensus-building. For example, a talk page discussion that was not mentioned in an edit summary; community discussion at some other venue (e.g. WP:VPP); a discussion which affirms the current status (thus strengthening consensus but not leaving anything in the page history); etc.
And regardless, I think it's also worth considering how changes to a policy over time bring it more in line with consensus; in short, perhaps back in the early 2000s (well, late 2000s, as policies from the early 2000s were excluded from your study) there were sometimes these nigh-unilateral status changes, but (and I'm not trying to put words in your mouth) I don't see a compelling argument that, after hundreds of discussions about and tweaks to these policies and guidelines, and thousands of people referring to and using them, they don't reflect something near to consensus now.
(Sorry, I know that's not particularly eloquent prose, but hopefully it's comprehensible. I'm just trying to understand your research better and what it does and does not cover.) LittlePuppers (talk) 21:11, 19 October 2026 (UTC)
On the point: The two "trivial" conclusions are (at least from [Textaural's] perspective) descriptive conclusions, they are [factual claims]. [Rooting factual claims] in empirical evidence [for or against them] is difficult, time-consuming and painstaking work, something that all Wikipedians are aware of. So now there is a reliable source for these facts, I fully agree (though I've reworded a bit more carefully from a WP:WIKILAWYERING POV). Boud (talk) 12:32, 22 October 2026 (UTC)
@Textaural: Glad that you've responded. However, you have not responded in plain language to the basic concern about your third claimed result: that you have not measured the full participation in the rule making used in the standard Wikipedia consensus decision-making algorithm and you have nevertheless made strong claims that the rule making was highly non-participatory, i.e. your published claim is not supported by your evidence, and you don't yet seem to have acknowledged that. Per Rhododendrites' suggestion below, I've started a section on metawiki on the talk page describing your article. I propose that people interested continue the discussion over there. I already pinged two people over at meta, I'm not sure if Sohom Datta wants to follow that discussion too. And, of course, there are the non-commenting implicit participants in this discussion who are leaving no trace in the wikirecord: those who feel that the things already stated are sufficient and feel that their overt participation would make the thread more messy rather than clearer. I cannot ping those implicit participants. Boud (talk) 13:34, 22 October 2026 (UTC)
Can I suggest separating, to the extent possible, the funding question from an evaluation of the paper? The WMF does not read the outcome of a project before funding the project, of course, so really it's a question of "should the WMF invest in research about Wikipedia governance" not "should the WMF invest in this paper". Yes, "was this worth it" is a fine question to ask, and one that the WMF answers internally, too, but any evaluation of the funding question should be based not on "I found one I'm skeptical of" but on a full accounting of related projects. I haven't engaged deeply with this paper yet (open in a tab in my "to read" window for some time, sadly), but the project sounds worth doing to me. We have precious few studies that examine Wikipedia governance anywhere but the English Wikipedia, and a direct comparison between several language editions is very potentially valuable. And NM&S is easily one of the top journals for non-computational Wikipedia research these days. That doesn't mean everything it publishes is perfect, but it has a high rejection rate, intense peer review process, and deep bench of Wiki-knowledgeable reviewers. That said, as with any Wikipedia research, it's also valuable when volunteers evaluate the content and correct the record, if appropriate. A quick search through the signpost archives doesn't turn up a match, so maybe it's a good fit for the next Research Report. —Rhododendritestalk \\ 16:16, 30 September 2026 (UTC)
I couldn't find an easy way to view multiple grants to the same researcher, but The WMF does read the outcome of a project before funding the next project by the same researcher. --Guy Macon (talk) 10:28, 6 October 2026 (UTC)
On a couple of occasions Guy Macon has said A lot of those donors are living in poverty and sacrifice to give because they were told that this was needed to keep Wikipedia free. I wonder what evidence supports this claim. I find it far fetched. Johnjbarton (talk) 15:33, 22 October 2026 (UTC)
I will be happy to support my claims with citations to reliable sources, but I need to know exactly what you are objecting to.
Are you claiming that the WMF doesn't send banner adds that get read by people living in poverty in Appalachia, India, and western Africa?
Are you claiming that the WMF doesn't clam in those banner ads that donations are needed keep Wikipedia free?
Are you claiming that the banner ads are totally ineffective and do not result in donations?
Are you claiming that for some reason only people above the poverty line respond to banner ads by donating?
Something else?
Please let me know exactly what you are disputing so I can post evidence to support my claims. --Guy Macon (talk) 16:15, 22 October 2026 (UTC)
I am challenging you to support your claim that a significant number of donors suffer hardship because of WMF actions. I do not think you polled donors living below the poverty line and determined that they were deceived. I do not think you represent a harmed class. Your critique of 0.0002% of the budget is fine, because an open source project should be open to criticism. But you should speak for others. Johnjbarton (talk) 16:43, 22 October 2026 (UTC)
Got it. You agree that the WMF sends banner adds that get read by people living in poverty, that those banner ads say that donations are needed keep Wikipedia free, that people respond by donating, and that some of those people are living in poverty. Your only objection is that the WMF (the only source that has access to that information) hasn't published data on donations by people living in poverty, and you refuse to believe that they exist if you can't count them. Thanks for clarifying your objection. --Guy Macon (talk) 17:15, 22 October 2026 (UTC)
Guy, it is not in dispute what the banners say, or that people living in poverty see those banners. What is being asked for is evidence for your claims that
People living in poverty donate in response to those banners
People suffer hardship because they donate in response to those banners
You say in your most recent comment that evidence for those claims does not exist, if so then you need to withdraw those claims and stop making them. If that evidence does exist, then you need to present that evidence. You cannot continue to cast aspersions on the WMF without evidence. Thryduulf (talk) 17:33, 22 October 2026 (UTC)
The burden of proof is on anyone who makes the extraordinary claims that you can take money from people living in poverty without affecting them or that poor people don't respond to WMF banners. --Guy Macon (talk) 17:48, 22 October 2026 (UTC)
You are the one making the extraordinary claims that the WMF are taking money from people living in poverty and that people are donating so much to the WMF that they are suffering hardship as a result. You have still presented no evidence for either of those claims. Thryduulf (talk) 18:39, 22 October 2026 (UTC)
That's not how it works. None of my claims are extraordinary. Yours are so extraordinary and outlandish that I frankly refuse to believe that you actually think that poor people don't respond to WMF banner adds or that poor people are not harmed by making them poorer. Who made the claim is irrelevant. Whether I make a claim that ghosts exist or that plants do calculus or whether you make the claim that they don't, the burden is on the person making the extraordinary claim, not on whoever made the claim first. -Guy Macon (talk) 23:01, 22 October 2026 (UTC)
Guy Macon, you said I will be happy to support my claims with citations to reliable sources... Please let me know exactly what you are disputing so I can post evidence to support my claims. We would like sources showing that A lot of those donors are living in poverty. LittlePuppers (talk) 23:17, 22 October 2026 (UTC)
5.46% or Wikimedia foundation ads get clicked on. 3.77% result in donations.
Families living in deep poverty face profound material, social, and emotional hardships. Households in deep poverty suffer from food shortages, unemployment, unstable housing, inadequate medical care, electrical shutoffs, and isolation. All US states have at least 5% of their children living deep poverty, including nearly one in five Black children under the age of five (Deep poverty is defined as living in a household with total cash income that is below 50% of the poverty threshold. It is a higher income level that the extreme poverty levels discussed above.)
I would also like to see your reliable sources that show:
People living in poverty donate to the WMF because of the WMF's fundraising banners
People suffer hardship because they donate to the WMF because of the fundraising banners
Those are claims that you made. You offered to support claims you make with reliable sources. Please do so. The burden is not on me to support claims that I am not making. Thryduulf (talk) 23:52, 22 October 2026 (UTC)
That's not how the burden of proof works. The burden in on the person making extraordinary claims, not on whoever spoke first. If I say that the Loch Ness monster doesn't exist and you reply that it does, the burden of proof is still on you to prove it exists because your is the extraordinary claim. --Guy Macon (talk) 00:26, 23 October 2026 (UTC)
Those are claims you made. Those are extraordinary claims. Therefore the burden of proof is on you. I am not making any claims, extraordinary or otherwise, I'm simply asking you to provide the evidence that backs up the claims that you are making, claims which you have claimed are supported by reliable sources. Thryduulf (talk) 00:48, 23 October 2026 (UTC)
None of those sources support any of the claims that you are making. They do support claims that nobody is disputing, specifically:
The WMF run ads in those territories
Some people who see ads click on them, and some of those people donate
Some people who live in those territories live in (extreme) poverty
Deep poverty causes harm to people who live it
Remember that correlation does not imply causation, and you haven't even shown correlation here. Thryduulf (talk) 00:56, 23 October 2026 (UTC)
This is not something that will be resolved by citations. It's a rhetorical move -- invoke a hypothetical sympathetic donor to delegitimize whatever the criticized-expense-of-the-day happens to be. In my opinion, the "people donate their hard-earned money because they think Wikipedia will die without it" argument makes some sense when criticizing the intensity of banner appeals, but just sounds condescending when trying to litigate specific expenses. At the end of the day you can accept it or ignore it, but it's not a citation issue. —Rhododendritestalk \\ 17:34, 22 October 2026 (UTC)
Good point. If the banner ads said something like "your donations go towards all the good things Wikipedia does" my entire argument would collapse and I would withdraw it. It is the combination of claiming that without your donations Wikipedia will no longer be free and the spending of those donations on things that have nothing to do with Wikipedia remaining free that I object to. Remove either leg and the argument falls over. --Guy Macon (talk) 17:48, 22 October 2026 (UTC)
Ok so you just represent Guy Macon. I think your argument makes sense in these terms, even if I don't agree with your conclusion.
In my opinion, the research effort Slow Editing Towards Equity was a high leverage investment in keeping Wikipedia "free". High-leverage because this amount of money is very small; investment because it was risky. It resulted in a published paper, above average results for that small investment. It engaged with scholars which may help further scholarly work on the structure of Wikipedia and its effectiveness. This kind of work might even be more important than paying electric bills for servers: Wikipedia has been challenged as unfair by both progressive and regressive ideologs so some exploration in to the effectiveness of policy structure makes sense. Being taking over by ideologs seems to me one o greatest risks to Wikipedia. Since "some" is in this case "almost trivial" this investment seems ok to me. Johnjbarton (talk) 18:29, 22 October 2026 (UTC)
I am writing to you today with an update on the planned changes to the Board elections process. The Board has been receiving feedback on its original elections process proposal since July. Thank you to the many people who participated onwiki, in person, or in direct conversation with Trustees. The feedback was extremely helpful.
Based on this feedback, the Governance Committee has decided that the eligibility criteria approach (as originally proposed) is not a good fit. Instead, we have developed two potential approaches we can utilise in the future. We are asking for your feedback again to inform our decision about which approach to use, starting with the 2027 selection process. Our goal is to have a process that is predictable and that does not require annual updates, although we recognise there may need to be minor adjustments in the future depending on facts and circumstances and lessons learned from 2027.
From a Board governance perspective, the fundamental requirement is that every trustee strengthens the Board and benefits the Foundation through the experience they bring. The Board oversees a community- and technology-focused international nonprofit organization with over 600 staff members across dozens of countries and an annual budget of almost USD$250 million. Every trustee must be able to operate, support and contribute in that environment. In addition, they:
must be able to work well with others;
must be able to make informed decisions based on an assessment of the best interests of the Foundation;
must be able to ask insightful questions;
must be willing and able to communicate decisions to the community and in other public spaces; and
they must have the confidence necessary to contribute their opinions and perspectives.
All trustees must also be able to commit to the confidentiality agreement of the Wikimedia Foundation in addition to exercising sound judgment and discretion, as well as managing any potential conflict of interest, both within and outside the Wikimedia Movement. The question is how to design an election process that ensures that every candidate on the final ballot meets that bar while still being a meaningful election where Wikimedians are the ones selecting the winning candidates.
Regarding "While the Board cannot forego its vetting process and its authority to remove candidates from the final list, we can make the process clearer", one of the major concerns among the volunteers has been the possibility of a future board making a decision that is so unpopular that is sparks open revolt among the volunteers, followed by the same board removing any candidate that does not support the decision.
While I have no doubt that the current board is pure and good, I do not have the same confidence in all possible future boards. By allowing the board to select itself you are preventing any any future reform movement from firing the board without the board's permission, no matter how bad that board is. This appears to be a clear conflict of interest.
Honestly? If the board isn't willing to take a far more liberal approach to board elections, then they should just be honest about it and drop the façade that the community has a meaningful voice on the board. CoffeeCrumbs (talk) 01:28, 11 October 2026 (UTC)
First choice recommendation: I recommend that someone who has no COI look at potential candidates and disqualify those that need disqualifying. Form a new group that does just that, hire an outside consultant, anything other than giving current board members the power to decide who can and cannot be elected to the board. Second choice recommendation: Stop pretending that this is an election. Just be honest and let the board select new board members without the sham election.
If you are serious about this being a fair election, whoever does the vetting should commit to disqualifying candidates without regard to whether they are likely to reverse any decisions of the current board, and should not be in a position to benefit from future board decisions.
Guy's suggestions are about what I think. Either have an outside consultant screen for set, objective standards or just drop the whole pretense. We're adults here; this isn't a grade school student council election where kids running promise more pizza days and homework bans. If you're not going to let the Wikipedia community have the power to elect people who can change the course of the WMF against what the board might currently want on some issues, then the elections are just Politburo "elections." CoffeeCrumbs (talk) 19:57, 14 October 2026 (UTC)
I agree with Guy. Elections where the board can arbitrarily reject candidates are not real elections, they just give the resemblance of community representation without giving any power to the community (which is worse than no elections at all). If screening is so important (why? Is the community choice not enough?), it should be done by a third party that is not influenced in any way by the board or the WMF Ita140188 (talk) 09:46, 15 October 2026 (UTC)
I also agree. I'm seeing an accelerating trend, of WMF leadership looking upon experienced members of the editing community as being something other than what the WMF movement is about. Kiss up, kick down leads to organizational obsolescence. --Tryptofish (talk) 23:58, 15 October 2026 (UTC)
RE: The requirements for a board member
The community being 4th, lumped in with the public as a whole, and only presented as something to be communicated to (rather than worked with) is deeply concerning and suggests the board failed to learn from all the happenings earlier this year. MetalBreaksAndBends (One for all) 14:15, 15 October 2026 (UTC)
It's deeply concerning but I think it's a difference of opinion rather than a lack of understanding. Wikipedia editors want a say in the governance of Wikipedia; the WMF wants to prevent that. Certes (talk) 15:16, 15 October 2026 (UTC)
Which seems like a relatively recent development to me. I don't remember the Trustees being like that when I first started editing in 2018, but maybe I wasn't paying attention. Levivich (talk) 18:09, 15 October 2026 (UTC)
"All organizations eventually come to be run by a leadership class... Far from being servants of the masses, this leadership class, rather than the organization's membership, will inevitably grow to dominate the organization's power structures... These mechanisms can be used to strongly influence the outcome of any decisions made 'democratically' by members."
We really need to take away the board's self-created total immunity to any reform now, while the volunteers still pretty much agree with the direction the WMF is going. If we wait until some future where the volunteers have formed a angry mob with torches and pitchforks vowing to take down a future board. the likely result will be replacing one bad set of all-powerful oligarchs with another slightly less bad set of all-powerful oligarchs. --Guy Macon (talk) 00:49, 16 October 2026 (UTC)
Well, looking at the stats for the last election, I think the pro-wwu block will be at least a significant minority in the next election. I, for one, will be voting for the most-wwu aligned candidates who are at least mildly competent, and will likely vote replicating whatever the most popular wwu-aligned guide is, if there is one. MetalBreaksAndBends (One for all) 02:06, 16 October 2026 (UTC)
It's worth keeping in mind that unionization of WMF employees is only one part of what is going on here. There are broader issues of whether or not the Board is willing to listen to what the editing community is saying, in many different aspects of how the WMF works. --Tryptofish (talk) 23:25, 16 October 2026 (UTC)
While the union has received a lot of attention lately, there are many other areas where both WMF management and the board appear to be highly motivated to never let the community have a say. As an example, I have repeatedly asked a Frequently Unanswered Question (F.U.Q!) that I am convinced will disqualify any candidate that shows a willingness to ask it: Pick a Wikimania. Any Wikimania. Tell us what it cost our donors and who received the money (as far as possible without naming any individual or violating anyone's privacy). --Guy Macon (talk) 02:24, 17 October 2026 (UTC)
I am aware that there are far far more issue with the WMF than just the handling of WWU. But support for the WWU is highly correlative with other good positions, so asking "What do you think the WMF did wrong with regards to WWU and the community?" and "How will you prevent similar breaches of volunteer trust in the future?" both show a person's stance on more than just WWU while also giving people who's first instance of WMF betrayal was comtech and/or WWU a clear guide on who's good and bad. MetalBreaksAndBends (One for all) 03:17, 17 October 2026 (UTC)
Reminder: meta:FUQ is ready for further edits. Currently two unanswered questions + one question answered within seven weeks. Boud (talk) 16:51, 22 October 2026 (UTC)
"The question is how to design an election process that ensures that every candidate on the final ballot meets that bar while still being a meaningful election where Wikimedians are the ones selecting the winning candidates." A clearer admission that the Foundation does not trust or respect the ability of the community to make good judgements would be hard to imagine. DuncanHill (talk) 23:29, 16 October 2026 (UTC)
What concerns me most is that the criteria for disqualification appears to be entirely arbitrary. I’d understand if they had specific, well deliberated red lines based on obvious community interests that they point out and hold to, but they’ve left it instead as an indeterminate line in the sand that they can seemingly redraw whenever they want depending on whatever their concern at any given moment is. It’s quite easy to justify that with the notion of “well we don’t know what we’re going to come up against”, but the fact that they won’t give the boogieman a face or even a facade as a good faith gesture to the community in advance (to allow time for potential nominees to consider input by the community writ large and self-select in the interest of putting forth the most undisqualifiable candidate who nonetheless shares their underlying values), is what irks me most heavily.
Democracy ultimately starts to crumble when leaders monopolize the authority to determine what (or who) is right or wrong, and what’s ultimately an acceptable question for the electorate to get to answer. If they’re implying here that the community they’re responsible for governing can’t be trusted to act in its own interest and not elect a fascist, then we really should just close up shop right now, they’ve clearly already failed spectacularly in their mission.
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on September 25. Please help translate.
Screenshot of the Thanks feature.
Highlights
Community Wishlist: Community Wishlist is looking for volunteers to join their working group. You can find details on the goal of the group, roles and expectations, norms we'll follow, and how to sign up on this Meta-Wiki page.
Human knowledge at stake: Wikimedia Foundation makes the case for human knowledge at the UN General Assembly and how scrapers are straining our infrastructure and the larger human knowledge ecosystem online.
Joy of contributing:How a simple thanks fuelled one of our Wikimedians of the Year as they connect the community.
Wikimania scholarship deadline extended: The deadline for Wikimania 2027 scholarship applications has been extended through the end of day on November 4, 2026 (Anywhere on Earth). This is to compensate for a pause in the application window on October 15, 2026 from 1pm to 6pm UTC, to allow for an upgrade to the LimeSurvey platform.
OpenAI agent activities on Wikimedia projects: The Wikimedia Foundation have discovered some activity by “rogue” OpenAI agents on Wikimedia platforms. These unauthorized bot activities included edits to our wikis, some unsuccessful attempts to exploit a public note-taking tool we host, and heavy traffic.
Listening to Wikipedia: The Phase 1 experiment for Listening to Article intros within the Android app’s “For you” feed has been released into the Wikipedia Beta App. This experiment tests whether adding a listening format into the "For you" feed has the potential to deliver improvements in reader retention.
Bookmark button on mobile web: Logged-out Wikipedia users on mobile web will begin to see a bookmark button for saving articles to their reading lists instead of the current Watchstar button. When clicked, the bookmark button prompts users to log in or create an account to save an article for later, to encourage more readers to become account holders.
Abstract Wikipedia piloting showing articles to readers: Three initial pilot communities are currently working with the team to explore using abstract articles on their Wikipedias: Malayalam, Dagbani, and Igbo.
Simplifying account creation: An experiment has begun on Spanish, Arabic, English, and French Wikipedias to simplify the experience users encounter immediately after account creation. The test will explore whether removing friction from the current Welcome Survey helps new users understand what to do next more easily.
Latest experiments: An upcoming experiment is testing a personalised module, called 'Review Changes', for Home which aims to introduce newer editors to the concept of reviewing the edits that other users are making. See all live, upcoming, and completed experiments in Product & Technology.
Tech News: The latest highlights from Tech News weeks 40 and 41 include users of default skins on desktop and mobile web will now be informed if the search results displayed come from page redirects. See also the 20 community-submitted tasks that were resolved over the last two weeks.
Improving developers experience: Two new features has been shipped to improve developer experience: Spiderpig (deployment web interface) which allows developers to leave notes for each other about errors they see in the logs and Patchdemo, which now supports in-browser code editing, so developers can make quick changes without needing to push a new patch and recreate the demo.
Strengthening infrastructure: To reduce the workload from non-pageview requests, the overall number of database queries per logged-out pageview has been reduced by 52%, from a baseline of 23 queries/pageview in August, to 11 queries/pageview today. Read more.
Increasing test reliability: To reduce friction in post-merge validation and ultimately improve confidence in release decisions: Catalyst was proven to be a much more reliable environment to run daily Selenium tests (95.7% eventually green) compared with the beta cluster (79.1% over the same 10 suites). This gives confidence to automatically catch issues before they reach production.
Transparency Report: The latest Transparency Report has been published. Out of 953 requests for content alteration and takedown, only 2 requests were granted. The Foundation continues to prioritize the public interest and is guided by the content moderation policies the volunteer community has shaped over the past 25 years.
Affiliations Committee: Wikimedia Affiliations Committee Has New Officers and Advisors. Read also the latest issue of the AffCom News to learn more about their work.
Board of Trustees Elections Process: The Board has reviewed the feedback received since July on its elections process proposal, and thanks everyone who shared input on Wiki, in person, or directly with Trustees. Based on that feedback, the Governance Committee has moved away from the eligibility criteria approach and developed two new options for the 2027 selection process and beyond. We'd like your feedback again before deciding. Please read the proposal and share your feedback on the Meta-Wiki talk page by October 27.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. If you have feedback or suggestions about the bulletin, let us know at foundationbulletin@wikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
At Resolution:Board Expansion 2020 the WMF resolved to "to reach a total of up to sixteen (16) [seats], as soon as practicable" and "Resolved, that the final composition of the 16-member Board of Trustees shall consist of a Founder seat, eight (8) seats sourced from the wider Wikimedia community, and seven (7) Board-selected seats" (approved on February 13, 2020)
At Resolution:Amended Bylaws Articles IV & V (2020) it says "The authorized number of Trustees of the Foundation shall be at least nine (9) and, at most, sixteen (16), as the Board may from time to time determine." (approved on December 9, 2020)
At Legal:Wikimedia Foundation Bylaws it says "The authorized number of Trustees of the Foundation shall be at least nine (9) and, at most, sixteen (16)", "As many as eight (8) Trustees will be sourced from candidates vetted through a Community and/or Affiliate nomination process."., and "As many as seven (7) Trustees may be sourced, selected and appointed directly by the Board." (the 16th seat will either be Jimmy Wales as Community Founder Trustee or will remain vacant). Also "The Board shall not appoint a new Board-selected trustee if it would cause the Board-selected Trustees to outnumber the Community- and Affiliate-selected Trustees." (last updated December 9, 2020).
At Wikimedia Foundation/Board of Trustees#Current members I count 1 founder, 3 appointed, and 6 Community/Affiliate (total of 10) and at Wikimedia Foundation/Board of Trustees#Current members I see that that number has never exceeded 12. (BTW, could someone please fix the colors in that section? It says that 0 members of the current board are Community or Affiliate and 6 are founding members -- but from 2004 to 2009 Jimmy Wales wasn't a founding member.)
So, was that "Inadequate capacity on the present ten-member board to most effectively carry out its responsibilities in light of considerable Foundation growth; the increasing diversity and complexity of the products, services and communities the Foundation serves; and significant external technological, legal, and political challenges" just blowing smoke? Did the ten-member board somehow acquire adequate capacity? --Guy Macon (talk) 05:08, 15 October 2026 (UTC)
The Wikimedia Hackathon, the yearly software engineering conference, may stop being a global conference
I can't say I'm very happy about this proposal: mw:Wikimedia Hackathon/Community Proposal 2026. This is a conference for Wikimedia software developers that I attend yearly, and that I consider to have an extremely successful format. The above proposal appears to want to take the money spent on this conference and basically kill it off to spend it on smaller regional conferences, except for every third year.
I'm not sure this is the correct place to post this or if it will resonate with people here. But this is something in the pipeline that is frustrating me. I wish WMF would leave stuff that's working alone and not make big changes to it.
I really hope this doesn't become a wishlist situation, where we have to put up with a poor format for a couple years, then finally there is a big backlash to get it changed back. I'd rather they just not make the questionable changes in the first place.
Thanks for listening. –Novem Linguae (talk) 06:09, 18 October 2026 (UTC)
"Our goal is to better understand whether concentrating our resources on one global event held in the same region each year creates barriers to participation or limits our ability to develop technical contributor communities in other parts of the world." There seem much easier ways to trial this than an immediate three-year experiment. For example, there are already regional conferences, trial a hackathon at one or two of those. Much less money spent for the same experiment without immediately affecting the current process. CMD (talk) 10:36, 18 October 2026 (UTC)
Wikimedia Ecosystem pilot feedback report published
Thank you very much to everyone who has contributed with feedback on wiki, at the recent conferences in-person, and on online meetings. Special thanks to those who acted as facilitators gathering and consolidating feedback from specific communities and organizations. This quantity, quality, and diversity of feedback helps us to make improvements in the proposal.
Moving forward, we plan to identify specific questions requiring further discussion and collaboration. We are also thinking of using additional ways to gather feedback and collaborate, to allow wider and also deeper participation beyond talk page discussions and sessions at events. More about all this soon.
In the meantime, we are still open to feedback at the upcoming regional conferences and online calls, as well as on meta, especially from those who haven’t got a chance to share their opinion yet. We will continue listening and integrating feedback as we go. --KVaidla (WMF) (talk) 11:24, 20 October 2026 (UTC)
Digital Security During Election Time: A Workshop with Freedom of the Press Foundation
Election time can be a difficult moment for your digital safety. Political issues take center stage, emotions run high, and online harassment, from unwanted messages to threats and doxing, becomes an easy way to target Wikimedians.
Ahead of the 2026 United States elections, the Human Rights Team, with the kind support of the Freedom of the Press Foundation, is hosting a 90-minute session for Wikimedians to learn about and connect practical steps to protect your privacy and stay safe while contributing to Wikimedia projects and participating in movement activities.
All experience levels welcome. Bring your questions!
New post at the WMF Fundraising Hub - October update
Hi everyone,
A new post is available over at the Fundraising Hub. Have a look what is new in our October update. Best, JBrungs (WMF) (talk) 08:22, 26 October 2026 (UTC)
New features for quickly finding bad-faith content
We (the Wikimedia Foundation Product Safety and Integrity team) have been working with volunteers for the last several months on new ways to automatically detect different kinds of bad-faith edits, which are then shown to volunteers to take action on, through a new special page called AbuseReview.
We have focused on two kinds: personal information that likely needs to be suppressed, and vandalism that likely needs to be reverted.
We figured the community here would appreciate some insight into the data we’re seeing and how these features work, including how it interacts with ClueBot NG and existing patrolling efforts. We have a project page that we’ve been updating along the way.
Detecting personal information
For this feature, oversighters are shown likely disclosures of non-public personal information, which typically should be suppressed or revision-deleted according to the oversight policy.
As volunteers described here a couple months ago, it took us working together through several iterations and a lot of manual labeling to develop an accurate classifier. Fancy AI stuff can only get you so far - we would not have been able to make something good enough without hard human work and expertise.
Since deploying this feature, the amount of personal information that is getting caught and removed on English Wikipedia by volunteers has roughly doubled. Oversighters have told us the accuracy rate is consistently better than the human reports they are used to receiving.
Personal data flagged on the Special:AbuseReview page and suppressed
This is built using an AI-powered classifier that runs on top of a language model. After evaluating multiple models, we are using CoPE-B, an open-weight model that is trained specifically for trust and safety purposes, and is maintained by the team at zentropi.ai. We are self-hosting this model, so the live edit analysis is all happening inside our infrastructure.
To use the classifier, we provide the model a plain language “prompt” that describes the specific factors to include and exclude. This prompt was written to match community oversight policies, and has been refined over time based on feedback from volunteers and observed performance.
If you are interested in how CoPE-B works, the creators have published a paper and talk about it on their blog. As a rapid classifier that emits yes/no decisions with confidence scores, CoPE-B bears a strong resemblance to what have more recently been coined “decision models”, like Jev and Clef. In fact, Zentropi recently published a new variant of CoPE-B that is more directly compatible with the “decision model” framework, and which we expect to evaluate soon.
Detecting vandalism
For this feature, volunteers are shown likely vandalism that should typically be reverted. This uses the same model (CoPE-B) as personal information, with a vandalism-focused prompt.
This has been running on English Wikipedia for about a month now, but as a limited alpha test accessible only to a group of volunteers involved in patrolling who raised their hand to help us test the feature. Similar to our development of the classifier for personal information, many of these volunteers also put in the time to manually review many edits to help give us solid data and feedback to work with.
We know there’s already a lot of energy on English Wikipedia when it comes to tackling vandalism, in human and bot form. We consulted with patrollers and with the ClueBot NG team, and we’ve been clear that we don’t intend to displace existing efforts. To avoid creating disruption as we introduce this tool, we are currently defaulting to a delay of a few minutes before surfacing likely vandalism, to let ClueBot NG and others “go first”.
By doing this, we’ve seen that there is a steady stream of vandalism that is slipping through the existing net of bots and humans, and that this classifier can help catch it. We’ve seen less than 1% of flagged edits reported as false positives, and we see a measurable speed-up in how quickly vandalism is getting reverted on English Wikipedia – especially in the longer tail that otherwise might have stayed online for many hours or days.
Time to mitigate vandalism flagged on the Special:AbuseReview page
What’s next
Given the above, we’re now ready to move the vandalism feature out of testing and open it more widely. To start, we have opened Special:AbuseReview to all rollbackers and admins on English Wikipedia. If this community thinks that the feature should be gated on different rights, it isn’t meant to be set in stone, but we do think it is important that the judgments being made within Abuse Review represent experienced patrollers.
Overall, it really seems to us that this new generation of classifiers is a huge quality improvement over what we and volunteers are used to in this space. We are internally working next on a classifier focused on link spam, and early results are already promising.
Finally – while we started with English Wikipedia, we have since worked with oversighters and others on other large Wikipedias to deploy this feature there too, and it seems to naturally translate pretty well. We are open to bringing this to other wikis that are interested.
We are interested in your thoughts – and of course, we deeply appreciate all of the volunteer collaboration on this project so far. EMill-WMF (talk) 16:30, 27 October 2026 (UTC)
I have used the AbuseReview tool for private information extensively, and it works great for quickly identifying likely PII exposure for quick suppression. Often, I'm reverting the edit before anyone is likely to have seen it, so we're likely suppressing before any exposure, as opposed to the old model either finding it while patrolling or someone seeing it and reporting. I've also used the vandalism detection mode, which has also been effective at surfacing edits that may have slipped past recent changes patrollers and Cluebot. Count this as a strong endorsement of both of these tools from me. ScottishFinnishRadish (talk) 17:54, 27 October 2026 (UTC)
I also want to say that I hope that we'll see a way for editors to report issues for revdel and oversight directly into the AbuseReview tool so there is a private on-wiki way to make these reports, which would be a huge upgrade over the current status quo. ScottishFinnishRadish (talk) 11:35, 28 October 2026 (UTC)
Also a very strong endorse from me. I was honestly shocked to see how much blatantly obvious vandalism gets past recent changes patrol, since my newbie experience of attempting to help out with that was that all the vandalism I found was reverted faster than I could get to it. As for the suppressible information... well, I knew it was that bad already, and I think we're surely still missing out on quite a lot. But this has been a huge help in surfacing things that should have been suppressed, but were not reported. In solidarity, asilvering (talk) 19:58, 27 October 2026 (UTC)
I don't have much to say except that I love this. Keep up the good work.
Is there any chance that we will be able to run this on historical edits/pages, so that we can chip down on long term vandalism? EatingCarBatteries(contribs|talk) 20:08, 27 October 2026 (UTC)
I had a short conversation about this with @EMill-WMF a week or so back after becoming aware of potentially libellous material that had been present in a BLP article for several months (since before AbuseReview went live). Based on that conversation, my understanding is that, at least for personal information, something like this is seen as desirable but the practical implementation has not yet been determined. We agreed that simply scanning the whole database and dumping any hits into AbuseReview would overwhelm the system, and this would be even more the case with vandalism (instances of which are more numerous). Several ideas have been suggested but the priority has been to get the live version production-ready first. Thryduulf (talk) 21:58, 27 October 2026 (UTC)
It's great to hear that's being considered. I hope that this does come to fruition, as well as for different purposes like promotional text.
If the system prompt being used is public, I'd imagine someone can repurpose it to run it on their machine on an enwiki dump. But it would take a metric ton of compute to scan on one of those all-revision dumps. EatingCarBatteries(contribs|talk) 07:04, 28 October 2026 (UTC)
I share my colleagues' enthusiasm for this. Finding PII in real time has been a consistent challenge, and the tool for that has made a measurable improvement. Our core purpose here is building an encyclopedia written by humans. Handling vandalism and private information is a necessary task to that enterprise, but it's an unpleasant janitorial task that sucks up editor time. I deeply appreciate the fact that PSI developed a means to automate some of this effort, and also that they worked with volunteers to bring in a level of quality control we are happy with. Vanamonde93 (talk) 20:13, 27 October 2026 (UTC)
It's been a few years since I've regularly done much anti-vandalism work, but from a brief look I really like this tool.
One comment: can we get a button to update the list, rather than having to refresh the page? (Or am I missing something?) LittlePuppers (talk) 21:00, 27 October 2026 (UTC)
You're not missing something, the product is.:) We are in fact working to deploy a "live refresh" mode soon, hopefully next week. EMill-WMF (talk) 21:07, 27 October 2026 (UTC)
I've been using the personal information side of AbuseReview and I can't endorse it highly enough. It's catching the additional of personal information before even new page patrollers can, so we (Oversighters) can suppress it before even they see it, reducing the exposure to sometimes very sensitive information. Thryduulf (talk) 22:01, 27 October 2026 (UTC)
Out of curiosity, what kind of personal information are people trying to add? Is this a matter of people trying to dox another person, or something a newer editor may think is innocent? EatingCarBatteries(contribs|talk) 06:29, 28 October 2026 (UTC)
@EatingCarBatteries Speaking from my personal experience (both as a former child on the internet, and the stuff I've sent into OS): children like posting stuff like which elementary school they go to, what street they live on, their phone number/email address, their full names, ect. This is obviously, not a good idea, but children do not always have a good sense of internet safety. GreenLipstickLesbian💌🧸 07:20, 28 October 2026 (UTC)
@EatingCarBatteries all of the above. People posting their own information is the most common, especially children as noted by GLL, but also apparent adults posting their contact details (email, phone number, sometimes street address) and occasionally other personally identifiable information. Posting the details of others also happens, most often this is in good faith, e.g. children including details of their family members alongside themselves or people adding too much information to biographies, but doxxing does happen. There are also cases that might be self-promotion/spam, might be innocent oversharing or might be doxxing but we have insufficient knowledge to tell (e.g. a pseudonymous editor sharing a phone number for Joe Bloggs might be Joe themselves or might be someone attempting to doxx Joe). Thryduulf (talk) 11:28, 28 October 2026 (UTC)
And to add to both of those, there are also people who think that the talk pages are for contacting an article subject. Those people tend to leave contact information. On pages dedicated to government agencies, they tend to leave... much more than just contact information. In solidarity, asilvering (talk) 17:16, 28 October 2026 (UTC)
Hello! I'm not an administrator, but I do enjoy reverting vandalism. Is there some way with which I can apply to access the vandalism detections without running for admin? I'm not interested in seeing any of the personal info stuff, obviously. GrinningIodize (you just lost the game) (talk) 17:21, 28 October 2026 (UTC)
This appears to be an industrialized doxxing threat from the Anti Defamation League. Is there a way to formally ask the WMF to request clarification on what exactly they are doing?
What exactly is the concern here? They are allowed to do this. There's nothing illegal, People do the same thing manually when gathering evidence for SPI or ArbCom. The tools that let people track editors are built into mediawiki. It's the user contributions and page history buttons. Packaging that information up into something that highlights shared pages, or related contributions, or similar content of edits is not objectionable and in fact would be a license violation to restrict. What part of CC-BY-SA or GFDL would let us restrict a reuser from using a users contributions to pull out patterns of purported bad actors? --~2026-51667-44 (talk) 07:51, 29 October 2026 (UTC)
If I remember correctly, you have to sign a disclaimer when creating an account consenting to it(It's been a while since I created my account so I could be wrong here), but the ADL aren't requiring that people consent, which is illegal at least in Australia. This is almost certainly a matter for the lawyers because they are breaking Australian law at the very least, and many Wikipedia editors are from Australia. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 08:06, 29 October 2026 (UTC)
Something not being illegal doesn't mean it's not wrong or immoral. It's pretty clear that what they're doing, or planning to do, is POV-pushing via intimidation. sapphaline (talk) 08:58, 29 October 2026 (UTC)
Also, per my post above, it is illegal in at least one jurisdiction. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 08:59, 29 October 2026 (UTC)
It is not illegal to analyse someone's wikipedia contributions. In solidarity, asilvering (talk) 09:02, 29 October 2026 (UTC)
Seemed to me like they were implying that they were stalking Wikipedia editors. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 09:03, 29 October 2026 (UTC)
I may open a discussion at RSN about this per the precedent established with the Heritage Foundation. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 08:09, 29 October 2026 (UTC)
It sounds to me less like they are making a doxxing threat and more like they are announcing that they have been cyberstalking us. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 08:16, 29 October 2026 (UTC)
Just going to link my comment from RSN here - Disturbing if true, but considering the source provided is seemingly an open white nationalist I'm not so sure this should be taken at face value. TheKip(contribs) 11:04, 29 October 2026 (UTC)
Also going to point out here that it's highly suspicious that they're in synagogue attire in a synagogue for a press release and that may be a sign of an antisemitic nutjob using AI to back up their own claims. ғѳmɑɭʱɑυե(Any pronouns)ᵀᵃˡᵏ 11:08, 29 October 2026 (UTC)
Wikimedia Foundation Bulletin 2026 Issue 20
Here is a quick overview of highlights from the Wikimedia Foundation since our last issue on October 9. Please help translate.
Mobile users can now edit with visual editors
Highlights
Community Wishlist: The process for this year’s Community Wishlist has been published, incorporating community feedback. The wish submission process will end on November 8. The triage is expected to be completed by late November. Votes for wishes will start in January.
Behind the scenes: What happened on 25 August as hundreds of edits were made to Dolly Parton's article on English and German Wikipedia – and why code stewardship and the Service Catalog matter.
The new Image Carousel treatment experience that will be tested
Identifying LLM edits easily: LLM Paste Check is now available on all Wikipedias. The feature will notify editors using the visual editor when they paste text that is likely to have initially been copied from one of five external generative AI chatbots. Edits will also be tagged so that patrollers can review them more closely.
The Future of Wikimedia Hackathon:A proposal to hold the Wikimedia Hackathon every three years, with regional hackathons in between has been shared. It explores making the event more accessible to technical communities in different regions. Share your feedback on the proposal’s talk page before November 6.
Re-testing Image Carousel on readers: Starting November 20, a test for Image Carousel will run for logged-out readers. Readers will browse community-uploaded images, selected by editors as relevant to specific articles. It will measure the impact of incorporating some community-requested features on logged-out reader retention.
Changes to Watchlist view: Moderator Tools will be removing the list view of the Watchlist and defaulting everyone to the changelog view. By defaulting to the changelog view, we are simplifying the codebase and avoiding the likelihood of missing bugs.
Wikifunctions quarterly planning: For October–December 2026, Wikifunctions will focus on two main areas: working with pilot communities towards bringing abstract articles into their Wikipedias, and making it easier to create and edit articles on Abstract Wikipedia.
Suggestion Mode: To encourage newcomers to publish their first suggestion when using Suggestion Mode, implementation of the publish prompt on mobile has been completed.
Onboarding newcomers: To encourage new editors to make their first edit, the early onboarding A/B test went live.
Tech News: The latest highlights from Tech News weeks 42 and 43 include CodeMirror syntax highlighting was enabled by default for all logged out and newly registered users on the English Wikipedia. See also the 54 community-submitted tasks that were resolved over the last two weeks.
Open geospatial dataset now released: Wikimedia Enterprise has released an open geospatial dataset containing 17 million OpenStreetMap elements linked to Wikidata, Wikipedia, and Wikivoyage, as Parquet and GeoParquet files on Hugging Face and Kaggle.
Better bot detection: There is a new bot detection system for traffic to the Wikimedia wikis. There might be sudden changes to visitor statistics starting on 26 October and going back to 20 June. This is because we will now be better at finding automated traffic which is trying to hide that it is coming from bots.
The Wikipedia Library: Datawrapper is now available in The Wikipedia Library. This is a data visualisation platform to create and publish responsive charts, maps, and tables. If you're a contributor who qualifies for TWL, please feel free to apply for access and make use of this tool.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. If you have feedback or suggestions about the bulletin, let us know at foundationbulletin@wikimedia.org. For questions about the Wikimedia Foundation's work, contact us!
Please for the love of all that is holy, can we either revamp these to require some degree of human oversight in terms of suggestions, or just remove them entirely? My experience both with peeking at them briefly as a newbie myself and reviewing edits made by others is that they give vague and unhelpful suggestions on articles that need major improvements, so we get these new editors with no understanding of the subject making equally unhelpful (and sometimes nonsensical) changes that other editors then have to review and usually revert. It's creating extra work without actually improving the articles. It would be one thing if the tool was actually capable of identifying truly minor edits needed, like spelling and grammar, but that doesn't seem to be the case. We'd be better off leaving newbies to look around on their own and make edits where they feel they adequately understand both the subject and the changes that are needed, rather than trying to guess what some automation has identified. ChompyTheGogoat (talk) 02:31, 25 August 2026 (UTC)
I'll just dump here what I wrote on my user page a while ago:
"I started editing by going through "Newcomer Tasks". After three days and a handful of edits, I have given up. The vast majority of the "Newcomer Tasks" I was shown were completely unsuited for actual newcomers. I mostly looked at tasks in the history topic. Most of them consist of being asked to improve very poor articles on very obscure topics. In many cases, there seem to be only few books or articles covering the article topic, and they tend to only be available in specialized libraries.
I do not know how these "Newcomer Tasks" are chosen. Based on what I've seen, most of the articles seem to have what I found to be called "maintenance templates". I suspect that these articles are automatically assigned to newcomers based on these templates.
That is a very poor way of introducing newcomers to editing Wikipedia. It feels more like being given the odious tasks that nobody else wants to perform, than tasks tailored to the needs and skills of newcomers. It feels like starting an internship and being given the tasks of making coffee and cleaning up behind the staff.
I expect those "Newcomer Tasks" to drive away a lot of people who might have gone on to become valuable contributors if they hadn't been turned off right at the start. While that isn't the case for me, it seems that I will have to find my own way on Wikipedia." Long is the way (talk) 13:44, 26 August 2026 (UTC)
At least those (IRL) tasks are actually easy to understand, just tedious. These are more like being asked to tidy up and walking into a building actively on fire. The ones I've seen newbies attempting to "fix" lately didn't have maintenance templates that I recall, so I really have no idea how they're being suggested. They suddenly started popping up on a group of related articles that have received attention recently. ChompyTheGogoat (talk) 17:12, 26 August 2026 (UTC)
Nope, no template. The latest was a "revise tone" with the summary "Removed bias and slang", when it fact the only substantial change was a misinterpretation based on lack of knowledge of the subject matter. There was no slang of any kind. ChompyTheGogoat (talk) 17:46, 26 August 2026 (UTC)
Before I settled on the History topic area I also looked at tasks in the Philosophy and Religion area and the Computer (it's been a while, I'm not sure if that was the title) area. In the Philosophy and Religion area, most articles that showed up were about random churches, religious colleges and religious schools in the US. And if that's not bad enough, every time I did a quick search for reliable sources (I won't do a thorough search for an article about a random church that interests me not one jot) came up empty. So what should I do? Nominate article after article for deletion as a newcomer when the author couldn't be bothered to provide proper sources for their edits and someone else couldn't be bothered to do more than tag it? And in the Computer area most articles were about random software and tagged for promotional language. Again, a quick search for proper sources usually came up empty. Once you've wasted a few hours like that it's hard not to come to the conclusion that Newcomer Tasks (if not Wikipedia in its entirety) are thoroughly broken. Long is the way (talk) 18:21, 26 August 2026 (UTC)
I think I was looking at Science - which is incredibly broad, with no way to narrow down my actual interests - and my "1-2 minute copyedit" tasks needed a full top to bottom rewrite (and probably sourcing too). I literally didn't know where to start. Instead I just dabbled with very minor fixes that I stumbled across during my normal reading, or occasionally when someone else mentioned it at Teahouse and didn't know how to do it themselves. Honestly, I think basing it on templates would be better than how it currently is. Even moreso if there was a specific "newcomer level" that could be appended to indicate that it's an easy fix for someone who's still learning - based on actual human judgement - leaving the more complex issues out of the newcomer database. Of course most experienced editors would just fix something that simple, but there could be an active choice to leave it in if it doesn't interfere with the overall reader experience. ChompyTheGogoat (talk) 19:22, 26 August 2026 (UTC)
The lack of filter options is a major drag. I found some stuff to do via WP:Backlog which seems to be entirely based on templates, but at least allows for (some) filtering. Long is the way (talk) 20:35, 26 August 2026 (UTC)
Thank you for taking the time to describe your experiences. I work with the Growth team, which developed newcomer tasks, so I wanted to let you know that I'm following along and thinking about all of the feedback shared in this thread.
New editors make mistakes, and that's true whether they arrive through Suggested Edits or on their own; our goal is to make those early mistakes smaller and easier to learn from, and we know we don't always succeed. Suggested Edits clearly aren't the right path for everyone, but in multiple controlled experiments they've increased the share of newcomers who make a first edit and who are still editing weeks later (2020 analysis, 2021 analysis, 2025 analysis), so many new account holders do find them valuable.
Two current efforts speak directly to what you've described. Newer tasks like Revise Tone are far more in-context than the broad "copyedit this article" tasks you encountered: they point to specific sentences rather than leaving a newcomer staring at an article that needs a rewrite. ChompyTheGogoat, since your recent example was a Revise Tone edit gone wrong, I'm curious if you've looked at other Revise Tone edits? Although newcomers are still making some mistakes, it seems like this task is helping provide enough structure to support newer editors, while still teaching more valuable skills than a super simple task like Add a Link.
And our Early onboarding / Home experiment is testing whether newcomers do better when they can choose specific interests instead of overly broad topics like "Science", which is exactly the gap several of you have identified. In early testing, this surfaces far more specific suggestions and lets people find the niche topics they actually know something about. Does that sound promising?
Finally, as @Johannnes89 notes, much of this is tunable locally via Community Configuration (which tasks are enabled, which templates feed them).
And if you have further ideas for how the Growth team can better support new editors, I'm always eager to hear feedback and ideas at Wikipedia talk:Growth Team features. - KStoller-WMF (talk) 20:54, 26 August 2026 (UTC)
Like I said, there needs to be actual human oversight for me to consider it viable - not problematic automation, and absolutely not this LLM suggestion crap. We spend far too much of our time fighting LLM content and in no way shape or form do we need it further misleading new editors. The problem isn't just the edits they make using such a tool, but what they would learn from it and apply in the future. And on that note, just the fact that newcomers are more likely to keep editing is not a very useful metric on its own - the edits themselves need to be beneficial. Quality over quantity. How many of the newcomer task edits are actually reviewed by more experienced editors, and what's the reversion rate on them compared to non-suggested newbie edits? How many of those editors continue to be productive over months or years, not just weeks? The automation we need is education - a walkthrough for new editors that covers the basics of editing; both the technical how-to aspect and an overview of the four pillars plus the most crucial guidelines. WP:NOTABILITY, WP:COI, and WP:NOLLM come to mind as the most obvious "read before editing" candidates (with checkboxes for the latter two affirming whether or not they have a COI to disclose up front, and that they agree to not insert LLM content). Actually teach people what they should be doing instead of just tossing them in the deep end and saying "here, change something and wait to see whether you get corrected or not". WikiEdu has been highly successful, right? There's no reason we can't package up the basics for all new editors who don't have time or access to such programs. Add an FAQ in too, and links to various sources for additional help.And as long as I'm ranting - better navigational structure. A site index. If I'm wondering "is there a guideline about this" or "where should I report such and such problem" I should be able to scan a list for anything that sounds relevant, instead of attempting to dig through namespace filtered search results - and newbies may not even know about namespaces yet. Once again, more often than not it comes down to "screw up and get corrected", which is a valid learning method but shouldn't be the primary one, because it gets extremely discouraging. Far better to set people up to succeed. ChompyTheGogoat (talk) 21:20, 26 August 2026 (UTC)
You raise a fair point about quality over quantity, and it's one the team shares. All of the Growth team's experiments account for reverts: when we report that Suggested Edits increase activation and retention, we're counting only "constructive" activation and constructive edits, meaning edits that were not reverted. A newcomer whose changes get reverted isn't counted as a success in that data (definitions in our data glossary). If it would be useful, we can also pull recent English Wikipedia data comparing revert rates on Newcomer Task edits vs. other newcomer edits; just say the word.
I've also filed phab:T436196 asking Movement Communications to share more about newcomer metrics as a whole, because I suspect some of the current frustration may relate to the recent increase in new accounts and new editors. More newcomers means more newcomer mistakes reaching patrollers, even if per-editor quality hasn't changed. Does that match what you're seeing?
On education: this is an active area of work. Together with the Community Development team, we're developing short micro-learning videos based on the Wikimedia Core Curriculum, to help new contributors understand the basics and build confidence before and while they edit. That said, no single onboarding path works for everyone: some people want to read the guidelines first, some learn best from a video walkthrough, and some only absorb things by trying a small edit and getting feedback. If we want an encyclopedia written by a broad, representative group of editors, and one that stays as neutral as possible, we need to support several ways in rather than optimizing for just one type of potential editor.
Where I fully agree with you is that we can do more to set new editors up to succeed, and your navigation ideas are a good example. What would a site index that doesn't overwhelm a newcomer look like to you? Namespaces alone are a bizarre concept for most newcomers to grasp, and we do very little to explain them. As always there's so much room for improvement and limited capacity to "make it so" but I'm committed to doing the best I can to improve onboarding for newcomers on the wikis. Thanks - KStoller-WMF (talk) 00:16, 27 August 2026 (UTC)
Yes, I would like to see the comparison stats. I'm particularly interested in which ones have actually been reviewed and confirmed to be an improvement vs just not noticed, but I realize that's harder to prove. I'm aware that new editors make lots of mistakes, but my personal experience has been that nearly 100% of those flagged as newcomer tasks are at best useless, if they don't actually make things worse, vs more of a dice roll for normal newbie edits. What exactly are the existing criteria for them to be suggested anyway?As far as the education side, I'm someone who prefers text learning over videos, so I'm aware that multiple approaches are needed. What I'm suggesting here is just a very brief intro - a popup (with option to skip) with a few slides mentioning the absolute basics and linking to additional learning resources. <2 minutes to get through. I would hope anyone who wants to edit Wikipedia could handle that amount of text, and the COI/LLM agreements are universal. As mentioned elsewhere, the situations we want to avoid the most are the novice good faith editors who are truly WP:HERE and end up with significant reversions purely because they're unaware. We had a case at WP:AINB recently where a new editor had made substantial LLM changes across numerous articles before anyone noticed and called it out. They were very apologetic and actively participated to help with the cleanup. Those are editors with real potential that we don't want to discourage. And removing plausible deniability would streamline disciplinary actions on other cases as well.For navigation, at minimum we should have top level links in the main menu to WP:List of policies, WP:List of guidelines, WP:Manual of Style, and WP:Noticeboards. Maybe WP:Template index too. I'd also recommend considering a customizable shortcuts section that logged in editors can add any pages they want to reach quickly to; internal bookmarks. And personally I dislike the current structure of internal navboxes such as Template:Wikipedia policies and guidelines - in theory if I'm already on the right overall section I can jump around from there, but my brain has a tendency to skip over them because they feel disorganized, and it's worse the busier they get, like with that example. I think stylistic changes could help with that - maybe color coding, collapsible sections, and some kind of change to the layout of the lists themselves within the cells? It's not something I've given much consideration to, but could be workshopped here at VP. And for the sake of being thorough, there could also be one site directory page linked in the footer with a complete list of all the main internal pages in WP space. Obviously It can't be 100% comprehensive, what with all the subpages and minor pages that are frequently created or deleted, but primary perennial ones. Other projects could implement these ideas too - if I want to go edit on one I'm unfamiliar with it would be helpful to know I can go through the menu to find their own policies and guidelines to ensure I'm in compliance with any standards that are different from here. It's especially difficult to try to track such things down via searches if you're dealing with foreign languages (I swapped out a few images across several foreign wikis the other day to avoid breaking pages via changes made at Commons).I'm probably well over my allotted time here, and it's only tangentially related, but one other idea I had recently was some area for more collaborative work on article creation. Not just the brief feedback from reviewers or general "how to use Wikipedia" questions for mentors, but a longer term partnership aimed at getting articles completed and published together. I'm sure newbies would find it the most useful, but I can also foresee situations where people need a specific type of help - for example, one person might be a subject matter expert while the other can help with translation. It could potentially improve AfC rates as well as the initial quality of articles that are directly published in "notable but needs work" condition. ChompyTheGogoat (talk) 05:11, 27 August 2026 (UTC)
Example pop-up for the "Find references" task
What I'm suggesting here is just a very brief intro - a popup (with option to skip) with a few slides mentioning the absolute basics – that's exactly what each newcomer task offers? Johannnes89 (talk) 05:47, 27 August 2026 (UTC)
@ChompyTheGogoat - Thanks, I appreciate the additional thoughts on onboarding, navigation, and ways to better support newer editors! I’ve shared the Newcomer Task comparison stats in my response here. KStoller-WMF (talk) 21:42, 28 August 2026 (UTC)
Not for tasks. A "how to edit Wikipedia" the very first time someone goes to edit. ChompyTheGogoat (talk) 08:07, 27 August 2026 (UTC)
Could you reduce "how to edit Wikipedia" to a handful of sentences? In my experience, "how to" depends a lot on the context, and what you're trying to accomplish. How to fix poop vandalism is a completely different skillset from how to add a new paragraph. WhatamIdoing (talk) 17:35, 28 August 2026 (UTC)
Of course - I just mean the very basics that would be most useful to good faith editors with zero experience. Brief references to things like WP: NOTABILITY, WP: RELIABLE SOURCES, WP:NPOV, and WP:MOS as well as the aforementioned WP:COI and WP:NOLLM, with links to all of these places as well as additional resources like WP:TEAHOUSE and WP:HELPDESK. We can't stop vandals from being vandals, and we can't fit all of the educational material into a single popup, but we can inform people that these things exist and help them find them, to hopefully prevent some of the most common genuine mistakes. I couldn't begin to count the number of new editors who come to Teahouse asking about a reversion, warning template, etc based on guidelines that they had no clue even exist, because how would they? Even the welcome templates are only dropped after they make an edit, see the notification, and go read it. We should be offering these resources upon account creation/first attempt to edit to be proactive instead of reactive. We could also include a mention of reversions and why they're a part of the learning experience (even for seasoned editors), not automatically criticism, to help people feel less offended by it. ChompyTheGogoat (talk) 03:35, 29 August 2026 (UTC)
Most newcomers don't try to start an article, so why should they care about our notability rules? Similarly, MOS violations are usually easy enough for editors to fix, and it's thousands of small rules, most of which are either automatic (basic grammar) or irrelevant (e.g., the name of a gene should be italicized, which 99.9% of newbies will never need to know). I wouldn't bother with that. But RS and NPOV and COI and NOLLM all sound like reasonable things for us to educate people about. WhatamIdoing (talk) 04:13, 29 August 2026 (UTC)
I think the definition of "most" is debatable, but certainly so is the specific content that should be included. I'm just trying to get the overall concept across. Which mistakes are good faith new editors most likely to make in their first handful of edits, and what can we offer them that would be the most useful to help avoid those? Collecting a pool of early edits that have been selected for good faith attempts at improvement - filtering out vandalism etc - would help us establish specific targets, and there would probably be some adjustments as we see the results. ChompyTheGogoat (talk) 04:21, 29 August 2026 (UTC)
The last time I saw the numbers, which was some years ago, about 25% of newcomers tried to start and article. Therefore, 75% of newcomers didn't. 75% is "most" under all mathematically sound definitions.
Teahouse folks probably have some good ideas about which problems they see most often. WhatamIdoing (talk) 04:31, 29 August 2026 (UTC)
@WhatamIdoing: 'Most' is your subjective perception of the math. In real terms, in an official quality control project in which you don't participate, 25% is massive. 25% of newcomers tried to start and article' was provided by Kersin Stoller herself, and the statistics to day are worse. The WMF was presented with a community project several ties and as recently again March this year. They are working on a project led by the language team but it will mot have any impact on the quality of the hundreds of new articles that are submitted daily to the English Wikipedia.The community's project could be rolled out in a couple of months and would stop all his nonsense dead in its tracks.Kudpung กุดผึ้ง (talk) 06:48, 2 October 2026 (UTC)
25% can be massive in absolute terms and still not be "most". If 25% of new accounts create an article, that's around 100,000 newbies creating an article each year, which is a lot of pages. But even though that's a lot of articles, it's still true that 300,000 newbies didn't try to create a page. For every one newbie (or alleged newbie, since some of those are experienced undisclosed paid scammers) who tried to create an article, three others didn't.
Therefore "most" new editors don't create articles, and (relevant to the context, which was a proposal that all newbies get "brief" education on at least eight separate pages, some of which are extremely long) therefore "most" newbies don't need to be forced to read the rules about whether and how they can create an article before they make the non-article-creating contribution that they actually wanted to make, such as fixing a typo or reverting vandalism, etc. IMO there is no need for newcomers to be forced to read about how to do something that they don't want to do. This is, as indicated, merely my personal opinion, and you are, of course, always entitled to hold a different opinion. WhatamIdoing (talk) 19:23, 2 October 2026 (UTC)
Please read my post again for context. Let's not split hairs over semantics - I'm agreeing with you (for once) - 'most' new editors do not want to create an article as their first contribution but that is a very narrow 'most'. 25% (now actually 27.9%) do, and that is a massive number of articles arriving in the New Pages Feed every day, but as you are not a New Page Reviewer, I can understand your perspective of the math being different. Kudpung กุดผึ้ง (talk) 06:20, 3 October 2026 (UTC)
Note: The AFC is heavily backlogged, and most are either AI slop or AI slop mixed with COI. Or there are other articles where people misunderstand policy. The drive in August worked, but immediately after it is on track to go back to pre-drive levels. 16dvnk (talk) 10:50, 3 October 2026 (UTC)
Learning by doing, especially learning from mistakes and feedback, is very effective when the experience is not demoralizing. The challenge is to keep this in balance. And getting corrected, or reverted, is unavoidable.
Newcomer tasks are visible and easy to categorize. This permits testing, tracking, improvement. It can also promote confirmation bias and a (possibly false) sense among experienced editors that newcomer tasks are especially error-producing. Newcomers who get "bitten" for completing a structured learning activity understandably feel let down. Even if the net success rate of these tasks is better it is for newbies left to their own devices the experience can be frustrating.
Related to (1) is figuring out the optimal way to introduce our myriad policies, guidelines, practices, and jargon. Presenting too much "required reading" up front is likely to discourage some newcomers while others feel set up for failure by not having fundamental principles put in front of them. We should make this information visible and accessible in a variety of ways. There will still be problems. I like policies and guidelines but they have to be applied and interpreted in context.Related to (2), it's funny that you mention WikiEdu. My sense is that it is successful but it is a frequent topic of discussion. Some editors feel that it disproportionately generates bad contributions that require cleanup. I haven't seen convincing evidence of that but WikEdu contributions leave a trail and (may) come with a set of expectations, like newcomer tasks, that can increase the frustration. These are good problems to talk about, and it's beneficial to have relatively new editors in these discussions. —Myceteae🍄🟫 (talk) 01:18, 27 August 2026 (UTC)
See my above comment re: 1. My intent for that is just a very brief "Welcome to Wikipedia, here are a few of the most crucial things you should know and places you can go to learn more", not a master's course in editing.I don't have a lot of experience with the outcome of WikiEdu myself - I'm mostly going off what I've seen others say - but what little I have seen usually seems to fall more in the "this is a good start, but here are some more suggestions" where reverting and explaining is helpful, as opposed to "this never should have been suggested in the first place so there's nothing to improve and both of our times were wasted". I definitely could have benefited from more useful suggestions; I was very wary of making any mainspace edits until quite recently and stuck to extremely simple ones (the opposite reaction from LITW). My suspicion - again difficult to prove - is that there's an inverse relationship, where those of us who have a better understanding of Wikipedia from the start and are able to handle the learning curve better look at these tasks and see what's inherently wrong with them, while those who don't know how anything works here assume the suggestions are valid so they just go ahead with changes even when they don't really understand the assignment. ChompyTheGogoat (talk) 05:32, 27 August 2026 (UTC)
The other big differences with WikiEdu is that there are much fewer edits produced by the program, and that when people have pointed out issues with those edits, they actually did make changes to the workflow that seem to have improved the situation. Gnomingstuff (talk) 18:05, 28 August 2026 (UTC)
Yeah, I'm sure it's not perfect, but right now it's our best resource for a more structured program to help support new editors, so I think we should be using what's been learned there to do the same in a more hands off way for others who don't have access to such things. Use what works and discard what doesn't. ChompyTheGogoat (talk) 03:41, 29 August 2026 (UTC)
WikiEdu claims its performance to have led to the contribution of 1,000s of new articles over the years. That may be true, but put in perspective, whether they are fine or require further clean up, it's a drop in the ocean of the massive waves of new articles that have to be processed daily at NPP or AfC. I personally do not see the work of WikiEdu to be in any way superior to that of Editathons that I and many other volunteers have hosted. Kudpung กุดผึ้ง (talk) 09:18, 2 October 2026 (UTC)
I think editing events (e.g., Wikipedia:Art+Feminism) are more likely to create articles, on average, than WikiEdu classes. WikiEdu steers most (but not all) classes away from creating articles. For many editing events, creating new articles is the main goal. I think we need both programs. WhatamIdoing (talk) 19:27, 2 October 2026 (UTC)
@ChompyTheGogoat, what does "actual human oversight" mean to you? From where I'm sitting, the newcomers are human, and so if and how they decide to make the edit constitutes "actual human oversight" of the edit already. But I think you mean something else. WhatamIdoing (talk) 16:08, 27 August 2026 (UTC)
Oversight by someone with more experience (hopefully) of what actually gets added to the task database, to ensure the suggestion itself is valid and easy to comprehend. ChompyTheGogoat (talk) 22:49, 27 August 2026 (UTC)
Are you volunteering to check all the pages that are identified as needing work, to make sure that they actually need that kind of work?
We need about a thousand brand-new accounts to not only register, but also to make their first edit every day. Anything that reduces that number risks Wikipedia's future, because I am going to die. Only a small fraction of them will complete a Newcomer task, but the newbies who do those tasks usually do multiple edits to multiple articles. We probably get about 1,000 to 1,500 newcomer tasks completed per day. Some tasks result in multiple edits to the same article, but we also need a buffer in case a pre-screened article doesn't find an interested editor. I estimate that manually pre-screening would therefore require pre-screening about a thousand articles a day. At a sustained rate of one article per minute, that's 16 hours of work, every single day of the year. It would also have the downside of introducing personal preferences (e.g., this editor wants to minimize links, that editor is unusually sensitive to 'promotional' content...). Do you think it would be worth it, in terms of improving the edits? WhatamIdoing (talk) 17:07, 28 August 2026 (UTC)
If only a small fraction of new edits are made through newcomer tasks then yes, I absolutely agree it would be justified to spend more editor time screening tasks instead of going back and fixing bad edits that result from them. Higher quality suggestions would also result in higher uptake by those of us who avoided them because they're problematic. Even if they actually were based on templates, as has been suggested in this conversation but not substantiated by the evidence, that would mean a human editor read the article and chose to add the template - something that already happens and doesn't add labor. Turns out my gut was right and this is a BS LLM doing BS LLM things. Sure took some tooth pulling to get that admitted. ChompyTheGogoat (talk) 04:15, 29 August 2026 (UTC)
My question isn't whether you think somebody else should prescreen the articles for each task. My question is whether you wanted to do that.
Different tasks have different triggers. The tasks also change over time. For example, the Add a link task used to look (only) for Template:Underlinked; now it is based on a statistical calculation.
Related to this, can we please disable the link suggestions feature in mathematics articles? It consistently causes new editors to add links which are either overlinking or even semantically incorrect (i.e. a different concept with the same name). These editors are often not mathematically advanced enough to understand the difference between a good link and a bad link in a mathematical article. It just ends up creating work for others who have to revert these changes. Elestrophe (talk) 00:05, 28 August 2026 (UTC)
Isn't that one of the newcomer tasks also? Same overall issue. They mean well, but the suggestions just aren't good for newbies with no Wikipedia experience or subject matter knowledge. ChompyTheGogoat (talk) 01:28, 28 August 2026 (UTC)
It is a newcomer task. There was a discussion about this quite recently: Wikipedia:Village pump (proposals)/Archive 231#We need to get rid of the "suggested links" tool. Some tweaks were made and other potential interventions suggested or were already being worked on that might improve the fidelity. There's a lot of discussion there of data indicating that links created via the newcomer task get reverted less often than links inserted by newbies going at it alone. There were some questions about the precision of these figures but nothing that suggested to me that the observation was directionally wrong. —Myceteae🍄🟫 (talk) 01:52, 28 August 2026 (UTC)
That statistic doesn't mean the feature is a good thing. It's not like the existence of the feature prevents new editors from adding links they would have already made, so it's still just creating a bunch of bad links that have to be reverted. Elestrophe (talk) 02:58, 28 August 2026 (UTC)
You're correct that the existence of the tool doesn't prevent manual edits, but the numbers show that it does encourage newbies to make that kind of edit. If nothing else, it educates them that this is the kind of thing that Wikipedia wants to have done. WhatamIdoing (talk) 17:12, 28 August 2026 (UTC)
See my comments below re: comparison between new editors who utilize the tool vs all new editors, which are definitely a mixed bag. ChompyTheGogoat (talk) 07:17, 28 August 2026 (UTC)
@Myceteae Re "links created via the newcomer task get reverted less often than links inserted by newbies going at it alone", is there? I've seen data on add a link vs overall newcomer edits, but not specifically vs non-task link additions. CMD (talk) 04:21, 29 August 2026 (UTC)
If you know a way to identify when an edit adds a link from metadata, then Wikipedia:Request a query should be able to give you the numbers. (Maybe compare all edits with a byte size of +4?) WhatamIdoing (talk) 04:47, 29 August 2026 (UTC)
@Chipmunkdavis As I understand it, the Add a Link structured task is a newcomer task. In the recent VP discussion, there was discussion of the original testing (mw:Growth/Personalized first day/Structured tasks/Add a link/Experiment analysis, December 2021) and other data. Initial testing compared newcomers who had the Add a Link task turned on to those who did not. Further analysis looks at edits with the Newcomer task and Suggested: add links tags in edit summaries. I'm not involved in this work and had not followed this previously. This is my understanding per recent discussions; please correct me if I have gotten something wrong. —Myceteae🍄🟫 (talk) 18:14, 29 August 2026 (UTC)
Yes, there have been a massive number in the last week alone, just from a single user Special:Contributions/Mathworkofpast. You can just take a look at how many of their recent contributions are link additions which have been reverted. Elestrophe (talk) 06:22, 28 August 2026 (UTC)
I count 94 edits to the mainspace, of which a total of 50 were newcomer tasks and a total of 63 were reverted. Specifically, I count 34 reversions of newcomer tasks (68% of newcomer tasks) and 29 reversions of ordinary edits (66% of non-newcomer tasks).
Maybe you want to run some proper calculations, but that doesn't sound like a statistically significant difference to me. Therefore, I think it would be difficult to blame the existence of newcomer tasks for those edits. WhatamIdoing (talk) 17:22, 28 August 2026 (UTC)
The reason all of these edits have not been reverted is because I have not slogged my way that far down the list yet, and because several of the edits have been subsequently buried under a deluge of other edits making cleanup even harder.
This is just one person. Multiply by a thousand and you have an idea of the cleanup burden. Gnomingstuff (talk) 17:37, 28 August 2026 (UTC)
No, the reason all of these edits have not been reverted is because the community did not consider them worth reverting. For example, picking a "revise tone" example from the middle of their contribs, I see this:
Perhaps the greatest Harbor Dynasty was that of Girls' Soccer who won 9 CCS Championships in 14 years → Harbor High School has seen notable athletic success over the years. The Girls' Soccer team won 9 CCS Championships in 14 years
It may not be perfect (e.g. neither version complies with MOS:SPELL9), but I think that rephrasing it to get rid of puffy "greatest Harbor Dynasty" language constitutes an incremental improvement. Maybe you would agree with me.
Remember that you don't have to clean up after a thousand newbies each day all by all yourself. In fact, you don't have to do any of it, unless you actually want to. WhatamIdoing (talk) 20:58, 28 August 2026 (UTC)
No, the reason all of these edits have not been reverted is because the community did not consider them worth reverting.
But you still have to go through every single one to see whether they are or not. Many of them are.
I do not actually "clean up after a thousand newbies every day all by yourself," because there are not enough hours in the day for that. I don't see why I am the one who is being scolded here instead of the people creating the cleanup work. Gnomingstuff (talk) 22:11, 28 August 2026 (UTC)
Why are you assuming that those edits haven't already been checked (and probably checked repeatedly) by the RecentChanges patrollers? WhatamIdoing (talk) 04:15, 29 August 2026 (UTC)
Because they clearly haven’t, or else they would have gotten fixed? Gnomingstuff (talk) 19:15, 30 August 2026 (UTC)
I picked one out randomly from the user's contribs, and I found no need for it to be fixed. Why should I assume that all the others need fixing, or even most of them? It's of course possible to find the one outlier, but it's not generally reasonable to assume that the one you found is an outlier.
I checked another, chosen for being a net negative number of bytes (because I thought a reduction in page size would be less likely to be a whole-page re-write, and I didn't feel like looking at a complex diff). That, too, was a good edit – not perfect, but better than what was there before.
My point isn't that the editor is any good. My point is that you don't have to take on reviewing those edits unless you actually want to. Those edits have almost certainly been reviewed by someone else. That someone else will be less adept at your particular skills (we are all less adept at AI detection than you), but they will have been checked for an ordinary level of reasonableness, and determined not to be obviously bad. As a result, it's IMO not necessary to treat this user's contribs as a significant threat to Wikipedia. Review them if you want, and don't if you don't. WhatamIdoing (talk) 20:00, 30 August 2026 (UTC)
It doesn't indicate that they improve edits at all either. That's exactly the point I was getting at all far as editors who use newcomer tasks at all vs the total sum of new editors, which includes vandals, UPE, SPAs and the whole range of LTA sockers. Most people who come in with any form of bad faith won't bother with the tasks, unless it's purely an attempt to game user rights. ChompyTheGogoat (talk) 03:50, 29 August 2026 (UTC)
This person seems to be a WP:SPA. An unorthodox one, to be sure, but their editing pattern is the same: spam out a bunch of newcomer tasks until Number Goes Up enough that they can do what they're really here for. In this case that's a low-quality draft on their favorite math problem rather than a low-quality draft on their marketing startup, but the pattern is the same. They even all but admit here that they mostly care about getting their edit count high enough to get permissions. Gnomingstuff (talk) 18:11, 28 August 2026 (UTC)
It's once again not clear that the newcomer task creates or promotes the problem as opposed to being a thing that can be used in conjunction with extremely common problematic newbie behavior. There are always newbies who try to juice their numbers so they can gain more tools and start working on their pet projects with fewer restrictions. —Myceteae🍄🟫 (talk) 21:09, 28 August 2026 (UTC)
The difference is that it provides them a frictionless way to very quickly spam out edits they don't care about, and one that directs them to articles that already have problems, drowning out the people who actually do care about and are competent at fixing the problems. Gnomingstuff (talk) 22:13, 28 August 2026 (UTC)
It's my experience that most newcomers actually do care about their edits. They may not be competent (yet), but most of us, including me, weren't competent in our early edits. WhatamIdoing (talk) 04:17, 29 August 2026 (UTC)
@Elestrophe, this one looks like a WP:CIR case to me. I'm not sure they'd be any more or less annoying if Suggested Links didn't exist, honestly. If they don't change their tune in the next couple of days, feel free to ping me about it and I'll get them out of your hair. If there are individual math articles that are getting a disproportionate number of bad links, you can add {{No newcomer task}} to the article to keep them away. In solidarity, asilvering (talk) 21:36, 28 August 2026 (UTC)
If Newcomer Tasks are based on maintenance templates then it's not surprising that they are poor because the maintenance templates are usually too vague and stale to be useful. In theory, they should be supported by talk page discussion which goes into detail but this is rarely done. And the actual talk page suggestions are often left dangling without being closed in a formal way.
There is a project called This week's article for improvement which is going to be featured on the main page soon. The idea is to encourage readers to become new editors. This will provide a good focus for improvement in the workflow for such tasks. I reckon that To do lists should be encouraged to provide a list of actionable tasks but I don't often see them on articles currently. The overall structure and workflow needs work.
I checked the latest one that caused me to start this discussion and the page did not have any template in place, nor do I believe the related ones that started to get on my nerves before that did either. They said in the replies that it is an LLM. ChompyTheGogoat (talk) 09:42, 29 August 2026 (UTC)
There are some overall stats at Special:NewcomerTasksInfo. The Revise Tone tasks seem to be quite a small proportion. Andrew🐉(talk) 09:58, 29 August 2026 (UTC)
Edit conflict - see below. ChompyTheGogoat (talk) 09:58, 29 August 2026 (UTC)
Per Special:NewcomerTasksInfo, the vast majority of all newcomer tasks are link-recommendation. If I'm reading Special:CommunityConfiguration/GrowthSuggestedEdits correctly, I believe that is the "Add a link (Structured task)", which is not defined by templates - only excluded by them. revise-tone is also not mentioned there at all and therefore I assume that one is AI generated as well. For those tasks that are template defined, I'd recommend improving the suggestions by adding a parameter to define the level of work an article needs - maybe a 1-5 scale, with levels 4-5 automatically excluding them from newcomer tasks based on the level of work required, as Template:No newcomer task is meant to (which I've never seen utilized, and I would imagine most editors don't know it exists). Levels 1-3 could correspond to easy, medium, and hard tasks, instead of just assuming that all copyedit is easy. I would also recommend excluding articles with three or more maintenance templates for the same reason. ChompyTheGogoat (talk) 09:58, 29 August 2026 (UTC)
18,000 articles are tagged with {{Promotional}}. How many of those are you personally willing to add a level-of-work parameter to?
That's just one of many templates. I believe that we've only added a requirement for an explanatory parameter in one instance ({{Cleanup}}), and until last month, more than a decade after we "required" it, Category:Cleanup tagged articles without a reason field had hundreds (previously thousands) of articles in it. WhatamIdoing (talk) 16:46, 29 August 2026 (UTC)
Going back to modify existing templates would certainly be a slog, but there's no reason we can't append a new parameter going forward. If we add a flag that would help editors notice and drop it in if they're doing any work on an article with an existing one. ChompyTheGogoat (talk) 05:56, 6 September 2026 (UTC)
You could ask the Twinkle folks if they would build something to support that. WhatamIdoing (talk) 06:09, 6 September 2026 (UTC)
Well, we'd need consensus to update the templates first, and if we don't settle this newcomer task issue there's less point to it. My biggest concern is which tasks are being fed to newbies who expect something simple - advising people who find the article through normal routes of the anticipated workload would be a minor secondary benefit. ChompyTheGogoat (talk) 06:34, 6 September 2026 (UTC)
@ChompyTheGogoat, I've been trying to explain that copy-editing is not "easy" to Growth to no avail for years. I continue to wish that community configuration allowed us to set the difficulty of individual tasks. In solidarity, asilvering (talk) 16:49, 29 August 2026 (UTC)
have also been trying to explain this, as well as the fact that copy-editing skill and Wikipedia familiarity are not the same thing, and training someone to use the Wikipedia UI does nothing to improve their copyediting ability, especially if you are giving them unconditional virtual pats on the back via widget for doing such a good job Gnomingstuff (talk) 21:06, 29 August 2026 (UTC)
Well, it CAN be - I make very minor spelling and grammar corrections all the time, and that's the kind of work I expected to see in the newcomer tasks - not full article rewrites (2 minutes; ha!) IMHO a level 1/"easy" CE task should only require decent English fluency, not a high degree of WP competence. A professional (non-WP) editor (or comparable ability) could maybe do level 2, and level 3 would start getting into more MOS details for newbies who are starting to get the hang of things. It would be a judgement call of course, but it would still help. ChompyTheGogoat (talk) 06:01, 6 September 2026 (UTC)
I wonder if the "2 minutes" estimate is meant to discourage full rewrites/to encourage making one improvement and then moving on. WhatamIdoing (talk) 06:11, 6 September 2026 (UTC)
But which small fix is going to have any measurable improvement on an article that does need a total rewrite? What's the point to me fixing one or two typos when the whole thing is an unsourced disaster? That's precisely why I walked away from them - I literally did not know where to start. I don't have a clue where those estimates come from anyway if CE is indeed template based, because it sure isn't the editors who added it. If we're going to improve the templates, maybe we could have a way to select which specific passage needs work (and indicating the entire article would automatically upgrade the difficulty level). ChompyTheGogoat (talk) 06:40, 6 September 2026 (UTC)
Expanding on that idea, maybe the difficulty level could be calculated by default based on the byte size of the selection, with editors having the option to adjust it as they see fit. That way they would be sorted automatically even if editors don't bother to set it manually. I'm not a programmer so I don't know what would be required on the backend to accomplish that, but it seems like it would be fairly simple. ChompyTheGogoat (talk) 06:44, 6 September 2026 (UTC)
It looks like we do have Template:Copy edit span as well as Template:Copy edit section. I wonder if we might be able to bundle them all into a single template with optional parameters for the sake of simplicity - I've never seen the span one used (and it's displaying the selection in code formatting for me, which is not great in an article body).I know this would need to be workshopped on the actual templates - just spitballing. ChompyTheGogoat (talk) 07:37, 6 September 2026 (UTC)
There is also a practical value in letting a newbie work on a disaster of an article: The odds are higher that if they do anything, they'll make it better. If we invite them to improve an article that is nearly perfect, then the odds are significantly higher that they won't understand what's wrong, or they'll pick the wrong thing to fix. WhatamIdoing (talk) 19:04, 6 September 2026 (UTC)
Not if we're talking CE - find and fix the error. Don't fix things that are correct. If they don't understand the difference that's a WP:CIR issue. Especially if we implement my suggestion to actually flag the specific part that needs work. Tossing disaster articles at them is overwhelming and it's highly likely the part they work on will end up reworked or deleted entirely once the article is actually brought up to snuff (if ever). No one is going to notice there's one less typo when it's still a mess. It might be a statistical improvement if it is correct, but not a meaningful one. (The Revise Tone task that was incorrected by the newbie was then deleted by the patroller who saw it because it was unsourced in the first place and not particularly useful. Neither the LLM that flagged it nor the newbie with no experience realized that.)I believe it was @Gnomingstuff who said their reaction to such a task was to dive headfirst into learning all the relevant guidelines and eventually fix the entire article, but that's obviously not the intended result nor a common outcome. Mine in the same situation was to just leave it and find easier work on my own. Others might give up entirely if they think monumental work like that is what's expected on a regular basis. ChompyTheGogoat (talk) 19:59, 6 September 2026 (UTC)
In my experience this has not happened; the articles just turn into a hundreds-of-edits deep morass that makes reverting a bad edit (of which there are many, with Newcomer Tasks) difficult and tedious. Gnomingstuff (talk) 21:06, 6 September 2026 (UTC)
Which part doesn't happen - the progressive improvements (which I haven't seen either)? It might have been someone else who said they turned the task into a long term project instead. My memory sucks. ChompyTheGogoat (talk) 01:00, 7 September 2026 (UTC)
The progressive improvements.
(It doesn't help that very few people actually remove the tag when they do their changes -- which is completely expected and nonmalicious behavior from a new user, but does mean that the changes don't stop coming and people get increasingly confused at what is tagged.) Gnomingstuff (talk) 15:11, 7 September 2026 (UTC)
The newcomers I've spoken with always expect someone else to double-check their work, and for that checking editor to remove the tag. WhatamIdoing (talk) 21:56, 7 September 2026 (UTC)
It sounds like we need a specific patrol group for any newcomer tasks that are retained. It would be useful to prioritize edits by all new editors, for that matter - are there filters that could pull changes made by non-autoconfirned and non-EC as well? That could be useful work for people who are involved with welcoming/mentorship/etc - sort the bad actors to appropriate noticeboards and offer support to the good faith ones who need help. ChompyTheGogoat (talk) 01:57, 8 September 2026 (UTC)
So I'd recommend such patrollers start with something like this, then expand to the learners group and eventually skim "likely good" edits. Depending on whether they're focused on damage control or outreach they could either look at bad faith filters first, or good faith and newcomer tasks.I checked one at random and found yet another instance of a problem with newcomer tasks: Special:Diff/1373819817 This appears to be a relatively competent new editor making useful contributions who hasn't been reverted yet (with 19 live mainspace edits), but even they failed to comprehend what the "expand" task is meant to be and just did minor CE instead. The edit itself is fine, but it speaks to the larger issue of newcomer tasks not being clear about the objectives. ChompyTheGogoat (talk) 03:52, 8 September 2026 (UTC)
Or they decided that it didn't need expanding, but while they were there, they wanted to make some other changes. Or they decided that they didn't want to expand it. The task isn't your schoolteacher, and you don't flunk if you don't do what you're told. It takes you to an article, makes a suggestion, and lets you do whatever you choose, which might not be what it suggested. WhatamIdoing (talk) 05:52, 8 September 2026 (UTC)
(I didn’t do any of these at the outset though, I just reverted vandalism) Gnomingstuff (talk) 21:07, 6 September 2026 (UTC)
About Not if we're talking CE - find and fix the error. Don't fix things that are correct: Copy editing (which is different from mere proofreading) is not limited to finding and fixing errors. Sometimes what's needed is improvements in clarity, organization, style, wordiness, tone, and so forth. Sometimes you can't actually flag the specific part that needs work because the whole article (or section) needs work. Sure, some people would prefer to fix a single typo and stop. Some people struggle to do even that much. For example, we have many experienced editors, including some admins, who have dyslexia and are happy to leave that part to others, while they get on with the many things they are better at. But others actually do substantial re-writes, and some of us even enjoy the work (e.g., presumably most participants in the Wikipedia:WikiProject Guild of Copy Editors). WhatamIdoing (talk) 21:51, 7 September 2026 (UTC)
And I did say the entire article can be flagged, but again, we should be trying to serve new editors easy tasks. If one particular section or paragraph is problematic flag it so they know what to focus on, with a difficulty rating to filter which editors it gets served to, and potentially even a comment about what needs to be changed. Drive by tagging rarely helps - if someone doesn't want to do the work themselves they should endeavor to make it clear what they think actually needs to happen. You saw the new example I gave below - the editor has no idea what they're supposed to be doing with the task, OR how the "ask your mentor" feature works. AI has no comprehension of the underlying issues and basing tasks on templates that the adding editor never intended to serve up to newbies both fail to grasp the point. It should be seen as training, not a labor source for issues other people skipped over precisely due to the complexity. ChompyTheGogoat (talk) 02:08, 8 September 2026 (UTC)
We actually don't know whether "drive-by tagging" works. It's never been studied. And some of the drive-by tagging is actually quite simple. WhatamIdoing (talk) 03:12, 8 September 2026 (UTC)
I'm not referring to all article flags, but simply inserting a standard template with no additional details on an article with complex or confusing issues. It might be enough to alert readers to potential issues with content but isn't always sufficient to inform other editors about what needs to be addressed - and once again, I don't believe most editors who add them have newcomer tasks in mind. If we're going to utilize them for that purpose there needs to be some thought about how they're implemented. Adding things like selections and difficulty levels would be covered in updated documentation, and editors who are aware of the changes could make an effort to notify others when they see templates being added without them. ChompyTheGogoat (talk) 03:19, 8 September 2026 (UTC)
"Maintenance templates should not be used to "warn the reader" that an article needs improvements or that a Wikipedia editor disagrees with the current state of the article."
Bold in the original. In other words, maintenance tags don't exist to "alert readers". WhatamIdoing (talk) 07:23, 8 September 2026 (UTC)
That sentence includes quite a bit after the bold explaining what purposes they shouldn't be used to warn. The entire purpose of those templates is to alert readers, like you and me, to changes that should be made. CMD (talk) 08:32, 8 September 2026 (UTC)
So the guideline says that they shouldn't be used to warn the reader that an article needs improvements, but you think that the entire purpose is to warn readers that changes should be made? WhatamIdoing (talk) 21:09, 8 September 2026 (UTC)
I think the text you added without disclosing that here is difficult to understand, but the main thing I'm not doing here is trying to force myself into a position where I'm trying to argue that the big orange box with bold for emphasis, and some even with a large exclamation marks, will not alert readers. CMD (talk) 22:51, 8 September 2026 (UTC)
I think it's called the Principle of double effect: We aren't (and shouldn't be) trying to warn the readers, even if it sometimes has that effect.
For years, none of the maintenance templates were displayed on the mobile site. What's changed isn't a desire to warn the readers, but the fact that we now get more editors on the mobile site than we used to.
(If I had to "disclose" every edit I've ever made to a policy or guideline, it'd be impossible to carry on an ordinary conversation. I apologize for not remembering that I edited that guideline a couple of years ago.) WhatamIdoing (talk) 00:27, 9 September 2026 (UTC)
The principle of double effect would be a possible argument for the existence of templates, but it is not reflected by their design. There is even a scale of alertness, from the yellow ones to red. CMD (talk) 00:48, 9 September 2026 (UTC)
Why do you assume that this design is aimed at non-editing readers, and not at editors like us? WhatamIdoing (talk) 02:18, 9 September 2026 (UTC)
For a start it's on the actual page, we hide the normal maintenance categories or put them in the talkpage. More philosophically, we do try to make those categories one and the same. This is a thread about newcomer tasks, after all. CMD (talk) 02:42, 9 September 2026 (UTC)
It's on the actual page ...so that actual editors can see it. WhatamIdoing (talk) 02:45, 9 September 2026 (UTC)
These eyesore banner templates have extremely limited value, mostly serve to bash readers over the head telling them things that were already obvious (e.g. "this section has no footnotes" or "this section is incoherent" or whatever), and the way they have been spammed all over the place for years is one of the biggest examples of Wikipedians shooting ourselves in the foot. Cf. User:Jorge Stolfi/Templates that I sorely miss §"Templates are too discrete" template. –jacobolus(t) 08:30, 9 September 2026 (UTC)
Acceptable disclaimers: ... Temporary cleanup templates, such as {{POV}}, {{original research}} or {{cleanup}}. These point to deficiencies in the article that should be corrected promptly.If they aren't for readers to see, they should be hidden. Lots of other things are. ChompyTheGogoat (talk) 09:36, 8 September 2026 (UTC)
And regardless of whether or not it's their stated purpose, my point was about what they actually accomplish. If it's unclear what needs to be fixed it's less likely to happen, meaning the template stays up longer, meaning more readers see it while editors keep skipping it. ChompyTheGogoat (talk) 09:38, 8 September 2026 (UTC)
If you can come up with a programmatic way to tell which logged-out people are non-editors, then we probably would do that more often. We have already done that for a handful of maintenance templates, e.g., {{orphan}}, which used to be displayed by default and is now only displayed under limited circumstances.
But generally speaking, we can't hide them from "readers" because it's impossible to differentiate between a "non-editing reader" and a reader who would use a temporary account, as well as editors who aren't logged in on every device they use. We want potential editors to be able to see these calls to action. WhatamIdoing (talk) 21:13, 8 September 2026 (UTC)
If they don't want non-editors to see something it's usually only displayed in editing mode, like template errors - and like the new edit suggestions mentioned elsewhere. They generally don't show things strictly related to editing to people who aren't trying to edit. Logged in editors can enable display of such hidden messages if it's something they want to see and potentially work on. These templates are visible exceptions to the disclaimer rule for a reason, and they absolutely have that effect - it's one of the things that made me start wondering about what goes on behind the scenes here, because they started showing up a lot more in the last few years, and I have found them useful in my pre-editing days when an article seemed unusually low quality. It helped me take things with an extra grain of salt. ChompyTheGogoat (talk) 22:00, 8 September 2026 (UTC)
"They" aren't doing this. "We" are. And one of the reasons we do it is to recruit editors. Your experience shows that works occasionally. WhatamIdoing (talk) 00:03, 9 September 2026 (UTC)
You realize this is all completely irrelevant to my original point about templates not telling editors what needs to be fixed, right? In fact, if your argument is that that's the only purpose they're intended to serve then they're doing an even worse job, because as I've stated if the template is vague and no one addresses it then it just continues to sit there as a flag to readers. Improve templates > improve articles > fewer visible templates. ChompyTheGogoat (talk) 14:21, 9 September 2026 (UTC)
Yes, I too have problems with newcomer tasks. I think that, at the very least, once you become a confirmed (or whatever you call a 500 edits, 3 months user) user you should have them turned off, or have the option to turn them off. -I sometimes eat bananas, and you can talk to me here: (talk) 22:01, 11 September 2026 (UTC)
500 edits + 30 days is called "extended confirmed". The links task turns off at 150 edits, even if it's still your first day and even if none of your first 150 edits did any newcomer tasks or added any links. WhatamIdoing (talk) 01:22, 12 September 2026 (UTC)
The problem is that my experience has been that the newcomer tasks are not by any stretch of the imagination "an easy way to learn how to make an edit", but an easy way to waste hours looking into an issue (real or imagined) and ending up not making an edit or learning anything other than to avoid newcomer tasks. Yes there should be newcomer tasks. But they need to be very different from the ones I encountered. Long is the way (talk) 20:30, 26 August 2026 (UTC)
They sound good in theory, but they reality is that they aren't good for helping people learn nor improving articles. They're confusing and waste editor time, especially when we have to clean up the "improvements that aren't". Like I said, they either need to be fully overhauled so they DO help, or removed to stop creating more problems. ChompyTheGogoat (talk) 20:57, 26 August 2026 (UTC)
Fully agree with the above and other comments here. As they are set up, they aren't helping anyone. Johnbod (talk) 02:53, 27 August 2026 (UTC)
I think that most of them are helpful. But we don't have to wonder about which one of us is correct; we could set up the mw:ORES review tool and get some editors (all of us in this discussion?) to manually do a blind comparison of a random collection of newcomer tasks vs unprompted tasks by new editors. WhatamIdoing (talk) 16:12, 27 August 2026 (UTC)
I'm not familiar with the tool. How exactly does it evaluate "overall quality"? I do believe that most newcomer task edits are good faith non-vandalism attempts to improve, but often not helpful because of the tool giving inappropriate suggestions and new users not having the experience to recognize that (or know what actually needs to be fixed). New editors who are vandals, UPE, etc wouldn't be likely to use the tool at all, so naturally more of those bad faith edits would be found without it. We'd need a narrower pool of test cases to avoid that bias. ChompyTheGogoat (talk) 21:26, 27 August 2026 (UTC)
As a matter of fact, that could easily be skewing the existing metrics - purely the fact that most editors who'd use it are indeed good faith and WP:HERE. Maybe an examination of edits made with and without the tool by the editors who do utilize it? ChompyTheGogoat (talk) 21:28, 27 August 2026 (UTC)
That tool works manually. It shows you a diff, and asks you what you think of it.
So imagine, e.g., that we set up this tool to show (without showing the Special:Tags) 10 edits from newcomer tasks and 10 similar-ish edits from equally inexperienced newbies that aren't from newcomer tasks. Then you rate them based on whether it's (in your best editorial judgement) a good edit or a bad one. WhatamIdoing (talk) 16:42, 28 August 2026 (UTC)
That's not what it sounds like to me. My read is that it automatically flags edits for patrol based on this internal automated scoring system. Is there some other function of it I'm missing? ChompyTheGogoat (talk) 04:08, 29 August 2026 (UTC)
Before ORES could produce those automated assessments (ORES is what color-codes watchlist items for "Likely have problems" and such), we had to feed it the original data. I guess the page I linked you to is more about the end result than about the tool for collecting the data, so that wasn't a very helpful link; sorry. WhatamIdoing (talk) 04:23, 29 August 2026 (UTC)
So for a specific use like this editors determine which tasks are part of the pool to be evaluated, then it crunches the numbers for us - not just scanning and feeding us what it runs across in the wild based on given params? ChompyTheGogoat (talk) 04:35, 29 August 2026 (UTC)
Well, more to the point, if we could resurrect the data-collection software that was used back then, we could feed it any set of diffs we wanted, editors could score them however they wanted, and we could crunch the numbers ourselves. WhatamIdoing (talk) 04:48, 29 August 2026 (UTC)
Ok, so the current implementation of it doesn't allow us to designate a specific pool for evaluation? I thought that's what you were saying in your initial comment. ChompyTheGogoat (talk) 05:06, 29 August 2026 (UTC)
I find it absolutely enraging that WMF would drop an AI feature onto English-WP as some sort of a beta test because somebody got a wack idea, a manager approved it, and engineers made work and developed it. I ran into a driveby "Newcomer Task: Suggested: Revise Tone" editor on a page I was actively working on that was flagged with a CONSTRUCTION template just yesterday. That is how I discovered the feature. That is how little regard that WMF paid staff has for the community and for the decentralized community decision-making process that has served us well for two decades. If it were up to the tech-worshiping, unforeseen-consequences-damning preferences of WMF, Wikipedia would by now approximate Grokipedia-With-Junkets. Something like this should NOT be unilaterally implemented by the engineers without community discussion. And I don't mean displaying notice of the forthcoming change in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard," either. Carrite (talk) 16:27, 28 August 2026 (UTC)
Just a note on this, the feature as a whole is several years old. Which means there have been several years for stuff like Special:Contributions/Aritonoko to accumulate. Gnomingstuff (talk) 18:17, 28 August 2026 (UTC)
People who earn a checkuser block aren't really evidence of a problem in editing software. WhatamIdoing (talk) 20:45, 28 August 2026 (UTC)
The problem is that they were given a tool that encouraged them to spam out over 100 edits at a rate of roughly 1 every 3 minutes. No one fixed them for over two years, despite their very much needing fixing. Gnomingstuff (talk) 21:07, 29 August 2026 (UTC)
The task itself is fairly simple: it highlights a paragraph containing language that the model has identified as commonly being reverted. In that respect, it is not all that different from the machine learning models that have been used for years to flag potentially problematic edits in Recent Changes. Revise Tone is also Community Configurable, so communities retain control over whether they want to offer the task. Any administrator can disable it if there is consensus.
Of course, I hope communities will choose to keep it enabled. Revise Tone, along with the other Newcomer Tasks, is intended to give people who are new to editing a relatively approachable way to make their first contributions. We know that getting started with Wikipedia editing can be difficult, and we need to provide newcomers with accessible ways to take that first step if we want to support the long-term sustainability of the projects. KStoller-WMF (talk) 22:35, 28 August 2026 (UTC)
Community members were involved does not equate to consensus. This comes across (yet again) as "We're going to shove LLM down your throat, and if people protest loudly enough we'll consider removing it after the fact." And you wonder why editors are hostile to WMF involvement. ChompyTheGogoat (talk) 04:23, 29 August 2026 (UTC)
I have asked for Newcomer Tasks to be disabled for several months now. I have done an audit on Newcomer Task quality -- the amount of good ones is dismally low. That's still true. I could do another audit, but I don't even know if that would help, because I have otherwise presented every piece of evidence I can possibly think of. There is no concrete evidence that anyone actually cares. (defined by anything actually being done about it beyond "we're listening") The situation is especially perverse for a number of reasons:
The articles hit by Newcomer Tasks are often articles that people tagged a long time ago. I assume that when they did so, their intent was not to make the articles worse, but that's what has happened.
The justification that we get, over and over, for why these are still around despite being a demonstrable net negative is the sunk-cost fallacy and how so much work has been put in. I don't know how to be any more polite here, but I don't care. If someone comes along and bashes a hole in my roof, I don't care how hard they worked to bash the hole, I care that my house is now being ruined by rain.
The other justification is that "well they're not being reverted so they must be good." The reason so many of them have not been reverted is because A) the firehose is spewing them out too quickly for "reverting" to even happen (in a way that puts the "reverted" tag on), and B) there are so many of them that everyone doing cleanup is swamped. The last time I brought this up I said I had over 100 tabs open with cleanup work. Now it's over 200. Just how fast am I expected to work to be able to make Number Go Down to a point that makes any impression whatsoever on the people who want see Number Go Up?
I don't remember anyone giving a sunk-cost justification.
Looking at Special:RecentChanges right now, I see just under 1,000 mainspace edits from newcomers (1–10 edits) in the last ~6 hours. About 11.5% of them are Newcomer tasks. 14% of them are already reverted. But: Only 3.7% of the Newcomer tasks are already reverted, whereas 16.2% of the non-Newcomer task edits have already been reverted. That's more than a fourfold difference. Newcomer task edits are only 23% as likely to get reverted as non-Newcomer task edits.
It might be that the daily ~4,000 mainspace edits from newcomers is more than our current Wikipedia:Recent changes patrol can handle. But it seems unlikely to me that the community is preferentially ignoring the Newcomer task edits, and if newbies using the Newcomer tasks are "only" as bad at editing as the rest of us were when we started, it would take a very significant level of ignoring edits to produce that big of a difference in the reversion rates. I therefore conclude that Newcomer task edits actually don't need to be reverted as often as other edits from newbies. WhatamIdoing (talk) 20:43, 28 August 2026 (UTC)
Could you please respond to my numerous comments referring to the difference in editors who actually utilize the tool at all before you continue to rely on this logic? ChompyTheGogoat (talk) 04:32, 29 August 2026 (UTC)
Sure: As has been pointed out repeatedly by multiple people in this discussion, Wikipedia:Long-term abuse socks, poop vandals, and other abusive actors might not look at Special:Homepage at all.
And as has also been pointed out, when you compare randomly assigned Group A, with the opportunity to complete newcomer tasks, against Group B, without that opportunity, and you see that Group A does the same or better than Group B on approximately every metric ever checked during the last ~seven years, even though most of the members in Group A never completed a task, then it's fair to assume that "actually using the tool at all" isn't necessary to get a benefit from it. The editors in Group A who use the tool are likely different from the editors in Group A who see the tasks and decide to edit independently (but who may have been influenced by the information they saw), and both of those subgroups are different from the editors in Group A who didn't look at the homepage at all, but there is no reason at all to assume that the randomly assigned members of Group A have a different number of abusive editors than the randomly assigned members of Group B, none of whom had the opportunity to see the page. And since Group A, including its voluntary non-users and its fair share of abusive editors, did much better than Group B, it's reasonable to think that the tool actually improves behavior overall. WhatamIdoing (talk) 05:02, 29 August 2026 (UTC)
Do you have a link to that information? ChompyTheGogoat (talk) 05:04, 29 August 2026 (UTC)
The Revise Tone experiment compared two different types of newcomer tasks, not a control group without any access to them at all. And the Add-a-link link is (ironically) broken (404). ChompyTheGogoat (talk) 10:05, 29 August 2026 (UTC)
Also, from the Revise Tone experiment the changes in constructive edit rates did not meet the threshold for statistical significance. ChompyTheGogoat (talk) 10:07, 29 August 2026 (UTC)
Yes, the individual subtasks have differing levels of value, which is why proposals, such as yours at the top of this thread, to remove all of them indiscriminately, are a bad idea. We should keep the ones we like, configure the ones we're okay with, and turn off the ones we dislike. WhatamIdoing (talk) 16:30, 29 August 2026 (UTC)
Add a link is probably the only one I've seen that doesn't cause blatant issues, but I have to wonder if the lower reversion rate is simply because it's such a minor change (and a judgement call on whether or not it's appropriate in a given situation) that patrollers often won't bother, in comparison to edit types that are more prone to cause issues in general. Copyedit or revise tone can insert statements that are flat out incorrect (as with the instigating edit I saw), to say nothing of more general edits that add or remove material. The feeling I get from the data in your link is that there's a slight benefit in terms of new editor retention because they feel successful, but not necessarily much benefit to the actual articles. It's essentially busywork. I'd rather have some kind of training module for different types of practice edits, but obviously that's a far bigger proposal. The reason I started out with "just shut it down" is because it's clear there have been ongoing problems with the tasks and discontent among seasoned editors for some time, but there doesn't appear to have been any concerted effort to improve things. If people aren't willing to make one, disabling them entirely is easier and would prevent additional problems going forward. ChompyTheGogoat (talk) 06:24, 6 September 2026 (UTC)
I feel like there's a tendency to let the perfect be the enemy of the good on this subject. If a tool has any benefit compared to doing nothing, we should keep it instead of doing nothing. WhatamIdoing (talk) 16:18, 6 September 2026 (UTC)
I tried that early on and wasn't impressed.What part of "experienced editors spend a bunch of time patrolling and reverting bad edits" sounds like a net benefit? ChompyTheGogoat (talk) 17:38, 6 September 2026 (UTC)
Because if we've got a thousand edits from newbies, our realistic options are:
We get a higher rate of bad edits, requiring experienced editors to do more reverting, and we end up with fewer editors coming back on a subsequent day/week/month, causing Wikipedia eventually to die.
We get a lower rate of bad edits, requiring experienced editors to do the same amount of patrolling but less reverting, and we end up with more mid-level editors, giving Wikipedia a chance to survive the next 20 years.
The option in which edits from newbies don't require "a bunch of time patrolling" doesn't exist. The thing we can actually affect is the number of reverts and therefore whether the newbie will try again another day. WhatamIdoing (talk) 20:24, 7 September 2026 (UTC)
And I'm not convinced most newcomer tasks accomplish that. In fact, I feel like it's more discouraging to have something reverted when Wikipedia specifically said "this is something that needs to be fixed and we think it's an easy task that you can handle without experience" as opposed to something that a newbie chooses to try to improve on their own. If we're going try offer them specific work, the work needs to actually be appropriate and provide support to maximize their chance of success. It's like starting a new job with no experience and having someone plop a pile of work on your desk with minimal instructions, then come back at the end of the day and tell you you've done all of it wrong. I sure as hell wouldn't be coming back after that. In my metaphor I chose to instead wander the halls looking for things that I felt competent to work on and asking whatever editor happened to be passing by any questions to try to ensure I was doing it correctly, which helped keep my reversion rate down and my confidence up (somewhat). I also spent lots of time dropping into random "meetings" to learn from the discussions instead of diving headfirst into editing without a foundation of knowledge to work from. A successful workplace with low turnover would offer more structured support to new workers instead of this sink or swim philosophy. ChompyTheGogoat (talk) 02:21, 8 September 2026 (UTC)
Let's stipulate that it's worse to be reverted for an edit suggested by the software than for an organic edit. How much worse? WhatamIdoing (talk) 03:13, 8 September 2026 (UTC)
I don't think that's something you can quantify. The effect it'll have on motivation and retention depends entirely on the editor in question, and of course how often it occurs. If they make a whole mess of edits right away thinking they're doing the right thing because it was recommended and come back to find a large number of them have been reverted that's a far greater impact than my initial "oops, my keyboard inserted a blatant error" reverted edit. I fixed it and went on with my day. If they do something similar with a single newcomer task and get reverted before continuing, maybe they realize things are more complex than they thought but don't get as offended because they didn't devote that much time and effort to it. It's all situational. ChompyTheGogoat (talk) 03:24, 8 September 2026 (UTC)
I think that a good economist would say that everything can be quantified. Actuarial work seeks to quantify just how much worse it is to lose a thumb than to lose a toe, or to die when you're 35 than when you're 55 or 75, so I'm pretty sure that it's possible to quantify whether it's worse to be reverted for a suggested edit in an article you don't really care about vs an organic edit in an article on a subject that interested you. It might be situational, but there will still be an average. And based on that average, we can easily determine just how much better system A has to be, compared to system B, for the benefits to overcome the disadvantages.
And that's apparently happened, because people with access to the newcomer tasks actually stay more than people without it. WhatamIdoing (talk) 05:59, 8 September 2026 (UTC)
Just because capitalism assigns a dollar value to human suffering doesn't mean it's an appropriate approach to life. Still only seen a single clear stat for retention from a valid A/B test on the link suggestions - not other tasks or the newcomer module in general. You cannot extrapolate from the least problematic type. ChompyTheGogoat (talk) 09:43, 8 September 2026 (UTC)
@ChompyTheGogoat We've run several other A/B tests that include newcomer retention stats, a few others are here:
Revise Tone Experiment analysis - this was one of our first experiments using a new testing platform (Test_Kitchen), and if I'm remembering correctly, Newcomer Retention simply wasn't an available metric at the time we tested, which is why we looked at "Constructive Edit Rate" for this experiment. We now have short-term and long-term retention metrics defined and we plan to use them for future experiments.
I also wanted to share that the work the Growth team is doing on Home is aimed to help address some of the gaps you have identified in this thread: newcomers should receive more relevant suggestions, more learning support (including short micro-learning videos), and more opportunities to grow and progress on to more meaningful work on the wikis. I won't pretend that this one project is an answer to everything you raised in this thread. But I think it's another step in the right direction to support newcomers, and should hopefully address some of the Newcomer Task frustrations you've named.
One thing I'd especially like your take on: do you think there a future where junior editors take on more of the reviewing and patrolling of "low risk" newcomer edits? You gestured at something like this above with the patrol group idea. Right now that work falls to the most experienced and busiest editors, so a very basic newcomer edit can end up costing several of them time that could go toward harder cleanup work (or perhaps just more enjoyable wiki work). - KStoller-WMF (talk) 22:51, 8 September 2026 (UTC)
Sure - I don't think it's particularly difficult work. It's not something I'd personally dedicate a lot of time to, but I'll frequently take a quick look through a newcomer's edits and try to address any issues I spot, and I'm sure there are others more involved with welcoming/outreach that wouldn't mind setting aside a bit of time for it. Most editors who are ECP could probably do it. I find work like that useful in small doses for improving my own skills via checking sources and pulling up the relevant guidelines, as well as expanding my horizons on subjects I wouldn't normally look up on my own. I do think it would be helpful to implement a tool that allows said editors to verify a given edit has been reviewed so others can skip over it, although it wouldn't necessarily need to be removed from the list altogether. A checkbox would probably be fine (might be scriptable?) If it's something that needs to be fixed but that editor doesn't feel like addressing it in that moment they just leave it unchecked and it would still show as unreviewed. ChompyTheGogoat (talk) 23:09, 8 September 2026 (UTC)
@KStoller-WMF, I think that patrolling "obvious" edits (both obviously good and obviously bad) is a good way to get started in anti-vandalism and other patrolling efforts.
That said, there's a risk: highly active RecentChanges patrollers don't like doing difficult clean-up work, and if one were to filter most of the easy reviewing work out, they'd feel like a fun, high-speed, usually easy task had become a long, slow slog. Speed appears to a significant motivator for some of the long-time RecentChanges patrollers, and anything that makes them pause or slow down is demotivating. The little dopamine hit from reverting blatant vandalism is important. And no matter what the task, if it's always the difficult question, then that rapidly becomes tiring. This isn't unique to Wikipedia; there was research ~10 years ago about the problems that Facebook's underpaid reviewers had when their filtering system got better, and the review queue that had been a mix of reported posts became endless queues of serious problems. So if most of the easy calls were to be checked by newcomers, we might end up with fewer and fewer experienced editors doing RecentChanges patrolling. WhatamIdoing (talk) 00:21, 9 September 2026 (UTC)
@ChompyTheGogoat Thanks for sharing your thoughts on the idea of reducing review redundancy. We have a software feature that could help with this, but it's currently not enabled on the English Wikipedia. On some other wikis, there's a 'patrol' button for each edit, so users can mark an edit as 'patrolled'. Other editors can then filter this edit out of venues like Recent Changes, and focus on unreviewed edits. There have been some discussions here about the feature, but no consensus to enable it. I'm interested in thinking about how we might be able to update the feature so that it could be enabled, if the community wanted to do so. I've been collecting notes at T409165 - would love to know if you have additional thoughts! Samwalton9 (WMF) (talk) 09:57, 10 September 2026 (UTC)
There's a whole lot more to that story (some of which is under NDA). I don't think a task group focused on good faith newcomer edits would have too much impact on the overall Recent Changes workload though, and reaching out to help newbies who made honest mistakes appears to be one of the things that's lacking. I often see them reverted with only a cursory edit summary that would be sufficient for a more experienced editor, but isn't likely to help newbies learn from it - and I know regular patrollers might not even realize it's a newbie when they revert, but someone who's specifically patrolling for them would know and could take extra time to try to help them improve. ChompyTheGogoat (talk) 14:13, 9 September 2026 (UTC)
@Gnomingstuff Thank you for taking the time to respond and for the previous audit work. I understand the frustration, especially the feeling that the cleanup burden has become overwhelming. Is there a particular task that you think is especially problematic, or do you feel that Newcomer Tasks as a whole are problematic?
I completely agree that we cannot equate “not reverted” with “good.” It is, however, one of the signals we have available. Looking at English Wikipedia article-namespace edits from January through July 2026, among editors with fewer than 30 days of tenure and fewer than 100 edits:
Newcomer edits overall had a 30.1% revert rate (900,292 of 2,994,419 edits). [1]
Edits made through Newcomer Tasks had a 4.7% revert rate (5,416 of 115,188 edits). [2]
There is an important caveat to this comparison: people who choose Newcomer Tasks are likely good-faith editors, while the overall newcomer figure includes vandalism and other clearly problematic newcomers. So this comparison almost certainly overstates the difference. And, as you point out, neither number captures cleanup that happens without a formal revert. Even with those caveats, though, the data suggests that Newcomer Tasks are not disproportionately contributing to the revert workload relative to newcomer editing overall.
The reality is that newcomers will always make some mistakes as they learn. That is part of bringing new people into the project. At the same time, I do think there are several promising projects underway that should help:
Better onboarding and task matching: The Growth team is working on early onboarding changes, including changes to the Newcomer Task feed. We are working toward a smaller, more curated set of tasks that better matches contributors to tasks based on skill level and interests.
More accurate Add a Link suggestions: The Machine Learning team is working to improve the accuracy of Add a Link suggestions, which should reduce the number of poor-quality suggestions reaching newcomers (T434259). The Growth team will also work on an Add a Link improvement soon that will both decrease the quantity of suggestions available and also increase the quality of suggestions (T429417).
More learning support: The Community Development team is working on "micro-learning" videos based on the Wikimedia Core Curriculum, giving newcomers more guidance at the point when they need it.
Catching mistakes before publication: The Editing team's Edit Check work catches some common mistakes before they are published.
Expanding the moderator pool: The Moderator Tools team is working on ways to onboard moderators and patrollers, so that the work of reviewing newcomer edits can be distributed among more people.
None of this clears your 200 tabs today, and I don't want to pretend that it does. But the direction we're investing in is fewer, better-matched tasks, with more support for newcomers and better safeguards around the edits they make, while also helping newer editors develop toward appropriate moderation and patrolling roles.
Does that feel like the right direction to you? And are there other approaches or ideas you think we should be considering? KStoller-WMF (talk) 21:31, 28 August 2026 (UTC)
@KStoller-WMF, would you also consider coming up with some better way to categorize articles for the purposes of showing "relevant to your interests" articles to newbies? There's someone complaining about that upthread, and I recall also finding this pretty useless for the same reason. I was under the impression that those ORES topics were going to be replaced by something much better years ago, and that hasn't happened. Is anyone still working on that? In solidarity, asilvering (talk) 21:42, 28 August 2026 (UTC)
Design showing how newcomers could select articles of interest before arriving to their Homepage
We hope to release an A/B test as early as next month in which we actually allow newcomers to select articles of interest to populate a more limited set of suggestions. Related project page: https://www.mediawiki.org/wiki/Home
Here's an early prototype if you want to test out the idea. Do you think something like that could be more promising than providing suggestions based on ORES topics? KStoller-WMF (talk) 22:04, 28 August 2026 (UTC)
@KStoller-WMF, this is much better!! All the articles it gave me are related to my interests, and none are in quite such a horrible state that it's depressing to look at them. And, well, it couldn't have known, but... it suggested one of my own articles (Richard Caudray) for expansion. In solidarity, asilvering (talk) 22:26, 28 August 2026 (UTC)
My suggestions are also much better, but I can't click through to check on anything. The crosslinks and references tasks seem reasonable - I'm not sure what "bring up to date" is looking for, which sounds rather vague. I didn't get any revise tone suggestions, which I honestly feel is better because newbies don't have a good feel for Wikipedia voice and NPOV yet - especially since it's marked an "easy" task, which to me should be the very first edits someone ever makes. Crosslinks and basic copyedit are about as easy as it gets. (Crosslink suggestions aren't always accurate or needed, but very low in terms of the actual problem they cause.) ChompyTheGogoat (talk) 05:01, 29 August 2026 (UTC)
I'm going to WP:AGF and assume that a WMF employee knows better than to use LLMs in discussions - we know these tools aren't fully accurate - but I cannot stress enough that if you're spending so much time engaging with AI that you start to sound like them you should seriously check yourself. ChompyTheGogoat (talk) 04:48, 29 August 2026 (UTC)
All of the tasks are net negatives in practice with the exception of Suggested Links, since the damage an individual editor can do with it is very small and contained, and does not affect the prose.
The type of the task also doesn't matter, as people disregard it all the time. Just a few examples taken from the hundreds of tabs I am slogging through:
Special:Contributions/HelloHop (Note the **Suggested edit-summary (copy-paste into the “Edit summary” box):** chatbot response in one edit summary, an indication of how thoroughly this person reviewed the edits they have spammed out)
Have you looked at the edit trail of new editors to try to classify their intentions? My guess is that some people have rather specific goals, e.g. taking political positions in a specific country. Others become unhappy when they see glaring errors in technical articles and feel they just have to fix them. Others feel that their small town has too little info. Others may be ....? Have you done a survey on this? It would be interesting to know. Thanks. Yesterday, all my dreams... (talk) 02:00, 5 September 2026 (UTC)
I'm going to ask a newcomer which likes using the feature for their opinion. 16dvnk (talk) 14:12, 5 September 2026 (UTC)
Let's not forget that their response to sunk cost concerns is to barge ahead anyway instead of pumping the brakes, so I have zero sympathy for that at this point. If you want to ensure your work will have a lasting beneficial impact, make sure it's something anyone bloody well wants before you ram implementation through. Or eat the consequences. ChompyTheGogoat (talk) 04:30, 29 August 2026 (UTC)
Sunk cost fallacy is one of those power words that power users like to throw around, usually when they have a gut-level revulsion to a change and don't think they'll be able to stop the change. There's a relevant source linked at the end of Wikipedia:You don't own Wikipedia that might prove to be interesting reading, if you haven't seen it before.
But, as a point of fact, the stated response in that discussion (which comes from a long-time Wikipedia editor, BTW) is that they've designed this project so they can easily "abandon" anything that doesn't look promising. A lot of the ideas the WMF evaluates don't see the light of day (e.g., the most recent round of "let's change the font!", which comes up every five years or so – but never from someone who lived through the last attempt), so you probably wouldn't hear about them unless you watch phab: regularly. Consequently, it is important not to assume that the continuation rate for the few projects you've heard of is the overall continuation rate. WhatamIdoing (talk) 05:23, 29 August 2026 (UTC)
Perhaps not, but it seems to be their preferred response on these related subjects. It was clearly communicated that numerous editors are uncomfortable with that project and a desire for consensus was expressed, and the response was "we can always abandon it later", which does nothing to address the underlying concern. Do they believe the community is going to magically change our opinion on LLMs by that point, or are they then going to argue that they should keep going after putting so much work into it? What harm does it do to pause and see whether people really do want this tool at all, instead of "what suggestions can be used going forward because we're definitely going forward"? It feels like they're willing to reconsider specific aspects based on input, but not the project as a whole. Rather WP:IDIDN'THEARTHAT of them, IMHO. ChompyTheGogoat (talk) 05:57, 29 August 2026 (UTC)
No, but they might believe that (a) people who haven't tried the tool don't have the information they need to make an informed decision, and (b) that even if the tool is abandoned, something useful could be learned from it. And, of course, we all know that (c) the ~five dozen people in that discussion, some of whom support the project, are not even remotely representative of the three-quarter million registered editors who make at least one edit in a given year.
More generally, we have the problem that (d), if you reach out to the communities early in a project, when it would be cheap and easy to abandon it, then people don't understand the project or its goals, and even complain that you brought the idea to them so early, when you don't even know how it will behave or whether it works or what it looks like. But if you bring it to them later, when you can provide solid answers to most of their questions, they say "How dare you not involve me early in the process! Nobody asked for this! (Pay no attention to those diffs behind the curtain that prove that someone else in the community did ask for it.) It wasn't discussed! (a common enough complaint that experienced people create lists of prior discussions such as Wikipedia:Vector 2022#List of discussions, but you still get nonsense, like this IP claiming "that nobody saw" an RFC that 344 people participated in) I hate it! (but a couple of months from now, I'll probably have gotten used to it). It was before your time, but the RFCs for Vector 2022 was so predictable (and predicted) that I should have started a betting pool on when the first rollback RFC would be started, measured in hours after deployment.
The WMF product folks who are involved in the project being discussed likely remember my views on anything that sounds like Microsoft's Clippy: I'm not a fan. But I don't think that the work they're doing is useless, or that any editors will be forced to use it. WhatamIdoing (talk) 06:42, 29 August 2026 (UTC)
Consensus is never expected to require input from the entire editor pool, just enough who have interest in the specific proposal to get a solid feel for the overall sentiment based on rational arguments (especially, but not exclusively, made by senior editors who do understand both the relevant guidelines and history of the subject on-wiki). And I don't think early consensus should be the final say on wide scale implementation, but an indication that most people think the general concept has enough promise to be worth developing and evaluating once it's functional. If they built a full Grokipedia style bot to write unreviewed articles and didn't listen to the community until it was in on-wiki testing I expect there would be a few opinions. I also did read your previous reference to Wikipedia:You don't own Wikipedia and I really don't feel it applies in this situation. Obviously not to me - I haven't even been here for a year, but I've seen how much harm AI can do both on wiki and off, and I've seen how the general community feels about its implementation, as reflected in existing guidelines. I've also seen similar sentiments on a smaller scale when it comes to newcomer tasks, which is why I started this, and I'm not at all surprised to learn it's also AI because the randomness and low quality of the suggestions is exactly what I expect from slop that can't comprehend the task at hand because it has no comprehension. An RfC would garner input from a wider variety of editors so no "power users" can attempt to strongarm their opinion through. Obviously the WMF should and does have ultimate authority when it comes to legal issues, finances, etc - but that's not what this is. Individual projects are supposed to have a wide degree of latitude for how to manage content that doesn't cross any legal lines, and English wiki is largely against AI implementation. If they want to develop it for different projects that have wider acceptance, have at (but I suspect they wouldn't devote the resources to it if we reject it from EN). ChompyTheGogoat (talk) 09:38, 29 August 2026 (UTC)
@ChompyTheGogoat, the way WAID's essay applies here is that we desperately need more new editors to step up, to replace those of us who inevitably will wander away from the projects (or die in office). It's going to be a group effort to make the projects more welcoming to newcomers, and this is one possible way. AI has some real promise in surfacing appropriate tasks for newcomers, because of the WP:SOFIXIT attitude that longtime editors have - if we spot something easy, we just fix it ourselves. That means that what's left - the stuff that's tagged - is often an absolutely horrible slog to deal with. That was my own experience of the newcomer homepage, when I started - it was entirely the tasks generated by maintenance templates, and what it sent me to was articles so broken that I felt completely demotivated to try to fix them. The tool was suggesting I get some basic editing experience in, and sending me to articles that needed to be completely rewritten, not things that were a quick job at all. Things like the suggested links task and revise tone can help find spots that need help that are much more within the capabilities and inclinations of newbies. In solidarity, asilvering (talk) 16:58, 29 August 2026 (UTC)
Revise Tone is precisely what I've seen the most problems from. It might look easy to someone who doesn't know what they're doing - because they don't know what they're doing. I'm not sure that one can be fixed either, because "phrases like these often get changed" is in no way shape or form indicative that it's a simple task appropriate for new editors, and just changing it doesn't mean it's been improved. It might be useful as a feature that more experienced editors can utilize, or as a flag that pops up to indicate the problematic phrase when someone is already editing the article in question, but we need to keep newbie tasks simple and more objective (if we keep them at all). ChompyTheGogoat (talk) 06:53, 6 September 2026 (UTC)
or as a flag that pops up to indicate the problematic phrase when someone is already editing the article in question - this exists (as a beta feature) in the form of Suggestion Mode. OutsideNormality (talk) 17:46, 6 September 2026 (UTC)
Sounds good in theory, except it only applies to visual editor. Most seasoned editors (who would have the skills to handle more complex and subjective situations) use source mode. Hopefully they can expand it with additional implementation.In any case, that's neither here nor there re: newcomer tasks. ChompyTheGogoat (talk) 20:04, 6 September 2026 (UTC)
Most experienced editors use both editing environments, based on what kind of work they're doing. Choose the visual editor for copyediting and table structure edits; choose one of the four wikitext editors for fixing wikitext problems. And, of course, you don't always have a choice: the 'Undo' button always uses the 2010 wikitext editor, no matter what your preferences say (and falls back to the 2003 WTE if you have javascript disabled). WhatamIdoing (talk) 21:54, 7 September 2026 (UTC)
I've spoken to many editors who've been around for a long time and don't know how visual works because they're never felt any need to use it. I hardly ever toggle it myself, despite mostly editing on mobile. I only leave it switched on for diffs. Regardless, if they don't think the work they're doing at the time requires visual and don't see that the flags exist, they're useless in that scenario, so I think wider implementation for as many editors to see them as possible (whether or not they choose to address it in that moment) would improve outcomes. I fix a lot of things that I stumble across at random, and if I had something flagging a wide variety of issues I'd usually at least take a look to see if it's something I felt capable of doing. That's a much better use of such features than serving them up to newbies. ChompyTheGogoat (talk) 02:31, 8 September 2026 (UTC)
Many editors only do a narrow range of tasks. I've never met one that preferred adding a column to a table in the wikitext editor after they've experienced doing it in the visual editor, even among those of us (including me) who can type the wikitext syntax by hand from memory. WhatamIdoing (talk) 03:16, 8 September 2026 (UTC)
And how much of the total editing on all of Wikipedia involves adding columns to tables? That's certainly a narrow focus. As I said, some editors will choose not to address the flag while they're there, and that's fine - but some will. The same people who might not actively seek out the article from some list of such problems might be willing to make additional improvements if they're already there working on whatever they're personally interested in. The more eyes on it (especially experienced ones) the better the odds are that it'll get addressed appropriately. ChompyTheGogoat (talk) 03:28, 8 September 2026 (UTC)
The problem with a non-representative group of editors is that you don't "get a solid feel for the overall sentiment"; you instead "get a solid feel for the overall sentiment within a non-representative group, which may or may not differ significantly from the overall sentiment of the whole community". Sometimes there's no important differences; that's why most RFCs, with a typical participation of 5 to 15 editors, work. But sometimes it does matter.
I suspect that the bigger weakness with the Small language model is that it can't compare article content against source content, so calling William Shakespeare "the greatest writer in the English language and the world's pre-eminent dramatist" will seem puffy, and that saying Martin Shkreli has a "reputation as 'the most hated man in America'" will seem disparaging. But both of these are justified by the sources, and the SLM machine learning tool has no way of knowing that. WhatamIdoing (talk) 17:16, 29 August 2026 (UTC)
What's your definition of a representative group in this context? We're not going to get an even slice of the editor population, because people who don't have an opinion on it (which is likely to be most of them) won't chime in. How do you propose improving said group, except through RfC? We have the tools we have. ChompyTheGogoat (talk) 06:56, 6 September 2026 (UTC)
I'm not at all surprised to learn it's also AI
Just to clarify, the problem is that people are using AI to spam out the tasks. If people weren't using AI to spam out the tasks, there would be less of a problem. But the tool itself encourages this behavior, by design:
The gamification system, by design provides an incentive for them to do so as fast as possible so Number Go Up as fast as possible, and provides repeated praise, implicitly and explicitly, as they do it.
The tool funnels them to articles that have already been identified as problematic, making those articles worse: a slap in the face to everyone who tagged articles for improvement in good faith because they wanted them improved.
The tool funnels multiple editors at a high speed, meaning that those articles' edit histories become so drowned beneath bad edits that none of them can be reverted without painstaking work. Essentially, it gives less-trafficked articles the edit volume of something on the front page, except without the people watching it.
I have the impression that Chompy's concern is that the "Revise tone" task is using a Small language model to find pages for its suggestion list.
I've just done six Revise Tone tasks. Five needed help, sometimes badly. The other was correct. It only proposed changes to a single paragraph at a time. It promptly asked me to switch to a more advanced task. If we're concerned about people doing too many of these in a single day ("as fast as possible so Number Go Up as fast as possible"), then maybe we should ask for daily limits. WhatamIdoing (talk) 00:32, 30 August 2026 (UTC)
Drive-by comment:
I skimmed through the overly tedious conversation. Apparently, the filing editor wants to upgrade the newcomer task feature or remove it, citing concerns over whether the tool is accurate, and how the new editors leave out work for the more experienced editors to fix. While I support a better system, it appears that this is just a WP:Competence is required case. Also, reading through, I am unsure what exactly they want to change. Further, this newcomer system is flawed by design, making a negative feedback cycle.
Is it possible that some PendingChanges type of monitor list shows a subset these edits for human review? Or, change the system so there is a complete Wikipedia course, something that is quite lacking to newbies. 16dvnk (talk) 11:46, 1 September 2026 (UTC)
Is it possible that some PendingChanges type of monitor list shows a subset these edits Well, this shows Special:RecentChanges filtered by edits that are tagged with newcomer task, which one can patrol at will. It's possible to filter further by type of task. Cheers, SunloungerFrog (talk) 14:32, 1 September 2026 (UTC)
However, there doesn't seem to be a way to approve or decline the edit, and what you suggested is a very tedious way. Given that PendingChanges has manpower and the backlog is often empty, it would be nice if those had their own place too. 16dvnk (talk) 14:16, 5 September 2026 (UTC)
Well, there is no way to approve or decline the edit, because Newcomer Tasks are not under pending changes protection. They are just edits that anyone can make, which I think is the whole point. You can still patrol them and revert them if you would like to. Cheers, SunloungerFrog (talk) 15:52, 5 September 2026 (UTC)
If you (anyone) want to check them, then this RecentChanges link will give you a list of all newcomer task edits. At the moment, it looks like it's a bit less than half adding links, a third copyedit/revising tone, 10% adding refs, 5% updating outdated articles, and 5% expanding articles. The 'tags' button on the side will let you change the all-encompassing newcomer tasks tag to a specific tag for just one of these, if you want. WhatamIdoing (talk) 00:42, 6 September 2026 (UTC)
That's just it - it is flawed by design, and when the entire purpose is to improve the level of competence we shouldn't have features that require advanced competence to understand how to utilize them correctly. ChompyTheGogoat (talk) 06:59, 6 September 2026 (UTC)
I'm not sure that "the entire purpose is to improve the level of competence". I'm not sure that any of its goals could be fairly described as "the entire purpose". WhatamIdoing (talk) 19:55, 7 September 2026 (UTC)
If we don't want new editors to get better at editing what are we even doing here? Why provide them any support at all? We don't want to retain them if they only continue to make bad edits. We block people who refuse to improve to a basic extent under WP:CIR. Shouldn't the goal of every editor be to always continue improving their abilities? It's a huge learning curve and if we can get them up that initial steep slope they'll be more empowered to continue improving on their own. ChompyTheGogoat (talk) 02:36, 8 September 2026 (UTC)
"That's not the entire purpose" ≠ "That's an anti-goal". WhatamIdoing (talk) 07:19, 8 September 2026 (UTC)
Which goals would still be relevant even if editors never improve in any way shape or form? If it's "Retaining more users that can improve their competence and make constructive contributions" that's a sub-goal. Would you prefer "The primary goal upon which all others should be contingent"? ChompyTheGogoat (talk) 09:51, 8 September 2026 (UTC)
Yes, that is what I meant (although the use of AI to compose edits is certainly a secondary problem too). Whether or not the tasks are identified correctly is also just part of the issue - it's whether these brand new editors who don't know anything about the subject or how Wikipedia works can actually make a substantial improvement in a very subjective situation.I've also make numerous suggestions regarding expanded introductions to editing for new users that would help them understand the basics before they start editing. I have no idea whether those suggestions are being seriously considered or not. ChompyTheGogoat (talk) 07:02, 6 September 2026 (UTC)
If you think that expanded introductions will help, why don't you draft some suggested content for those expanded introductions somewhere for others, e.g. on the WMF Growth team, to consider? And I couldn't see it anywhere above (may have missed it) but does Help:Introduction cover some of the topics you would expect to see put in front of new editors? I think I remember seeing it early on, but can't quite remember when it was surfaced. Cheers, SunloungerFrog (talk) 08:00, 6 September 2026 (UTC)
Wikipedia:Nobody reads the directions (except Chompy). Seriously, we have three-quarter million registered editors making an edit each year, and the number of people who later say that they read a lot of help/policy/etc. pages before making their first edit appears to be a single digit number. Per year. For typical newcomers, the iron laws of the internet (e.g., WP:TLDR) apply. WhatamIdoing (talk) 20:00, 7 September 2026 (UTC)
And yet I still see so many people saying they had no idea such resources existed. If we smack them in the face with it and they choose to ignore it, then and only then can we hit them with WP:CIR. Much like the AI and COI affidavits would remove plausible deniability. Part of WP:AGF is ensuring people have every possible opportunity to do things correctly. I don't think my particular skillset is so much the willingness to read guidelines, which is required of all editors, but the ability and determination to go to extra lengths to look for things myself. I can't count the number of times I've gone to fix something, then wondered where there's any relevant guidance that would ensure it's both necessary and correct, and proceeded to spend far more time looking for said guidance than it takes to actually make the edit. Once you have some idea of the basics (which would be presented in my pop-up idea) it's easier to know what else you might need to look up in other situations, and I've also made recommendations for improved organization to enable people to find such things easily, but you still have to know they exist in the first place. ChompyTheGogoat (talk) 02:48, 8 September 2026 (UTC)
As an aside, I did not in fact read any guidelines before my very first edit, because I alsodid not know they existed. Fortunately it was a very simple correction to mirror the source that I'd continued my reading on, so I didn't need any specialized WP knowledge. I just wanted to fix that single passage and didn't try to make any more live edits right away, so I got welcome templated and (presumably?) followed that link to Teahouse, and gradually found my way to additional resources before continuing to do any substantial mainspace edits. I think it would be extremely beneficial to encourage other newbies to hit that pause button for anything beyond a single minor correction that motivated them to start editing in the first place. If they come here with the general goal of working on Wikipedia instead of fixing a specific issue they spotted as a reader then taking that time to learn how to be successful shouldn't be a deterrent. ChompyTheGogoat (talk) 02:58, 8 September 2026 (UTC)
Regarding "the tool funnels them to articles that have already been identified as problematic" that can be a serious problem and can also cause chaos in software management. Sometimes new programmers who can not be trusted to write major new pieces of code are assigned the task of "fixing" bugs in the system. In the process they introduce many new bugs, exactly because they are newbies. Only one word can describe the situation: nightmare. Yesterday, all my dreams... (talk) 13:15, 7 September 2026 (UTC)
It's somewhere around here, and I think one of their team was involved with the latest discussion. I want to see a "Welcome to editing" pop-up that appears when you first create an account (or attempt to edit from a TA) that will give a very brief overview of the most critical policies and common mistakes, and links to various other resources for continued learning. The more proactive we can be instead of reactive the better retention is likely to be. It currently feels like you're tossed directly in the deep end and have to keep your head above water while searching for a flotation device - then maybe someone stops by and offers to help. We should loop people from WikiEdu in and try to learn from what's worked for them; condense the basics down for people who don't have access to those programs and need to be able to learn on their own. There's a lot more we could do as far as things like training modules, but I think this is one of the simplest things that could be implemented quickly and would have a huge impact. The goal would be to keep it under 5 minutes reading time (preferably more like 2) but strongly encourage them to follow the additional links. It would also be skippable for people who already know what they're doing. ChompyTheGogoat (talk) 09:43, 6 September 2026 (UTC)
Sorry, I should've been clearer: I meant "I can't remember when I saw Help:Introduction when I first started editing" not "I can't remember when Help:Introduction first came up in this thread".Re your popup, I am trying to think what I would have done had I been faced with such a thing when I started editing, and I'm afraid that I would probably have done whatever I needed to do to make it go away - ticked the boxes, clicked OK, chosen "Skip", whatever - so that I could get on with the edit I wanted to make. I won't generalise from my experience, but it certainly wouldn't have had a huge impact on my editing.
What edits would you make to Help:Introduction to cover things that you think are missing in that? Cheers, SunloungerFrog (talk) 10:13, 6 September 2026 (UTC)
You might have clicked out if you already felt confident that you knew what you were doing, but many wouldn't, and it would start with a splash screen saying essentially "We're glad to have you, but there are a lot of rules and we want to help you avoid common mistakes so we strongly recommend reading the following if you're new here". I probably would have read it - I made a couple TP suggestions before actually creating an account because I was afraid of screwing up if I tried to edit an article directly - and in fact my very first live edit WAS reverted, but only because of a glitch with my phone. The issue isn't necessarily what resources are available, but people being able to find them easily. ChompyTheGogoat (talk) 17:37, 6 September 2026 (UTC)
Help:Introduction wasn't even created until 2015, so I think that it's fair to assume that more than half the admin corps definitely didn't read it before starting. The problem with "if you already felt confident" is that confidence is a poor predictor of knowing what you're doing. WhatamIdoing (talk) 20:14, 7 September 2026 (UTC)
Obviously. We can't force people to read, but we can at least provide them with the opportunity. Isn't your base argument than any improvement is a win? We're obviously not going to see 100% success from literally anything. And I would recommend that the initial splash screen (possibly with additional details on the second slide) try to stress exactly why it's so important to understand how things work, and that we really want them to be successful instead of being reverted because they didn't know something basic. If people can't even be bothered to read a few sentences right in front of their face their chances of making it as an editor are far lower. Some of them are going to wash out - it is what it is. Our target audience is good faith editors who are WP:HERE and truly want to make edits that are constructive and well formed. We can't change their motivations, but we can provide them with the tools to learn if they choose to utilize them. ChompyTheGogoat (talk) 03:06, 8 September 2026 (UTC)
If our target audience is people who "truly want to make edits", we should close up shop now and go home, because we're going to die for lack of editors. Most people don't "truly want to make edits". Most editors start off in the range of "eh, I see a typo, and I heard you can edit" and (just) a few of them find the experience so appealing that they keep doing it. Prior research has shown that even putting a small barrier in between the newcomer and their first edit causes significant reductions in the number of edits. We are operating on a principle closer to "First one's always free, kid" than on "Please read the instructions before you touch the delicate machinery".
As you say, "we can't change their motivations", which is mostly either "I'm willing to help out if it's really easy", but we can avoid putting up barriers. I particularly object to your desire to "hit them" with a complaint that they're incompetent if they don't read, remember, and follow all the directions (most of which will be irrelevant to most of their intended edits) before making their first edit. As I've said before, Wikipedia:Too long; didn't read is one of the iron laws of the internet. If you make people read a bunch of stuff first, they'll quit instead. We need them to try that first edit. WhatamIdoing (talk) 18:00, 10 September 2026 (UTC)
That's a blatant misinterpretation of what I said. Not only did you literally drop the inconvenient part of a sentence, but I specifically said we can only apply WP:CIRif they've had the opportunity to learn. As in, we cannot expect competence if they don't, and I certainly didn't mean for their very first edit. If we could manage to stop more of the editors who will mostly or exclusively make bad edits during their tenure, I'd call that a win. More editors isn't always a good thing. Of course it's significantly harder to track complex stats such as "how many good edits are made over time" instead of just "how many new editors make their first edit", but you can't know what the effects are at all if something hasn't been tried. Testing is important. As I've already stated, using encouraging language and making it easily skippable would both be priorities. I'm definitely the person who skips through tutorials most of the time, because usually what I'm doing is easy and obvious, but this is one situation where I was less sure of what I was doing and would have welcomed more information. When I did find that information later it drew me into editing (particularly Teahouse) instead of pushing me away. If I hadn't found the discussion boards I highly doubt I would have come back. For people who do skip it and make a mistake, we continue to treat them the same way we do now. Really the only difference in how experienced editors respond to newcomers would be if they agree to the COI and AI affidavits and then violate them. Otherwise we're just providing them with more information and hoping it improves their rate of good edits and lowers necessary reversions, which then improves retention of those that are reasonably competent. Washing out those who aren't (despite being offered resources and given multiple chances) is the system working as it should. ChompyTheGogoat[Bleat|Munched] 18:41, 10 September 2026 (UTC)
Well, this was timely.Special:Diff/1373683524 Special:Diff/1373682228 Special:Diff/1373680292 Special:Diff/1373677809Plus User_talk:WXchaser#Question_from_Ainigushenzouanxiang_on_NYChrisG_(06:22,_7_September_2026) (and subsequent sections). This appears to be a good faith new editor who has no idea what they're doing and is fumbling around not understanding what the newcomer tasks are asking of them, particularly revise tone. The only edits that seem fine are link suggestions - one of the articles already appears to be overlinked to my eye, but I'm not going to attempt to guess whether their addition is more or less appropriate than all the existing links. So out of seven mainspace edits this user has already had four partially or fully reverted - and the other editor who did so didn't bother dropping them a TP note, so they're probably unaware of it. ChompyTheGogoat (talk) 10:03, 7 September 2026 (UTC)
Which is kind of the problem here, because if someone doesn't understand why an edit like Special:Diff/1373682228 does not change the tone at all, then all the Wikipedia training in the world is not going to help a problem that's fundamentally about English writing/editing skills. Gnomingstuff (talk) 15:24, 7 September 2026 (UTC)
Yes. Adding a preposition to a WP:PLOTSUM doesn't change the tone. @Sdkb-WMF, can you talk to the Growth team about having the Revise tone task avoid plot summaries? WhatamIdoing (talk) 20:16, 7 September 2026 (UTC)
I don't mean this to be rude, but this is a strange and overly literal interpretation of what I pointed out. Adding one preposition to anything is unlikely to change its tone. It might change its grammar, or fall into one colloquialism or another ("he found that" vs. "he found out that"), but the edit above doesn't change the tone, and I highly doubt the person can explain why.
Basically, the problem is that this editor is not proficient enough in the English language to do English-language editing tasks, much like I am not proficient enough in the Swedish language to do Swedish-language editing tasks. Newcomer Tasks are not equipped to teach people English, and the English Wikipedia interface should stop encouraging them to do something they currently cannot do well. (Of course, the editor could always recognize by themselves, on their own volition, that this isn't their skill set, but for whatever reason people don't do that.) Gnomingstuff (talk) 05:59, 9 September 2026 (UTC)
I think that plot summaries, particularly in fantasy or other forms of non-realistic fiction, are highly likely to correctly contain phrases that seem to have tone problems. The problem isn't the edit that was made; the problem is that the Revise tone task suggested improving that plot summary in the first place. WhatamIdoing (talk) 18:13, 10 September 2026 (UTC)
Following up on this, @WhatamIdoing, we've documented a Phabricator task that would create the ability for the community to exclude plot summary sections: T437637. Cheers, Sdkb‑WMFtalk 19:30, 10 September 2026 (UTC)
They may or may not be capable of doing the actual work, but I still think the bigger issue is not understanding what's being asked for in the first place - just like I wasn't, and not for lack of English skills. I've seen plenty of other fluent editors have the same problem. But we're in agreement on the tasks encouraging them to complete work that they don't actually comprehend. ChompyTheGogoat (talk) 14:04, 9 September 2026 (UTC)
Precisely my point. They don't even understand what the task is meant to accomplish, in addition to not flagging things appropriately. The feature itself is the problem. ChompyTheGogoat (talk) 02:02, 8 September 2026 (UTC)
I disagree. The fact that some newcomers struggle doesn't mean that the software is bad. WhatamIdoing (talk) 02:58, 8 September 2026 (UTC)
I've already made my case for "this phrase often gets changed" =/= "this is a simple fix that a new editor with no experience can handle correctly without additional instructions". If this person really understood what the task is asking for they might have made a better change, OR they might have realized they aren't up to it and just skipped it entirely. Both would be a better outcome. ChompyTheGogoat (talk) 03:10, 8 September 2026 (UTC)
But they did "skip the suggestion entirely". And while they were there, they made a small change that wasn't related to the suggested edit.
Do you understand that if it makes a suggestion, then the tag is there, even if you decide that the tag is wrong? "Tags: Revise tone" is not a promise that the edit attempted to revise the tone. It's a paper trail explaining how the editor arrived at the article. WhatamIdoing (talk) 07:22, 8 September 2026 (UTC)
Are you confusing different examples? This editor made numerous good faith edits that are not useful and needed to be reverted, and asked their mentor for help understanding how revise tone tasks are meant to be accomplished numerous times in a row. If that doesn't indicate they don't understand the task then what on earth does?? ChompyTheGogoat (talk) 09:54, 8 September 2026 (UTC)
to be fair, whoever is answering their questions is not doing a very good job of it Gnomingstuff (talk) 00:13, 9 September 2026 (UTC)
That's a separate issue that also needs to be addressed, but there's still an overall failure to comprehend the tasks at all. Work that's specifically aimed at newbies should be reasonably self explanatory. After I reverted one and linked to the relevant guideline they came back and made a better edit, so they are capable of figuring it out if the information is provided. I don't really know what to say about the revise tone though because even I don't know what the task is asking. ChompyTheGogoat (talk) 12:49, 9 September 2026 (UTC)
I don't think your examples above are proof that newcomer tasks don't work, it rather shows that some newcomers are doing low-quality edits, regardless of any attempts to guide them. Your first link Special:Diff/1373683524 is their attempt to find references – someone who reads the tutorial on finding references that pops up when doing the task and considers Reddit a good source, is unlikely to ever do good contributions to our projects imo. Johannnes89 (talk) 09:31, 9 September 2026 (UTC)
is unlikely to ever do good contributions to our projects imo I think that's rather a sweeping statement. First, the editor may well have had good experiences outside Wikipedia with the accuracy of information on Reddit, so why would they think off the bat that it is an unreliable source? Second, maybe they missed the note on the fifth slide of the tutorial that social media is generally not reliable, or they might not consider Reddit to be social media - it is certainly user-generated, but the tutorial doesn't talk about the unsuitability of user-generated content. In this case, the edit was reverted with a decent edit summary, plus a corresponding talk page message, helping the editor to learn from the mistake. That is, I think, how we encourage and retain new editors, rather than dismissing them out of hand after they make a mistake on their fourteenth edit. Cheers, SunloungerFrog (talk) 10:07, 9 September 2026 (UTC)
And I do understand that such reversions are a necessity sometimes, but I think the more proactive we can be with learning resources to try to keep reversion rates down, especially on the first handful of edits, the better retention will be. ChompyTheGogoat (talk) 12:53, 9 September 2026 (UTC)
They literally came back and added a better source to that article after I reverted and linked to the relevant guideline. Clearly the task did not provide adequate support for them to understand it. ChompyTheGogoat (talk) 12:50, 9 September 2026 (UTC)
Also, this is my experience with most newcomer task edits - I'm not cherrypicking bad ones. I literally just ran across this editor at random while this discussion was ongoing. I've seen very few newcomer task edits that were actually good, and it's almost always the suggested links because those are idiot proof (and cause no real harm even if they're incorrect). ChompyTheGogoat (talk) 14:25, 9 September 2026 (UTC)
How strange. When I go through RecentChanges for newcomer tasks, I find that most of them are helpful, and some cause no real harm even if they're unnecessary. I find that only a small minority are actually "incorrect". WhatamIdoing (talk) 18:55, 10 September 2026 (UTC)
How true is that if you skip link suggestions and only look at revise tone or the templated tasks? There's a lot less uptake on the templated ones, but when I do see an expansion done it often boils down to "more words must be good". There are occasionally good ones, but out of all the ones I've seen (not actively looking for them) they've been few and far between, from editors who seem competent enough that they would have done fine without the tasks. ChompyTheGogoat[Bleat|Munched] 19:01, 10 September 2026 (UTC)
Special:Diff/1374235678: The new URL works but the edit itself is promotional puffery (e.g., "a base camp" becomes "providing protection to allow them to rest and strategize)" that also changes meaning (the walnut trees got lost in the edit, RIP walnut trees)
Special:Diff/1374235831: Gets rid of low-hanging fruit but also changes meaning, the original text did not imply the battle was "swift" or rule out it being slow
That's a 20% hit rate. Gnomingstuff (talk) 05:59, 11 September 2026 (UTC)
I'm not sure I agree with all of your assessments.
I defer to you about the AI, but I think it is a very slight improvement.
I agree with you; it's a clear improvement.
I defer to you about the AI, but I think it is an improvement in terms of framing the religious claims as religious claims rather than facts in wikivoice.
I agree with you (pointless at best).
The source didn't support the claim about walnut trees (or "base camp", though that might be within the range of Wikipedia:Use our own words). Also, the source does support a claim of shade, safety, and strategizing. Therefore this is an improvement that makes the article stick to the source.
This is a description of how a soldier earned the Victoria Cross for Australia. A "promotional" tone should be expected. You don't earn a "decoration for according recognition to persons who in the presence of the enemy, perform acts of the most conspicuous gallantry, or daring or pre-eminent acts of valour or self-sacrifice or display extreme devotion to duty" by doing things that can sound boring.
This edit got rid of an unencyclopedic exclamation mark. I'd rather have the one extra word than the exclamation mark.
The main problem here is that the paragraph is unsourced, so it's not easy to determine whether the "swift" claim is verifiable. I wouldn't be surprised if it were true, however.
Can you take another look at that? That edit turned 117 words into 74 words, but your note says it's wordier.
By "wordier" I mean that Cottage restoration has led to a renewed urban environment and overall visual aesthetic. is no different in tone than Most of the old cottages have been fixed up, so much so that the area has a newer look than it did just ten years ago except for the "bigger words," and arguably it is worse because it now has an abstract, promotional, real estate brochure-like slickness.
As far as changing meaning, if someone is "revising tone" in a way that changes the factual meaning of a sentence, and gives no indication that they understand that they are changing meaning (or worse, give an indication that they didn't, as with calling factual changes revised language to be more concise) then they didn't understand the task, and any improvements are basically accidental. Gnomingstuff (talk) 19:03, 11 September 2026 (UTC)
That reduced a 26-word-long sentence to a 13-word-long sentence. That's the opposite of wordier.
I think the new version has a more formal tone than, e.g., "fixed up". WhatamIdoing (talk) 23:17, 11 September 2026 (UTC)
We can't afford to let AI edits slide even if they are improvements. When newcomers start making a large number of formal/promotional sounding revisions across a wide variety of articles they likely have no subject matter knowledge on that's an immediate red flag. In some cases it's edit count gaming for nefarious purposes - in others, it just encourages them to keep inserting more slop. ChompyTheGogoat[Bleat|Munched] 06:58, 12 September 2026 (UTC)
The entire paragraph starting When newcomers start making... drives a coach and horses through assuming good faith. Cheers, SunloungerFrog (talk) 07:19, 12 September 2026 (UTC)
I said it's a red flag, not automatic proof of anything. AGF doesn't mean we ignore potential problems - it means we investigate further before taking action. Like leaving an initial warning, then reporting after they respond to the warning with more slop. Which happens on a regular basis. If they have a viable human written explanation then we let it go and move on. ChompyTheGogoat[Bleat|Munched] 07:23, 12 September 2026 (UTC)
I think that your making unfounded assumptions that newcomers don't have subject matter expertise on a wide variety of things is entirely failing to assume good faith. Cheers, SunloungerFrog (talk) 07:45, 12 September 2026 (UTC)
Ones that just so happen to pop up on newcomer tasks, including highly niche topics with poor sourcing (if any)? I did not say "Editors who are active in numerous subject areas must be using AI." It's a specific pattern that includes how the edits are composed. If I was still a newbie myself and hadn't seen it so many times I wouldn't think anything of it. The above example literally just happened, from one of the newcomers mentioned in this discussion that I was watching - before intervening - to see whether there would be additional proof. My spidey senses are rarely wrong. ChompyTheGogoat[Bleat|Munched] 08:04, 12 September 2026 (UTC)
I think that assigning a motivation other than doing their best to help ("edit count gaming for nefarious purposes") is the opposite of assuming good faith. I don't know if you've ever read Wikipedia:Assume good faith, but the main story there is a reminder to experienced editors (especially RecentChanges reviewers) that the people who are completely screwing up are genuinely motivated by a desire to help Wikipedia. They're not "gaming" anything, and they don't have "nefarious purposes".
In some cases does not translate to "all of the time". It means I have literally seen that happen on some occasions, meaning it was eventually proven. Some even turned out to be LTAs. I'm not assuming anything and I've had quite enough of the disingenuous misinterpretations. Do you have any relevant points to make that haven't already been discussed, or are you just going to continue arguing over increasingly pedantic minutiae? Because I know you aren't trying to imply we should allow AI slop simply because it comes from a new account. Good faith mistakes do happen also (albeit far less often), and my proposals attempt to minimize those as well so such editors don't get discouraged when they're reverted. ChompyTheGogoat[Bleat|Munched] 18:42, 12 September 2026 (UTC)
I am not assuming anything, I am classifying the edits as they exist in the world right now. At which point the need for assumptions is over, the edits are there and anyone can plainly see their quality or lack thereof.
More to the point I don’t really think it matters what the intent is, as this is a content issue caused not by any one person but by an overarching system. To which the only reasonable response should be to disable the system so it stops producing the problem. The purpose of a system is what it does, and this system is slowly rotting Wikipedia more and more every day. Gnomingstuff (talk) 00:12, 13 September 2026 (UTC)
Meanwhile, another AI slop spammer has now come along and edited the article. Note how they are just repeatedly blowing past the Paste Check warnings that are supposed to stop them from pasting things in; the critical oversight with that is if that someone doesn't care about your requesting them to not do something, warning them isn't going to help. Gnomingstuff (talk) 13:19, 9 September 2026 (UTC)
Of course. I've always said our target audience for newcomer support is the good faith editors who are WP:HERE. Those are who we want to retain. Ideally having well designed infrastructure can help with both - other things I've proposed like the AI/COI affidavits and newcomer patrolling would also help us identify and address the problematic ones. Some might learn and clean up their act while others just need blocked, but either way the sooner we notice and intervene the better.Btw, which edit are you referring to? I don't see that they've touched Angela (Trials of Mana). Ironic that a slopper is doing a better job at "revise tone" than any organic editors I've seen. ChompyTheGogoat (talk) 13:52, 9 September 2026 (UTC)
@ChompyTheGogoat Thanks for sharing your thoughts on the idea of reducing review redundancy. We have a software feature that could help with this, but it's currently not enabled on the English Wikipedia. On some other wikis, there's a 'patrol' button for each edit, so users can mark an edit as 'patrolled'. Other editors can then filter this edit out of venues like Recent Changes, and focus on unreviewed edits. There have been some discussions here about the feature, but no consensus to enable it. I'm interested in thinking about how we might be able to update the feature so that it could be enabled, if the community wanted to do so. I've been collecting notes at T409165 - would love to know if you have additional thoughts! —User:Samwalton9 (WMF)09:57, 10 September 2026 (UTC)
Patrolling isn't required for edits to be live, correct? My biggest suggestion would be to show the reviewed status on the feed even if someone chooses not to use it as a filter option. They can still decide whether or not it's something they want to check out for themselves. Nonbinary statuses and/or counts of reviews could be useful too. The concern about backlog is valid, if that's what the tool currently does - I don't think it's reasonable to expect all edits to be reviewed; it should just be additional information to help patrollers do what they're already doing. If a specific newcomer patrol is created (especially one focused on good edits/newcomer tasks instead of vandalism) I expect they'd have a significantly lower workload so it might be more realistic to clear their feed - or it might not. More flexibility for them to implement it however they find the most useful is most likely to be successful. My idea was something very lightweight that would just indicate another patroller has had eyes on it, but given the previous difficulties it may take more work to get RCPatrol into a form that EN editors are willing to pass. ChompyTheGogoat[Bleat|Munched] 10:16, 10 September 2026 (UTC)
Correct! This feature is different from Flagged Revisions (called Pending Changes here), which is the software that gates edits being live behind the patrol requirement. The native MediaWiki Recent Changes Patrol feature is all about the patrolling workflow, enabling users to filter out edits that have already been patrolled by others. Thanks, this all makes sense. I think this is a solveable problem with some software improvements, I just need to gain some clarity and put some definition on what changes exactly! Samwalton9 (WMF) (talk) 11:16, 10 September 2026 (UTC)
I think that plot summaries, particularly in fantasy or other forms of non-realistic fiction, are highly likely to correctly contain phrases that seem to have tone problems. The problem isn't the edit that was made; the problem is that the Revise tone task suggested improving that plot summary in the first place. —User:WhatamIdoing18:13, 10 September 2026 (UTC)
And adding one single exception (when some of them really do need to be fixed) doesn't change the fact that the task is inherently problematic, and even if it does correctly identify a passage that needs work it doesn't offer new editors the necessary support to actually understand how to fix them. This one sounds like it was ripped straight from the blurb on the cover, not actually a proper summary of the sources - which aren't cited in any case, so there's additional legwork needed to figure out what it really should say. ChompyTheGogoat[Bleat|Munched] 18:51, 10 September 2026 (UTC)
I don't agree that the task is inherently problematic. WhatamIdoing (talk) 18:57, 10 September 2026 (UTC)
That's obvious - as is the fact that you have no intention of ever changing your mind on much of anything. Plenty of other editors still consider this a problem, however. ChompyTheGogoat[Bleat|Munched] 19:04, 10 September 2026 (UTC)
I have no clue where to reply to this huge thread, but I wonder, instead of looking at the reversion rate of "revise tone" edits, has anyone studied the amount of "revise tone" edits that are targeted by more "revise tone" edits in the future? Going through User:7amad something's edits, many of the passages they changed had gone through like 3 or 4 rounds of "tone revision" that just changed various words to synonyms. Also, what's being done to prevent direct quotes from being included in these tasks?
I was a newcomer not that long ago and I agree the newcomer tasks are absolute crap. In particular the "add references" task is the definition of WP:BACKWARDS - it's almost impossible to find genuine references for 99% of the random garbage people stuck on a page in 2006, so no wonder most people probably just ask ChatGPT to give them a random, vaguely related link. After trying these tasks when I first made an account, I quit editing for several months.
Do you know what teaches new editors how to operate on Wikipedia? Asking other people. The only reason I know how to edit effectively is because I asked someone to teach me. Even reading every guideline and policy and WikiProject page I could get my hands on didn't show me how to do what I wanted to do - I had to get help from others. I have a baseless theory that a big part of the motivation towards LLM usage, both on and off Wikipedia, is the desire to avoid the friction of human interaction. Taking away more of that friction by creating these machine-generated tasks is misguided. Newcomers are served with a frictionless experience that teaches them nothing, then they are dumped unceremoniously into the worst interactions possible when other editors start reverting and templating them. There is no technological way around the fact that Wikipedia is a collaborative project and that Wikipedia's culture and craftsmanship can only be handed down through interactions from one user to another. Helping newcomers make connections with editors that do the same types of tasks or edit in the same topic areas would be a better way to use the technology than helping them avoid other editors while they unproductively shuffle text around. purringmaggot (talk) 20:11, 13 September 2026 (UTC)
Yep, finding my way to Teahouse early on is definitely the reason I'm still here.Thanks for pointing out something I'd also noticed but forgot to mention - the task doesn't seem to remove passages from the database after an editor makes changes, so others keep coming along and revising them again. So even when someone does actually make an improvement it could just be undone by someone less competent. And articles that have been tagged for newcomer tasks often have as bunch of them show up and start making multiple changes, which can leave the article worse than it started. ChompyTheGogoat[Bleat|Munched] 21:46, 13 September 2026 (UTC)
Also, what's being done to prevent direct quotes from being included in these tasks?
For whatever reason AI despises direct quotes in most non-reviewer contexts because it thinks they're somehow inappropriate and thus will attempt to paraphrase them (into slop) quite often (e.g. I also eliminated direct quotes except where necessary to preserve meaning, summarizing statements instead of reproducing conversational language). I suspect this is probably occurring here as well. Gnomingstuff (talk) 07:03, 14 September 2026 (UTC)
I shared with the WMF staff an example of a revise tone task that resulted in more promotional wording. The newer version contained one fewer word flagged by the bot, and so got a lower score. I suspect passages that go through a series of revise tone edits are ones where the 'promotional score' assigned by the bot decreases each time, but is still above the task-triggering threshold. (Maybe there is even flex for a slight increase in promotional score.) CMD (talk) 07:15, 14 September 2026 (UTC)
Is that what it's (theoretically) flagging - promotional tone? Someone else here said it was "wording that frequently gets changed", which is bizarrely vague. Lots of things get changed for lots of reasons. A lot of the ones I see aren't overtly promotional so much as awkward with poor grammar - more CE work than anything. ChompyTheGogoat[Bleat|Munched] 08:06, 14 September 2026 (UTC)
To my understanding the revise tone task assigns different words different levels of promotionality, and scores passages based on the concentration of those words. I don't know if or how it assesses overall grammar. CMD (talk) 08:59, 14 September 2026 (UTC)
Oy vey. I still !vote for removing at least that task entirely - it's just too problematic. Suggest Links is fine(ish) and the templated ones could be improved if people are willing to put the work in, but I think the underlying premise of Revise Tone is fundamentally flawed. We simply can't be relying on AI to determine whether or not certain phrasing is appropriate in a given context - let alone to communicate what the problem is to new editors for them to actually understand how it can be improved. They just read "revise=change something". (I can't remember if I've mentioned it before or not, but I have seen newbies make good improvements to phrasing - when they identify the problem themselves instead of following a task there.) Simple tasks with clear objective goals are the best way to ease into editing, and that's what we should be offering people who don't know where to start. Suggested Links has much higher uptake than any others for a reason - it's nearly impossible to screw up in any meaningful way. ChompyTheGogoat[Bleat|Munched] 09:45, 14 September 2026 (UTC)
@Chipmunkdavis, that's not my understanding of how the model works. You can read about it at meta:Machine learning models/Production/Tone Check#Model, and if you have in-the-weeds questions about it I can confer with my colleagues on the Machine Learning team (which built the model) to get you answers. Cheers, Sdkb‑WMFtalk 04:15, 15 September 2026 (UTC)
I don't see anything there that contradicts what I said. Anyway, I presume the team is already aware of the example I am talking about, it being long past. CMD (talk) 05:16, 15 September 2026 (UTC)
Hi @Purring maggot! Thanks for sharing those observations. I may be able to clarify a few things. First, we've programmed Revise Tone not to trigger on any quotations, so hopefully you won't encounter any issues there.
Regarding whether passages can resurface, the way the check works is that, after you have rewritten the passage it flagged, you click "recheck" and it checks whether the model still identifies a tone issue, and if so the check card persists. So because of that, if you've actually addressed the check, then by definition the model no longer identifies a tone issue and the passage won't be flagged again.
And on your last point, I agree that sociality is crucial to the Wikipedia model. We created the Mentorship program to help encourage this sort of educational interaction, but we know it has some issues and overall we're always looking for ideas. Do you have suggestions for how we could make newcomer tasks or other Growth features more social? Sdkb‑WMFtalk 04:12, 15 September 2026 (UTC)
Sounds like an awful lot of editors aren't bothering with that check (or don't care). See previous points.As far as mentorship, I don't think it's terribly helpful overall, but we really need some kind of standard for qualification so we don't have relative newbies advising other newbies with minimal oversight. I started helping at Teahouse early on, but only because it's a public venue where I knew more experienced editors would correct me if I made a mistake. The issue has been mentioned in passing before but was never actioned. ChompyTheGogoat[Bleat|Munched] 04:48, 15 September 2026 (UTC)
@Sdkb-WMF: I'm not sure the programming is working very well at avoiding direct quotations, either that or editors on revise tone tasks are just choosing a different part of the article to edit? Here are a number of recent diffs I've seen modifying a direct quote, tagged "revise tone":
As for increasing the social aspects of Growth features: I don't have a super great idea, just something tossed off that I'm sure would be hell to implement. Maybe there could be a kind of distributed mentorship, divided into a list of tasks or topic areas, where someone could say, for example, "I'm willing to teach someone the ropes of copy editing or biology articles". And then a newcomer that's editing suggested articles that need copy editing, or one that's picked biology as an area of interest, would get prompted on their homepage or somewhere "Ask (this guy) how to get started (doing copy editing, or working on biology articles)". Thinking of the concerns Chompy mentioned earlier about "newbies advising newbies", this is probably an even worse idea in terms of administering things since then we'd have to determine who actually has reasonable skills/experience in a whole bunch of individual areas. But I have seen conversations among mentors that suggest they feel a lack of direction in how to engage with their mentees, and that mentees don't seem to know how to engage with them, so I don't know, maybe some more nudging of newcomers in how to interact and what about would help drive productive interactions. purringmaggot (talk) 03:08, 16 September 2026 (UTC)
If we implement better standards for approving mentors we could allow them to self-identify areas of interest, provided no one objects to it on their nomination. Relevant WikiProjects could (maybe) also be involved in some way. ChompyTheGogoat[Bleat|Munched] 03:16, 16 September 2026 (UTC)
I just ran across this thread at the mentorship noticeboard which is like the mentor-led version of what I was talking about, recruiting and training newcomers to competently do a specific task. WikiProjects also came to mind for me but I don't have any solid ideas for incorporating them, especially given their wildly varying levels of activity. purringmaggot (talk) 03:29, 16 September 2026 (UTC)
Yeah, I wouldn't make their involvement mandatory, but maybe optional for those that are highly active to set what they feel are appropriate requirements for their subject matter and to maintain a list of approved mentors at the project page. ChompyTheGogoat[Bleat|Munched] 03:32, 16 September 2026 (UTC)
Followup thought: Could we implement some kind of automated assignment system based on these topic improvements once they go live (for those newbies that do set them)? ChompyTheGogoat[Bleat|Munched] 03:41, 16 September 2026 (UTC)
The main problem with "Ask (this guy) how to get started" is that new editors don't want to wait until "this guy" replies. WhatamIdoing (talk) 19:59, 17 September 2026 (UTC)
Which is why we have Teahouse. I don't think much of the mentorship program in its current state, but I do think it has more potential if the focus was on building a longer term collaborative relationships instead of just asking repetitive one-off questions, and actually pairing based on shared interests could help move things in that direction. ChompyTheGogoat[Bleat|Munched] 20:48, 17 September 2026 (UTC)
@Purring maggot, I followed up about quotations with the team, and it turns out I was mistaken above. We filter out block quotes currently but not common inline quotes. We've created phab:T439643 to document the issue and will look into it; feel free to subscribe to the task if you'd like to follow along. Cheers, Sdkb‑WMFtalk 23:58, 29 September 2026 (UTC)
Yet another case study in "newcomer tasks don't make sense to newcomers": one of the bots told me that I had to change a section on this article. Said "bot" was a Revise Tone suggestion, and they deleted commas because they thought they "had" to do something. Once again, this is one I just stumbled across, not intentionally looking for bad examples. ChompyTheGogoat[Bleat|Munched] 14:13, 15 September 2026 (UTC)
I am now trying to experiment with this system. Interestingly, scans were actually using a BERT model, which is usually outdated.
Before revising tone, it has a quiz which could be skipped. Then that quiz attempts to teach you how to revise tone, but I doubt that a 5-question skippable questionnaire with no policy attached to it could teach much of anything.
The results were not great.
There was a useful add link suggestion on the first article, but it ignored everything else, like WP:MOS (the article placed citations incorrectly, but then it only recommended a single link add over literally anything else).
Search engines that are expressly designed for searching web pages, documents, and images were developed to facilitate searching through a large, nebulous blob of unstructured resources. They are engineered to follow a multi-stage process: crawling the infinite stockpile of pages and documents to skim the figurative foam from their contents, indexing the foam/buzzwords in a sort of semi-structured form (database or something), and at last, resolving user entries/queries to return mostly relevant results and links to those skimmed documents or pages from the inventory.
I do not see how this is promotional. This is technical and relatively well-written.
Three years after the events of Ghosts 'n Goblins, the Ghosts have returned with Ghouls for revenge, initiating a mortal holocaust on the Princess' kingdom as beams of light struck through countless villagers. When Sir Arthur returns to the village, his rescue attempt was too late as his beloved Princess Prin-Prin also has her soul taken away from her body in front of his very eyes. Now it's up to the heroic knight once again to slay his way to the hellish castle to defeat the evil Lucifer and his legion of demons and restore the souls of Prin-Prin and every mortal.
This smells more of a copyvio than a basic promotional tone revise. There is absolutely no guide teaching how WP:PLOT works.
For my fourth article, it flagged half a section, but in reality, the entire section was problematic. It does not teach you that you should strip some parts instead of "revising tone". I blanked the section.
For the fifth article, some of the wordings were promotional. However, even after the recheck, it still said it was promotional, which was unhelpful. It proceeded to glitch by flagging the same paragraph twice and then flagged another paragraph before removing the flag for that paragraph. That was very confusing. It also did not manage to catch some subheading MOS issues, which was arguably more basic than checking for grammar. I do not think that that is included in medium nor hard mode.
The experience with this (knowing policy) was misleading and frustrating. When logging into my main account with &safemode=1, the articles I already fixed here somehow popped up again, only to suggest another article when it realized it was fixed. Sometimes, articles where I stripped the promotional claims ended up getting flagged with another hallucinated tag like the second article.
The promised newcomer feedback I gave a few weeks ago was here. Do not debate there or ping them (as they requested), discuss here and do not ping them. Thanks. LiteGlide (talk) 03:44, 26 September 2026 (UTC)
I have also remembered seen a repeating point which goes along the lines of patrollers need adrenaline (if I remember properly). However, the point of patrolling is about protecting Wikipedia, not about whether patrollers get that hit or not. Patrollers should not not patrol because it is boring. I am not going to debate this however, as I do not remember the details.
I will also be trying out medium mode, to see if it is any better. LiteGlide (talk) 03:52, 26 September 2026 (UTC)
At this point, using such a model at this scale to detect vandalism for patrollers (i.e. either "experienced editors" or EC) to scan would be much better. I am unaware if this exists. 16dvnk (talk) 04:03, 26 September 2026 (UTC)
I've been doing some recent patrolling after gaining access to WP: Interceptor and I've found the experience to be equal parts addictive and mindnumbing, which somehow feels like an appropriate balance. ChompyTheGogoat[Bleat|Munched] 04:24, 26 September 2026 (UTC)
I apologize if my comments here have come across as high expectations from volunteers. I know better than most just how steep the learning curve is, considering I've been here less than a year - my underlying concern is that the newcomer tasks don't help people learn. They rarely make sense even to those of us with more experience. I've seen a number of newbies make better edits on articles they choose to edit voluntarily than on newcomer tasks (including some I've used as examples here). And I'm still not against the overall idea of suggested edits; only their current incarnation. I don't believe that retention alone is an acceptable priority if it comes at the cost of other editors needing to do extensive cleanup. WP:CIR in general, and while we all know that newbies (and everyone else) will make some mistakes, any features targeting them should be optimized to help them overcome that learning curve and gain competence as quickly as possible. Some people just aren't ever going to be competent; it's not easy work, and I think it's less frustrating for everyone if those wash out quickly while the ones who are capable of learning make clear progress. A better mentor system might help with this, but overall it's difficult to know how to avoid wasting excessive time while also not being overly discouraging. (There's a reason I'm not a mentor myself.) I do want a better system that will help improve retention of the subset of newbies who have the potential to benefit the project in the long run, and I've made numerous suggestions to that effect. This user said if I am not sure of an edit, I would rather leave it to others, then to create more work which I think is a good mindset to have - it was also my own approach that I think helps with both competence and retention, because I wasn't making tons of mistakes and getting reverted right and left. I hung around discussion boards learning as much as possible and trod lightly in mainspace until quite recently. Some editors want to be more active to feel like they're contributing, and that's fine, but reverted edits usually don't do much in that regard, so we should be giving them functional tools that can help ensure their edits really are improvements. ChompyTheGogoat[Bleat|Munched] 04:55, 26 September 2026 (UTC)
LiteGlide, I think it's tripping over these phrases:
"expressly designed": an intensifier and in an encyclopedic context, usually needless; just say that it's designed.
"facilitate": buzzword
"nebulous blob of unstructured resources": redundant
"infinite stockpile of pages": unencyclopedic exaggeration to the point of falsehood (the number of pages on the web is large but finite)
"the figurative foam": unencyclopedic metaphor
"a sort of": casual, slangy phrase
Whoever wrote this would be welcome at Wikivoyage, where this kind of lively, casual tone is welcome. WhatamIdoing (talk) 19:45, 27 September 2026 (UTC)
Casual yes, but not overtly promotional. That's why this simple pattern matching really isn't great for determining intent. And it's a bit pedantic, but while the current number of pages is finite the potential for new additions is essentially infinite, which is definitely relevant to how search engines are designed vs dealing with a fixed database. ChompyTheGogoat[Bleat|Munched] 22:19, 27 September 2026 (UTC)
This is why the AI system is not exactly great for these tasks. 16dvnk (talk) 23:16, 27 September 2026 (UTC)
Did the software actually say the problem with this one was "promotional" tone, or were you just assuming that the Revise tone task is only promotional? When I checked an article a moment ago, it said "Other users often revise this kind of wording, saying the tone is unbalanced". "Unbalanced" ≠ "promotional". WhatamIdoing (talk) 02:36, 28 September 2026 (UTC)
I'm not going to attempt to find it again in the above mess, but I think someone (possibly from WMF) did say that's their intended purpose. ChompyTheGogoat[Bleat|Munched] 09:16, 28 September 2026 (UTC)
It said out loud that it was promotional. I don't remember the exact quote though. Really weird. 16dvnk (talk) 04:49, 28 September 2026 (UTC)
The blurb for the "Revise tone" task on the dashboard is Make articles more factual by removing promotional words. If you look at the tooltip -- which I doubt people actually do, but for completeness's sake -- the text is Help readers access trustworthy information by replacing promotional and opinion-based language with balanced content. Tone improvements are machine-suggested, and you decide whether to revise or decline each one.Gnomingstuff (talk) 18:01, 28 September 2026 (UTC)
Yes, we can do that locally. The devs provide a default text, but any admin or interface admin can override it. We'd need to decide what we want it to say, and produce evidence of a consensus (so the admin/intadmin will feel comfortable making the change).
Normally, we just change the English version and leave the translated versions alone, but it's also possible to change any language. The main thing to keep in mind is that TL;DR is one of the iron laws of the internet. If we turn a short message into a long treatise or a laundry list of all potentially relevant policies and guidelines, almost nobody will read, and even fewer will understand it. WhatamIdoing (talk) 13:53, 29 September 2026 (UTC)
Please tell me why you think it would be useful to change the description of the task when how it actually works is the issue. Literally what would that solve? ChompyTheGogoat[Bleat|Munched] 14:04, 29 September 2026 (UTC)
To recap: 1. The task is intended to identify promotional tone. 2. The task description says that it is intended to identify promotional tone. 3. The task is bad at identifying promotional tone.And you think removing the intended purpose from the description will fix this somehow? ChompyTheGogoat[Bleat|Munched] 14:12, 29 September 2026 (UTC)
Even if one subset of MOS:TONE violations is the main intention, it's okay for the tool to flag other TONE problems. There is no rule anywhere saying that the tool must only identify TONE problems that editors would label as specifically being 'promotional'. (However, keep in mind that the second example described above probably would be considered 'promotional' by most editors, since it appears to be a copy of text used in advertisements for the game.)
The task description ("Make articles more factual by removing promotional words") did not help the editor understand what needed to be fixed in the particular instances described above.
Did it actually do so correctly, or did it attempt to flag PROMO, fail, and happen to catch a different tone issue as a byproduct? Again, changing the description written by the programmers themselves does not change the underlying programming, and I fail to see how that would have any appreciable impact on user competency when even experienced editors are confused by it. You seem to be the only person obsessed with retaining this task and we keep getting dragged into the weeds over trivial details. I'm going to attempt to write up a summary/proposal based on the discussion up to this point, and I'd appreciate if you could refrain from continuing to drag things out. If anyone has specific input that they think is relevant and hasn't already been mentioned that's still welcome. ChompyTheGogoat[Bleat|Munched] 17:44, 30 September 2026 (UTC)
Do we agree that both of the paragraphs quoted by the OP are actually problematic in terms of MOS:TONE? WhatamIdoing (talk) 18:44, 30 September 2026 (UTC)
I'd say there's room for improvement with the first, but I don't find it inherently problematic. Not a NPOV issue. ChompyTheGogoat[Bleat|Munched] 23:31, 30 September 2026 (UTC)
The first contains casual, chatty phrases ("a sort of semi-structured form"), which is not the formal register that should be in an encyclopedia article. It also uses a metaphor ("foam") instead of sticking to objective facts. It is a MOS:TONE problem. Not all TONE problems are strictly about NPOV. WhatamIdoing (talk) 00:11, 1 October 2026 (UTC)
Thanks for your explanations, but in general it is evident that the tool misled me. Also, the technical issues of the suggestions I mentioned were not addressed. And I have not even started testing "medium mode". 16dvnk (talk) 03:03, 1 October 2026 (UTC)
And maybe highlighting the problematic words in addition of the whole section might be better. I missed foam entirely, which may be my issue, but still. 16dvnk (talk) 03:04, 1 October 2026 (UTC)
I am not sure what the model wants to detect. Since the models are (probably) open source, I might take a look in the weights. 16dvnk (talk) 03:07, 1 October 2026 (UTC)
To be honest, using AI tools may very beneficial, only if you do it properly and with suitable disclaimers and education beforehand. Unfortunately, these staff who added them in does not understand the side of newcomers, does not understand which problems are actually easier to fix (like MoS), uses the AI improperly so that it hallucinates, except there is no warning (and expecting new comers to realize which are hallucinated, which are not, which defeats the point of the tool), provides misleading descriptions, and an improper rollout with a potentially contentious technology. Now, somehow we are the ones to debug this mess. Clearly, we need a refactor of the tool, but VPM is not bringing a solution. 16dvnk (talk) 12:29, 2 October 2026 (UTC)
And clearly this is improper given the very obvious glitches I mentioned above. 16dvnk (talk) 12:33, 2 October 2026 (UTC)
I thought I was going to do a detailed analysis like easy mode in medium, except it is not exactly great. I inserted a test link to the article (reverted), but the tool did not attempt to stop me. After I was done, there was no mention of if what I have done was correct. In the guide (which is not even a quiz, just a broad and confusing manual of no mention of any policy, not even a nutshell), it was unsurprisingly skippable and required a remote button press. And the guide did not link to anything, even though these were supposed to be harder. I also do not see how somehow flawlessly revising promotional tone could somehow unlock you to source in medium mode (marketed as "After you have completed some easy edits." which is completely illogical). Medium mode was not useful at all and was vague. One of the regular users that use this, Idr888, once accidentally inserted a new citation with author "wpadmin", but the tool somehow did not flag it. They were confused but assumed it was correct. I later fixed it, but if I did not randomly stumble across that and taught then, who knows how much more broken citations would be inserted. Hard mode next, and I am not expecting any better. Thanks! LiteGlide (talk) 12:56, 2 October 2026 (UTC)
What exactly are you expecting this tool to do?
What it does it:
Finds an article that needs some work.
Tells you what the perceived problem is.
Asks you to fix it.
It sounds like you're expecting it to evaluate your changes to see if you did the work correctly. WhatamIdoing (talk) 18:44, 2 October 2026 (UTC)
You also say that it does not provide you with any warning. The Revise Tone task says "Help readers access trustworthy information by replacing promotional and opinion-based language with balanced content. Tone improvements are machine-suggested, and you decide whether to revise or decline each one." That last sentence sounds like a warning to me.
The decision about which tasks are easy/medium/hard was made by the community. The classifications may well be wrong, but it's based on the type of task (e.g., adding links is easy, adding sources is medium, expanding stubs is difficult). There is no attempt to evaluate an individual article. Adding links is always "easy" (even if it's actually difficult for that particular article), and expanding articles is always "hard" (even if it's actually easy for that particular article). WhatamIdoing (talk) 19:01, 2 October 2026 (UTC)
Thank you for the challenges. To clarify, I was not trying to attack the tool; I was trying to show what areas needed
improvement.
Hallucinating means that the tool puts false information in a page. Both my understanding and the link you added contradicted your point.
Article: a response generated by AI that contains false or misleading information presented as fact. Additionally, the BERT model is not Symbolic Artificial Intelligence.
Either way, debating if the term is right does not matter. What matters is that it is consistently producing false positives.
Tone improvements are machine-suggested, and you decide whether to revise or decline each one. That wording does not read like a warning. It just says that the suggestions are from a machine and you decide if you should fix it or not. That is also tucked at the last sentence of a greyed out paragraph. After you are in the experience, it does not remind the newcomer of the relatively high error rate.
The classifications may well be wrong, but it's based on the type of task (e.g., adding links is easy, adding sources is medium, expanding stubs is difficult). There is no attempt to evaluate an individual article. Adding links is always "easy" (even if it's actually difficult for that particular article), and expanding articles is always "hard" (even if it's actually easy for that particular article).
Which is why it is misleading for newcomers which has no way to know that. The skills between easy and medium does not transfer.
It sounds like you're expecting it to evaluate your changes to see if you did the work correctly.
I am expecting it to have less false positives, do a basic check to see if the sources attached do not introduce errors, and point newcomers to actual policy.
Once again, I need to reiterate that the attempts here are to improve the tool, and I do not intend to "grill" the system. Thanks. 16dvnk (talk) 02:49, 3 October 2026 (UTC)
You gave two examples of paragraphs that the Revise Tone tool "suggested" might need to have the tone corrected. In both cases, the paragraph violated MOS:TONE and actually did need to have the tone corrected. Where, therefore, is your evidence of false positives? All I'm seeing is evidence of PEBCAK – that is, the software correctly identified a real problem, but you didn't happen to understand the problem (which isn't a problem, overall; we all have our strengths and weaknesses, and Wikipedia editors generally manage to find a way to work on things they're good at instead of the things they struggle with). WhatamIdoing (talk) 04:06, 3 October 2026 (UTC)
The tool says "promotional", not MOS:TONE. This false positive means the model said "promotional" while the text was not promotional. While the text has issues with other WP:TONE issues, this is not what the narrow scope of the model was supposed to flag. Newcomers may see it, see that it is not promotional, and just skip because they are unaware of policies like WP:TONE. The text is not extremely bad afterall.
Applying PEBCAK is ironic, as newcomers are users that do not yet know how things work. I am not sure if I am misunderstanding your point, but using PEBCAK reads as "the user is wrong; the tool is right". But the whole point of the tool is for people who cannot yet be right.
Now, other than narrowing down the scope to "positive or false positive" (or some minor imprecise usage in my wording), let us widen back to scope to the actual problems, and not debating if they were positives or false positives.
The tool does say "promotional", but the tool also says "opinion-based". The tool also indicates the goal is "balanced content" and "Tone improvements". I realize that you didn't read (or at least remember reading) the rest of it, but the tool says more than just "promotional".
What the tool says, in part of one sentence, on one screen is not as important as what it does. What the tool did is identify paragraphs that needed "Tone improvements". It's not entirely the tool's fault that you didn't recognize the tone problems (e.g., the straight-up copy/paste of advertising text – how much more "promotional" can you get than a word-for-word copy of the advertisement?) in these paragraphs.
I certainly do remember and do detect the all the issues of the prose. The issue here is that the sentence is not "opinion based".
At this point, you are arguing narrowly about whether a case is a false positive or not. I also find you not engaging with any other of my points. What we are trying to do is to identify potential weaknesses including the potential incompetence of newcomers. However, so far this has spiraled into a deadlocked debate about whether a sentence is a false positive or not. Keep in mind that we are trying to improve the tool, not pointlessly and endlessly arguing about such narrow matters.
And the prompt asking you to fix it writes "promotional" and no other mention. 16dvnk (talk) 15:51, 3 October 2026 (UTC)
the straight-up copy/paste of advertising text And I already wrote that in my initial report, if you missed it. Thanks. 16dvnk (talk) 15:54, 3 October 2026 (UTC)
I give up. I'm requesting speedy close at this point because there's no possible way this can be concluded in any useful manner when it keeps getting dragged out in endless pedantic bullshit. I'm over it. Leave all the broken tools forever and let everyone else clean up after them. ChompyTheGogoat[Bleat|Munched] 21:19, 3 October 2026 (UTC)
At this point, people have continued to repeatedly narrow the scope and ignoring other points I say. I do not find this constructive. In addition, I have made all my points I will need to make here. As such, I do not plan to reply. Please do not ping nor reply to me. To progress this further, bludgeoning further will not work. Either file an RfC or Phabricator task (or whatever else may work) of the bugs I have mentioned. Thank you for your precious time.
I can't help but agree. Pedantic bullshit apart, and all the arguing about semantics, one can clearly conclude that the WMF's tool designs and the mentorship onboarding scheme put more cognitive load on the new user than they lighten. Kudpung กุดผึ้ง (talk) 04:58, 4 October 2026 (UTC)
I just looked at a few Revise Tone suggestions. These mostly seemed to be simple hostility to words like "excellent", "famous", "quirky" and "perfect" without any regard to whether these were appropriate or not. In all cases, I decided they were reasonable and just dealt with a grammatical error which was much clearer.
What's not clear to me is whether declining a Revise Tone suggestion will stop it being suggested in future. Does this tool have any memory or feedback?
I don't think so, unfortunately. WhatamIdoing (talk) 20:33, 4 October 2026 (UTC)
That's quite broken then as it will keep looping back until someone makes a change. Tsk. Andrew🐉(talk) 07:37, 5 October 2026 (UTC)
And because many newcomers assume the tasks are valid they just change what it tells them to even if the change actually makes things worse. ChompyTheGogoat[Bleat|Munched] 13:16, 5 October 2026 (UTC)
Who do you expect to add it? The newcomers who don't understand the task in the first place? ChompyTheGogoat[Bleat|Munched] 21:01, 12 October 2026 (UTC)
@Andrew Davidson and @WhatamIdoing - Declining a Revise Tone task will remove that suggestion from the Suggested Edits / Newcomer Task queue permanently for all editors. (Admittedly this is a little confusing because there is different logic in place for Suggestion Mode, but that's an entirely different feature, that is currently not exposed to new editors).
I know this question is related to Revise Tone, but some related info about the "Add a Link" task: previously we had an issue where a newcomer might accept an "Add a Link" suggestion and if that edit was reverted, it might simply get suggested again in the future until the suggestion is declined. That shouldn't ever happen again because we've released this improvement: T429417 Add Link should not make a recommendation if one has already been accepted or declined (Limit an article to only one Add a Link suggestion). The Machine Learning team is also using revert data in the model training pipeline now too, so hopefully we will start to see further suggestion quality improvements with that work as well. KStoller-WMF (talk) 00:08, 14 October 2026 (UTC)
Thanks, I'm glad to hear it. WhatamIdoing (talk) 04:41, 15 October 2026 (UTC)
Wikipedia articles in need of updating?
I recently discovered Category:Wikipedia articles in need of updating, which has an extensive backlog; the earliest sub-catagory is from January 2009. Would working through the backlog be a reasonable newcomer task? These are more complex tasks than fixing typos, but they mostly center around verifying some specific fact so seem like something a relative newbie could handle. RoySmith(talk) 13:03, 19 October 2026 (UTC)
I think that might work. I think a common-sense response to "please update" would be "Um, I'm going to have to go look this up", which is exactly what we want to happen. WhatamIdoing (talk) 21:53, 19 October 2026 (UTC)
Wikipedia:Nobody reads the directions. You should never expect people to read two long pages before trying to help. It would be much better to give everybody a very brief summary and a link for the few who want more. WhatamIdoing (talk) 22:27, 19 October 2026 (UTC)
If you're going to keep dragging that out, why do we even bother having any at all? More complex edits require doing more work, and that includes reading how to do it correctly. WP:CIR, and editors who refuse to learn how to make well formed edits get sanctioned. ChompyTheGogoat[Bleat|Munched] 23:02, 19 October 2026 (UTC)
In point of fact, not only is that an essay, but it's talking about how to write guidelines. I'm fairly sure the intention was never for it to be used to imply we shouldn't inform editors about existing ones. ChompyTheGogoat[Bleat|Munched] 23:05, 19 October 2026 (UTC)
CIR and "Newcomer task" really don't belong in the same sentence. The whole point of newcomer tasks is to entice people who have never done this into trying it, convincing them that we expect them to screw up and then providing friendly guidance and education when they inevitably do. RoySmith(talk) 23:47, 19 October 2026 (UTC)
No one creates an account because of newcomer tasks - something else interests them and then they work newcomer tasks to gain experience and (hopefully) competence. I don't expect perfection from the start, but we should be providing people with the resources to learn, both to minimize their frustration from being reverted and to minimize the cleanup for experienced editors. I have said before and will continue to maintain that boosting editor numbers purely to boost editor numbers is not a useful goal; we want competent editors who make constructive contributions (of any volume), and the goal for newcomer tasks should be to get newbies to that point - not to retain those who have no interest in learning or following our requirements. We can't force anyone to read them, but we can provide them with resources and explain why they're beneficial for everyone involved. A summary and a link is a perfectly adequate way to do so (and precisely the kind of thing I've already suggested). But if they only read the summary and not the pages and go trying to insert new content with no experience doing so there's a significant chance they will get reverted anyway. I've seen the kind of "updates" articles from 2009 often need, and it's a hell of a lot more than just correcting something to the latest name or number based on an existing valid citation. This idea absolutely does have potential, but we need to be cautious about how it's implemented so the inevitable resulting cleanup work doesn't outweigh the benefits. ChompyTheGogoat[Bleat|Munched] 00:14, 20 October 2026 (UTC)
We should assume that that people will only read the summary and not the pages. And if you make the summary too long, then we should assume they won't even read that. The first half of this blog post looks like the standard UI industry view: https://alisodigital.com/why-employees-ignore-work-instructions-and-how-to-fix-it/ It's about 500 words long. How much of it will you read and remember? Could having more information about how typical people do and don't read the instructions change your POV on how other people interact with written instructions? WhatamIdoing (talk) 00:30, 20 October 2026 (UTC)
I'll reiterate what I said above: if you're going to assume that no one ever reads directions, why do we bother having them at all? Either they're important and we should be trying to encourage people to read them, or they're useless and we should just resort to anarchy. The fact that many people don't bother is a problem we should try to solve (or at least improve), not just accept it. No one can ever become a competent editor if they refuse to read, so those are not the editors we want to retain. If they see the link and ignore it, make a mistake, get reverted, and then decide to go read after all - well, that's the stick side of the carrot and stick, but we should still try to offer the carrot first. ChompyTheGogoat[Bleat|Munched] 01:08, 20 October 2026 (UTC)
And your link there describes what the essay you keep referencing is actually meant to confer - not that have instructions is pointless, but that they need to be written better so that more people are able to digest them. I don't disagree with that in any way. We need more learning resources in more formats for the huge variety in editors with different learning styles, and I fully support any efforts to that effect. Personally I actually do learn better from text (something about devouring every book I've been able to get my hands on since about age 4?) I can read faster than most people speak and I retain it better. I loathe having to sit through a ten minute video that my brain will tune out instead of having text that I can skim to find the exact part I need in 30 seconds. I realize I'm an exception in that regard, and yes, and I still dislike getting bogged down by a tedious wall of text and may miss some parts during said skimming. Keeping guidelines concise - splitting even appropriate - with clear sections and the tl;dr "in a nutshell" are all helpful in that regard. If you'd care to volunteer to convert guidelines to other formats I'm sure you'd receive overwhelming support. ChompyTheGogoat[Bleat|Munched] 01:19, 20 October 2026 (UTC)
There is an old saying in software development: When all else fails read the manual. Yesterday, all my dreams... (talk) 22:42, 25 October 2026 (UTC)
And everyone knows that software manuals are written from the perspective of the dev who already knows how the thing works. Software devs and equipment designers have excellent ideas for software and products and write complex code but compiling a coherent manual for it is a separate discipline. Writing user guides and handbooks is an established field of study taught at undergrad and graduate levels usually as Technical Communication (or Technical Writing), as well as Information Design and UX, often as part of a broader media, Communication Science, or linguistics degree. Kudpung กุดผึ้ง (talk) 12:11, 26 October 2026 (UTC)
If all else fails, I will try to understand what you just wrote. Yesterday, all my dreams... (talk) 15:55, 26 October 2026 (UTC)
And did you continue reading the rest of the article? ChompyTheGogoat[Bleat|Munched] 03:32, 20 October 2026 (UTC)
Yes: It gave five reasons why ordinary people don't read the directions, and six ways they regularly recommend that their clients hire them to change it. WhatamIdoing (talk) 03:35, 20 October 2026 (UTC)
And where did they say "It's pointless to bother giving people instructions at all"? ChompyTheGogoat[Bleat|Munched] 04:05, 20 October 2026 (UTC)
I don't think it's pointless; that's why I have spent thousands of hours writing these pages. But anyone who expects people to read the directions is going to be disappointed many more times than they're pleased. WhatamIdoing (talk) 20:00, 20 October 2026 (UTC)
I find the instructions useful. From time to time I get involved in some admin task in an area where I'm not very familiar with current policy, so I refer to these pages for guidance. But in general, I agree that if you expect newbies to read (let alone understand) these pages before they hit the Submit button for the first time, you're going to be disappointed at lot. RoySmith(talk) 20:07, 20 October 2026 (UTC)
I think the point is that you need to make it so that the newcomers are forced to read the instructions without annoying them, which may (or may not) be an extraordinary task. 16dvnk (talk) 23:17, 20 October 2026 (UTC)
Instructions? You can lead a horse to water but you can't make it drink, but the main problem is the '...that anyone can edit' which was originally meant to mean articles, but somehow it got interpreted to mean 'anyone can write the PAGs and instructions'. So they do. And that's why it's such a confusing mess of 1,000s of pages of them, rarely written by experts in communication,and chopped and changed by anyone who comes along , especially vandals - just look at the history of the very example that was cited. 28% (that's more than a quarter) of all new users join Wikipedia with the sole intention of creating an article (according to the WMF) - but instead of helping them, WMF keeps conjuring up newcomer tasks that add to the cognitive burden rather than reduce it, so we get a massive backlog at NPP.. Kudpung กุดผึ้ง (talk) 18:15, 25 October 2026 (UTC)
My Advice for Newcomers is simple (whether they are starting a new article or trying to improve an existing one):
Research your topic before you write. Read lots of sources, and then summarize the key parts in your own words.
Cite your sources.
Don’t be afraid to make mistakes - we all do (especially when we are new).
Work with others, and be willing to compromise.
This should be enough to see any new editor through the first month or so of editing. The rest they will learn as they go… as we all had to do. Blueboar (talk) 18:46, 25 October 2026 (UTC)
There is just one snag: you have to get that message to the new user before they write their article - but nobody wants to listen to the simple solutions that have been repeatedly proposed since 2022. Kudpung กุดผึ้ง (talk) 11:40, 26 October 2026 (UTC)
Another idea: quizzes?
This is somewhat tangential since it's not a newcomer editing task, but maybe we could help encourage people to read policies and guidelines by offering quizzes on them, with badges they can display on their userpage for completion. These would be entirely optional for new users, but they could also potentially be utilized alongside sanctions for problematic editors that we're trying to help improve. For example, if someone gets blocked from mainspace for ongoing sourcing issues, having them to complete a quiz on WP:RS could be a potential requirement for an unblock request (imposed at admin discretion). Putting that knowledge to work in draftspace or via edit requests would help support their new understanding and ability to apply it as well.
I know many newbies would find this tedious and not have any interest, but I think there's a subset that does want to improve their skills and would be motivated by the ability to showcase them. I have a fairly good handle on most guidelines at this point, but as a terminal completionist I'd still enjoy the challenge of trying to check off every single one I could find. It would require volunteers to write them up, but WikiEdu might have some resources we could utilize, or at least suggestions on how something like this might be implemented. I still think we should liaise with them to improve learning resources on-wiki for editors who don't have the option of going through structured programs. They're the experts on this stuff.
ChompyTheGogoat[Bleat|Munched] 00:32, 20 October 2026 (UTC)
You could put together an example, if you wanted. Bawolff has an example for automatic 'grading' at User:Bawolff/Quiz. WhatamIdoing (talk) 00:41, 20 October 2026 (UTC)
Do you have a suggestion for a very simple guideline I could base it on? I'm not interested in putting a ton of effort in if no one supports this, but I'm willing to work up a quick one just to give people an idea of what I'm thinking. ChompyTheGogoat[Bleat|Munched] 01:23, 20 October 2026 (UTC)
Well, I did mean short, although I wasn't thinking quite that short! Certainly makes it easy though. ChompyTheGogoat[Bleat|Munched] 04:07, 20 October 2026 (UTC)
A few years back (5–10?), someone was doing some work on microcredentialing. If you wanted to develop it into a program, that would be a way to showcase success. WhatamIdoing (talk) 20:05, 20 October 2026 (UTC)
Nice, Wikipedia:Ignore all rules/Quiz is simple but effective. If I were to integrate that into newcomer onboarding, I would add an educational blub after someone answers, especially if they answer wrong.
We tested the quiz approach with the onboarding for Revise Tone. The quiz displays the first time newcomers complete a Revise Tone task, that way the learning feels relevant to what they want to do. When someone answers incorrectly we provide a succinct explanation. I was actually impressed with the completion rate, even with 5 questions, the majority of users who start the quiz end up completing it. [1]
The Growth team is also starting to connect more with WikiEdu and the folks working on the Wikimedia Core Curriculum as we make improvements to onboarding and the Newcomer Homepage.
As we update the Newcomer Homepage, one idea is to replace the "Get Help with Editing" section with something more engaging and educational than the current static list of help docs. I'm not sure exactly what this will look like, but I think it could include a section that is similar to the Policies and guidelines section on Special:PersonalDashboard. That page provides examples, but I love the idea of eventually having a short quiz for each of the 5 pillars. I think it's important to also link out to the policy pages for people who want to go deeper, but most new editors need to get started and get more invested before they are willing to read lengthy policy pages. Do you think integrating quizes directly from a main page (like the Newcomer Homepage) is the right approach, or do you think they need to be surfaced "in the moment" they are needed or the policy is violated? KStoller-WMF (talk) 00:32, 21 October 2026 (UTC)
I think offering them up front for editors who appreciate a more structured approach would be good. Since it's purely voluntary (if not related to sanctions) it wouldn't interfere with anyone who wants to just dive right into editing. I would integrate it in with however policies and guidelines are being linked initially - a "here's a fun way you can work through these pages and show off what you're learned" option. Specific ones can also be linked in other places they seem relevant. The overall idea is to try to address the "nobody reads the rules" issue by offering motivation, and hopefully improving retention when they have to actually think about the questions. Theoretically we could have one for every single guideline; it's just a matter of editors being willing to take the time building them (and creating the badges). Starting with the pillars would certainly be a good call. And I like the idea of linking specific ones that are relevant for newcomer tasks - you could have a brief summary in a pop-up when they start the task for the first time, then link from there to the full pages and associated quizzes. ChompyTheGogoat[Bleat|Munched] 01:19, 21 October 2026 (UTC)
My impression is that the concept of "show off what you're learned" is popular with a certain type of career-oriented contributor in developing countries, but not with the core community here. WhatamIdoing (talk) 17:10, 21 October 2026 (UTC)
Thanks. I really like the idea of having some core onboarding quizzes easily available from Home, but then also providing quick access to this style of learning material "in the moment" they might be needed (perhaps before a Suggested Edit, within an Edit Check, or even within warning templates). I added the idea and some quotes to this task:
I don't think we can work on this immediately, but it's definitely an area that I hope the Growth team can focus on soon! KStoller-WMF (talk) 23:42, 23 October 2026 (UTC)
Another tangential thought - maybe we could get some editors to work on improving the readability of P&Gs based on resources like the one WAID linked above. Break up walls of text into more manageable chunks, split them out as needed, write more "in a nutshell" blurbs, add bolding to emphasize critical aspects (I noticed they utilized that heavily in the article), add more visual aids, etc. That's in addition to potential A/V learning resources which I know have been discussed also. Those take longer to build though and we still need the text formats to be accessible as well. Some are already fairly good but others have lots of run on text that can be daunting even to us heavy readers.Spinning off from that, what about creating a new Wikiproject for all of these kinds of newcomer related things (wrapping mentorship under it as well) that would act as the local partners for the Growth team, addressing lesser changes like this on the ground, as it were? Having a variety of experience editors giving feedback and working collaboratively would help us have a broader perspective on different learning styles and what works best for different people. ChompyTheGogoat[Bleat|Munched] 01:37, 21 October 2026 (UTC)
Splitting policies and guidelines is really difficult. A couple of years ago, I suggested splitting WP:PSTS out of WP:NOR, and had two very smart, very experienced editors genuinely concerned that if we split the policy into two policies, then PSTS would somehow stop being a policy. (I'm chalking it up to them also being very busy and just missing it as they skimmed down the page, but if they were confused, then lots of people would be.) WhatamIdoing (talk) 17:13, 21 October 2026 (UTC)
Personally, I think PSTS stopping being policy would be an excellent outcome. People put way too much weight on "primary" versus "secondary" rather than things that matter more like reliability and independence. Anomie⚔ 18:38, 21 October 2026 (UTC)
I also would like to see PSTS go away, or at least be demoted. In some kinds of articles (i.e. scientific topics) primary sources are considered the best sources. Nobody is going to say (I hope) that a species of beetle is not notable because there's no secondary sources. RoySmith(talk) 19:33, 21 October 2026 (UTC)
If people could really figure out that Wikipedia:Secondary does not mean independent, I think that would solve a lot of these problems. Sometimes you need a secondary/analytical source (e.g., whether a new cancer treatment works), and sometimes you need a primary/original source (e.g., for a direct quotation, or to say that Queen Elizabeth died today).
I wouldn't expect splitting to be utilized too often, but there are some situations where it could definitely help. Maybe subpages could be utilized underneath a primary summary page to show they're all aspects of the same overall concept. ChompyTheGogoat[Bleat|Munched] 19:31, 21 October 2026 (UTC)
Break up walls of text into more manageable chunks, split them out as needed, write more "in a nutshell" blurbs, add bolding to emphasize critical aspects. We do this occasionally (at least those of us who know what were doing) but as often as not someone comes along who thinks they have a better idea and we get reverted. Rather than create a fuss, we just shrug our shoulders and move on, and it's back to walls of rambling text.
WADR, I think if the WMF were to take more seriously the voices of experience from the community, the entire management of newcomers would have been perfected and completed a long time ago, there would be less need for 100s , nay, 1,000s of pages of PAGs, and hardly any backlog at NPP; there seems to be a misunderstanding that because volunteers are, well, volunteers, there are no UX and UI experts among them. Instead, as far as I can see from my own experience and what the community is reporting in various threads on the VP, the newcomer help places a greater cognitive load on the new users than it reduces. Kudpung กุดผึ้ง (talk) 09:26, 21 October 2026 (UTC)
The other problem is that we tend to multiply help pages, rather than merge and consolidate them. WhatamIdoing (talk) 17:14, 21 October 2026 (UTC)
Why are nerds under-represented vs. jocks?
About 90% of the time I search WP for a scholar who wrote a seminal, highly-cited work, I find that the scholar has no article, yet some absolutely insignificant sports figure with the exact same name has a WP article..
WP sports projects have created very low requirements for athlete notability: Wikipedia:Notability (sports) ... e.g. the athlete just needs to play one season in some minor-league, or less.
The notability for scholars at Wikipedia:Notability (academics)appears to permit an article based on how much the author's work(s) are cited: "... show that the academic has been an author of highly cited academic work – either several extremely highly cited scholarly publications or a substantial number of scholarly publications with significant citation rates..."
Yet that simple test appears to be not utilized by the AfD people when assessing notability ... otherwise there would be a lot more articles on scholars. Are the Notability experts not applying an easy-to-compute "measure the citation impact of a scholar" metric when assessing notability? What is going on? How did the jocks achieve such dominance here in WP? </rant> Noleander (talk) 15:09, 12 October 2026 (UTC)
Just on the measure the citation impact of a scholar point, my understanding is that, unfortunately, it is difficult to come up with something that is easy-to-compute. Effectively one has to compare the citation statistics for the individual against comparable individuals in the field - having first decided what the field is! - and that is a manual task (see User talk:JoelleJay/Archive 4 §Tool for citation metrics comparison for a brief discussion that @JoelleJay and I had a while ago). It is not helped by the fact that many editors will not have access to Scopus or other citation databases to perform that manual task. Cheers, SunloungerFrog (talk) 15:48, 12 October 2026 (UTC)
Then the criteria should be relaxed. I can give 40 examples of scholars I've utilized in my articles that tremendously benefited humankind ... yet they have no WP article. To pick a random example: engineer Nicholas Schnitter who literally wrote the book on the history of dams. I shouldn't have to pay $$ for access to tool, then another 2 hours collecting justification that he meets the WP notability criteria. Noleander (talk) 16:17, 12 October 2026 (UTC)
In this example it is far easier to show that his book is notable; this only requires two book reviews, which popped up immediately for me on Google Scholar. Helpful Raccoon (talk) 10:31, 13 October 2026 (UTC)
Does the discrepancy arise at AFD, or at the step of article creation? Or both? Sports are tremendously popular and there is a whole ecosystem that produces and propagates stats, coverage, championships, and fandoms. I'm not disagreeing that there is an imbalance, just curious about what drives it. —Myceteae🍄🟫 (talk) 16:29, 12 October 2026 (UTC)
Speaking for myself: Over the years, I've started to create WP articles on about 20 great engineers and scholars, and I'll spend a minute googling them, and I quickly ascertain that there is no book about them. So, I realize I'm going to have to collect lots of indirect evidence of Notability. At that point, I give up, because I don't know how to gather the "measure the citation impact of a scholar" data.
If the "measure the citation impact of a scholar" are not going to FREE and FAST for editors, then Wikipedia:Notability (academics) should be extended to include the criterion:
The person wrote a book or journal article that is particularly important, foundational, and significant in their field.
I understand that could potentially be abused to create non-notable articles, but if the criteria are not expanded, WP will continue to fail to provide users with articles on thousands of important engineers and scholars. Noleander (talk) 16:42, 12 October 2026 (UTC)
Just because you mention books, another way in is WP:NAUTHOR. A couple of books with 2+ reviews each in scholarly journals usually demonstrates that the subject meets NAUTHOR. Cheers, SunloungerFrog (talk) 20:01, 12 October 2026 (UTC)
Yeah, with absolutely no evidence for this other than my feelings, I would assume that this discrepancy arises at the article creation rather than deletion stage. There are a lot more people who know and care about minor sports and entertainment figures than there are about all but the most successful and famous academics, the sources are usually more easily accessible, and the articles are often easier to write. Simply being notable is (at least theoretically) necessary but not sufficient to have an article on Wikipedia; it is also necessary to have a Wikipedia editor care enough to write the damn article. Caeciliusinhorto-public (talk) 11:51, 13 October 2026 (UTC)
Note since the discussion at Wikipedia:Village pump (policy)/Sports notability, participation-based criteria in non-championship/elite events does not have consensus support as a criterion for presuming that the standards for having an article are met, and they have been mostly removed from the sports-specific notability page. (I know of one example of a participation-based criterion in non-elite events that is still there; I was unable to get enough people to discuss the matter on the talk page to establish a consensus on how to proceed.) isaacl (talk) 17:51, 12 October 2026 (UTC)
I think you'll find that the number of editors prepared to spend their time creating article of sports figures (and actors, musicians etc) greatly exceeds the numbers editing in STEM. Also the articles are often easier to create. I think that is the primary barrier. Johnbod (talk) 18:30, 12 October 2026 (UTC)
And stubby articles can be mass-created. If I could find a chart of the 1959 line-up of the San Francisco Chinese Basketeers, then it's a few minues to set up a stub for the first one on the list and far less for the others, copying and adjusting that original articles. Such charts are common in sports, far less common in academia. -- Nat Gertler (talk) 16:16, 16 October 2026 (UTC)
Publications filled with people being nerds about jocks. I'm not sure conceptually how to be a jock about nerds. Conceptually stacked deck. CMD (talk) 23:58, 12 October 2026 (UTC)
So there are a few reasons that sports are popular for Wikipedia articles:
There are a lot of sports fans.
There are a lot of publications that people can pull from. This makes writing the articles for athletes much easier then academics. I have personally written a few biographies for academics, and hunting down 3rd party sources for biographical information is really hard.
There is a motivation to boost an athlete for marketing purposes. Not saying any article in particular is corporate, but I'm sure it happens.
Sports is a common special interest for Neurodivergent people, and they might make the effort to make an article.
Sports betting is a huge thing, so people gather information on specific athletes to help them feel more confident gambling.
There's also the fact that WP:NACADEMIC exists in part because your average scientist just doing their job doesn't generally get press. NACADEMIC itself is a fairly roundabout SNG as well, and requires some degree of being "read-in" to academia to come close to grokking it. —Jéské Courianov^_^vThrillerNight! 17:03, 13 October 2026 (UTC)
Perhaps the more balanced approach is that not every mid-tear, early career athlete ("sportsperson") should get their own article. Someone mentioned WP:NAUTHOR above. This produces an odd outcome where someone with 2+ notable books is notable and gets an article even if there is zero WP:SIGCOV of the person's biography, only book reviews. This produces articles like Sherry Argov, which is little more than a directory of her two books. Citation impact is sort of the academic's version of this but it's much easier to measure "has two or more books with standalone articles". —Myceteae🍄🟫 (talk) 17:16, 13 October 2026 (UTC)
The cases that really bother me are the scholars or engineers that wrote an important work that helped mankind through a major scientific advance or a safety improvement or an invention. The work might be recognized within their field, but no one really writes about the author. There are hundreds, maybe thousands, of unsung heroes that did wonderful work and they'll never get a wikipedia article. Noleander (talk) 17:17, 13 October 2026 (UTC)
Please do not let it bother you. Accept the fact that in today's world kicking or throwing a ball is more important to the public at large than obscure advances in quantum mechanics that made their flash drives possible. That is the world today, and Wikipedia reflects that. Yesterday, all my dreams... (talk) 20:53, 13 October 2026 (UTC)
We could raise the bar for how notable an athlete needs to be for coverage to something close to academics. For example, make it something closer to WP:NACADEMIC, so notability is more then just "was on team, had article written about them." GeogSage (⚔Chat?⚔) 19:07, 16 October 2026 (UTC)
Good one! Sigh! Donald Albury 18:30, 14 October 2026 (UTC)
Good lord, that is extreme. Carlstak (talk) 18:50, 14 October 2026 (UTC)
But there are also extreme cases of oblivion. Consider Jack Yuan at Sandisk. He was one of the three people who started a new industry but gets no Wiki page. And sometimes resistance to new pages is serious. Look at the talk page for Milos Ercegovac. The person who wrote that page was "out of breath" arguing about it. I managed to change the situation else he would have had no page although I am certain that your computer is using his work to add numbers right now. Yesterday, all my dreams... (talk) 22:11, 14 October 2026 (UTC)
One case in point I noticed is that Kyle Hill the basketball player is considered notable while Kyle Hill the science presenter is not. – MrPersonHumanGuy(talk) 13:25, 15 October 2026 (UTC)
I am sorry, but I would have supported that Afd. I am not at all sure how much of that man's content is correct. A better example would have been Jesse B. Wright whose fundamental work with Samuel Eilenberg changed our understanding of automata, long ago. . I heard that Wright just called Eilenberg out of the blue and gave him the idea. That was a seminal idea. He had done various other things at IBM research too. Maybe someone could start a page for him? And I am fascinated by the fact that he was blind! I have no idea how he could be such a good mathematician and not see. He deserves a page just for his seminal work with Eilenberg. Yesterday, all my dreams... (talk) 15:43, 15 October 2026 (UTC)
Because sourcing for academics is terrible. NACADEMIC proxies well for real world significance but produces terrible articles. Usually with an NAUTHOR pass you can mine the book reviews for biographical details. Even though a lot of things technically pass NACADEMIC, the terribleness of the sourcing dissuades article creation. PARAKANYAA (talk) 18:59, 16 October 2026 (UTC)
Another thing is people just people's interest in contributing to a topic. The book notability guideline is very, very lax, but relative to the amount of notable books there are very few contributing editors, so we don't actually have that many book articles. frequently, no one makes an article on Pulitzer Prize nominated books! It is madness! PARAKANYAA (talk) 19:02, 16 October 2026 (UTC)
I've written three articles about books, it is hard. Mostly, trying to hunt down 3rd party sources to describe the contents of the book can be a challenge. GeogSage (⚔Chat?⚔) 19:09, 16 October 2026 (UTC)
@GeogSage I love writing articles on books. And finding sources for articles on books. If you need help finding any sources feel free to ask.
But also you technically don't need secondary sources for the contents of the book, especially if it's fiction, WP:PLOTREF. They help when they're there but you can just cite the book itself. That's what we do for books/movies/etc. But usually for a nonfiction book summaries are in the reviews. PARAKANYAA (talk) 19:13, 16 October 2026 (UTC)
Thanks! I've been dinged before for citing the book itself, but could have just been an overzealous editor. Example of where deep diving the contents was tricky was Technological Transition in Cartography. There is plenty of content to verify the book as notably, but details about what is inside are a bit sparse or very general within these sources. How to Lie with Maps (same author) was much easier to find that kind of material. GeogSage (⚔Chat?⚔) 19:32, 16 October 2026 (UTC)
Citing the book itself for the contents is totally fine unless it's for interpretative stuff; I think "overzealous editor" is right. PARAKANYAA (talk) 19:42, 16 October 2026 (UTC)
"Why are nerds under-represented vs. jocks?" is the same question as "Why does every daily newspaper have a sports section, but none of them have an academics section?" WhatamIdoing (talk) 20:18, 16 October 2026 (UTC)
Well, to be fair, lots of newspapers have a books review section. We don't have articles on that many books. PARAKANYAA (talk) 20:31, 16 October 2026 (UTC)
Newspapers typically review a book once, which makes it difficult to establish that it meets the standard for having an article, while (due to fan interest) they cover sports figures and teams many, many times. isaacl (talk) 21:28, 16 October 2026 (UTC)
I'm not aware of any notability requirements that would benefit from a book getting reviewed more than once by the same publication - when counting notability-establishing sources for books I look at the number of unique review outlets. ScalarFactor (talk) 23:20, 16 October 2026 (UTC)
It being covered only once by one paper would not be any better or worse than it being covered by the same paper 20 times. PARAKANYAA (talk) 23:43, 16 October 2026 (UTC)
I once had a book that I wanted to write an article on. Somehow, it received three different full length reviews from three different authors over a yearlong period in The Independent, and no other paper. I could not write an article on it. PARAKANYAA (talk) 23:56, 16 October 2026 (UTC)
Sure, I wasn't referring to any such requirements. I was pointing out a difference between the sports section and the book review section, and also saying that with more coverage, it's typically easier to determine if a topic meets the standard for having an article. isaacl (talk) 02:42, 17 October 2026 (UTC)
Sorry, but I doubt if NY Times ever reviewed Topos Theory . I am sure 99.999% of their readers have not even heard of the term. Once again, we live in a world where kicking balls matters more than research. We must accept that. And given that Wiki is driven by crowd sourcing, ... you know the rest. Yesterday, all my dreams... (talk) 22:07, 16 October 2026 (UTC)
We lack articles on Pulitzer Prize for Fiction nominees! Those get reviewed in the NYT! PARAKANYAA (talk) 22:09, 16 October 2026 (UTC)
And did I mention science? We lack articles for plenty of mainstream, newspaper-covered topics due to lack of editing interest. For academic books the sources are all in academic journals. Academic journal book reviews are plentiful. Also not covered due to lack of editing interest. PARAKANYAA (talk) 23:44, 16 October 2026 (UTC)
WP:NBOOK is incredibly lenient. It took me about ~15 minutes to find more than enough reviews for Topos Theory:
Ioniţă, Cătălin (1979). "Review of Topos Theory". Bulletin mathématique de la Société des Sciences Mathématiques de la République Socialiste de Roumanie. 23 (71) (4). Societatea de Științe Matematice din România: 445–446. ISSN0373-2908. JSTOR43680483. Full access available to users of The Wikipedia Library.
And around half of that was formatting citations because toolforge:citer isn't playing nice with JSTOR right now.
In general, for fiction and non-fiction, high-quality and relatively-easy-to-access sources are in abundance relative to our current coverage of books. ScalarFactor (talk) 23:35, 16 October 2026 (UTC)
Sorry, I did not mean that there are no books on Topos theory. And if you had searched for topoi you would have had even more results. What I meant was that NY Times does not review those types of books. Yesterday, all my dreams... (talk) 23:57, 16 October 2026 (UTC)
In general my experience is that "serious"/academic nonfiction gets reviews in journals, while fiction and popsci/pop history/etc get reviews in newspapers & trade book review magazines. I normally wouldn't expect the NYT and a journal to review a book, but Ihaveremoveddozensofnotabilitytagsfrombookarticles by finding reviews in print sources like magazines and newspapers, all through sources in WP:TWL. ScalarFactor (talk) 00:06, 17 October 2026 (UTC)
I know y'all love to hate on AI, but I asked Claude "give me a list of the top 100 most notable scientists who do not already have articles in wikipedia". Amusingly, Claude declined to give me such a list ("I’d risk including people who already have articles or, worse, people who don’t exist") but did show me how to figure it out myself. Running Claude's query got me this list. RoySmith(talk) 20:32, 16 October 2026 (UTC)
Hate is a super nagative feeling. Please try disike instead. Yesterday, all my dreams... (talk) 22:18, 16 October 2026 (UTC)
My sparql-fu is weak to none, but I would imagine that would be trivial for somebody who knows it well. RoySmith(talk) 23:45, 16 October 2026 (UTC)
I also only speak baby sparql, but it looks like there were only nine more cut off by the limit. Which suggests to me either that enwiki's coverage of women in the National Academy of Sciences is pretty good, or that wikidata's is pretty bad. —Cryptic 04:19, 17 October 2026 (UTC)
I noticed the lack of women - and wondered whether it's the energy of the Women in Red project that has contributed to ensuring that current notable women scientists are getting properly represented in en.wiki! Well done, us. PamD 11:29, 17 October 2026 (UTC)
Hmm, I don't know about the US Academy, but the List of female Fellows of the Royal Society has been 100% complete since some years before this project was started. User:Edwardx told me had hunted down the last one in 2012 or 13 I think, and new ones get at least a stub on the day of the announcement. Johnbod (talk) 12:09, 17 October 2026 (UTC)
@Johnbod well, I did say "contributed", rather than claim all the credit for WiR! But, well done @Edwardx too. PamD 15:21, 18 October 2026 (UTC)
You are 300% right deep in your mind of course, as usual, but please do not pose a question that you know the answer to. It is because most readers are more interested in the kicking of balls than recent advances in cohomology. The idea is simple: if people do not understand something, there is no reason for newspapers to write about it, and it is not attention grabbing. As they say, if it bleeds it leads. But research does not bleed, so bus crashes come first. Wiki policies are decided by the public at large, so... you know the answer. Have a good day. Yesterday, all my dreams... (talk) 22:14, 16 October 2026 (UTC)
To move forward more productively - WP:NACADEMIC is one of our most inclusive subject-specific guidelines. The best fix is to make it even more inclusive. "The person's research has had a significant impact in their scholarly discipline, broadly construed" is a big vague, but in general it should be interpreted very generously, a gate wide enough to drive a truckload of academics through. Basically any academic who is publishing and is having others acknowledge or review or criticize their work should qualify. It's a little tricky because you can't rely on citation counts or the like anymore due to paper mills and the like, but hell, even some of the frauds are notable if for the wrong reason if they get caught. If we "accidentally" allow stubby articles on academics who appear to have published a textbook and journal articles but actually sold just 400 copies to their own students, and nobody cared about the journal articles, oh well, it's probably a good trade to start including the other lesser academics. I would say that we should consider removing "significant" from NACADEMIC criterion 1 to make it even more clear that if you're a publishing academic, we will cover you, even if the article is just a list of publications and basic educational affiliations. Academics aren't usually notable for their biography, they're notable for their work, so if their personal life is a mystery, that's fine. SnowFire (talk) 18:55, 17 October 2026 (UTC)
If we make it to relaxed, almost all of my friends (and I) would have qualified for a Wikipedia article in grad school. To get a Ph.D. in my program, most people published three articles in peer-reviewed journals. Most of us exceeded that minimum. I don't think any of us are notable though, and this is the situation in most academic departments. I think the main issue is that we are too relaxed on inclusion criteria for athletes. An average athlete is not notable, but probably has more written about them then an average person. GeogSage (⚔Chat?⚔) 20:40, 17 October 2026 (UTC)
Did you and your friends all become professors while still in graduate school? That would be pretty unlikely. So I don't think you'd qualify just from getting some publications out while a grad student, not even under my hypothetical loosened guidelines. (I am presuming we would apply it to people who became tenured professors, not just anyone publishing in academic journals.) SnowFire (talk) 23:44, 17 October 2026 (UTC)
According to Claude, "roughly 250,000 to 300,000 professors in the U.S. hold tenure". Claude also estimates that worldwide there's several million people in academia with appointments similar to what we call tenure in the US. Surely we're not positing that they are all notable? RoySmith(talk) 23:59, 17 October 2026 (UTC)
The fact of the matter is WP has far too many biographies of both athletes and academics, and far too many biographies altogether. In modern times the career trajectories of both are normally highly standard from a young age, and the bios rather boring as a result. I used to propose a moratorium on new biographies for say 6 months (except for the "urgently" newly notable), so that editors could get on with proper work on encyclopedic subjects. You can imagine the reaction to that. Far too many editors in the last decade confuse WP with a biographical dictionary. Johnbod (talk) 21:46, 17 October 2026 (UTC)
As opposed to what? What should we be writing articles on?
I've read plenty of print encyclopedias. Some of them are only biographical topics. Some of them are only organizations. Biographies are one of the major encyclopedic subjects. PARAKANYAA (talk) 01:43, 18 October 2026 (UTC)
Obviously we should have biographies, as we always have had. But, quoting from a talk I gave in 2011, which remains pretty much true: " I would make the following wild generalizations:
Our “top level” topic articles are generally weak, especially on abstract concepts.
Our articles on specific things, whether people, films, ships or species are often very good, and our coverage is usually very wide, even if many articles are pretty short.
So the more general and abstract the article subject, the worse our articles tend to be. This is the reverse of the pattern generally found in published reference works. It also means that some of our weakest work within a subject area gets the highest number of viewers. This is not good" Johnbod (talk) 01:52, 18 October 2026 (UTC)
Top level articles, especially abstract topics are misery to edit. One of many reasons that this is the case it can be incredibly difficult to stop people from coatracking on minor details about any topic. With broad articles you can basically justify shoving in any minor detail and attempting to stop people from doing this is like pulling teeth; people will die on the hill that the article needs to be 15000 words and include details from every single news article. Try to remove a few words cited to a passing news article from 2005 on a broad topic with dozens of academic books about it? Prepare for ANI (this happened to me once). Taken comprehensively basically all broad articles involve some degree of the dreaded original research in how you're presenting them, which, unless you are a subject matter expert on the topic, is usually bad. Versus articles on say, one movie or one person, where you can more or less recite dry facts.
Preventing biographies from being written would have 0 impact on the quality of these higher level articles, it would just make people edit less, because the kinds of people who edit articles on pop culture aren't the same people who care about improving articles on basic topics. You realize most people do this as a hobby, right? You couldn't pay me to write a broad topic article after what I've experienced. PARAKANYAA (talk) 02:16, 18 October 2026 (UTC)
And I do agree that it is an issue how bad our broader articles are, but really the only thing that would help this would be instituting stronger guidelines for dealing with broad articles/abstract topics, as the current lack of them opens up a lot of room for bad editing. PARAKANYAA (talk) 02:27, 18 October 2026 (UTC)
Not to digress too much, and I know this take will be unpopular, but top-level articles are on the whole less consequential than more niche ones. If Wikipedia did not exist people would still be able to find out more or less what they wanted to about those higher-level topics in half-a-minute of searching, whereas on more niche topics you might not have any other easily available compilations. In this sense Velites is actually more important than Roman Army, VITAL notwithstanding.
I'd have to dig through to find the research, but most readers are simply quickly skimming articles hunting for one or two tidbits of information; reading an article start-to-finish is very much the exception.
WP:Nobody reads the directions, and BLOAT is its own problem. I mean we're already in a situation where it is simply not possible for WIAFA to be met for broad topics if taken literally.
I agree those articles are a misery to edit, and have been for a long time. ~2026-46960-97 (talk) 03:40, 25 October 2026 (UTC)
Because it was easy for someone to connect sports databases to a script that would create articles. Articles about academics take more care and attention, so there are less of them. -- LCU ActivelyDisinterested«@» °∆t° 14:10, 18 October 2026 (UTC)
Apologies if someone mentioned it already, but AFAIK WP:NATHLETE also used to be an extremely low bar (one only needed to prove that the athlete had competed at a certain level and they were considered automatically notable) so I would imagine there are a lot of sportspeople articles left over from that time that would not be suitable if assessed under the current criteria. Athanelar (talk) 08:54, 20 October 2026 (UTC)
Predicting the next CTOPs/CCTOPs
I don't know if this is appropraite to ask, but does anyone have predictions on which topics could be potentially WP:CTOP/WP:CCTOP territories sooner or later? FMecha (to talk|to see log) 19:31, 21 October 2026 (UTC)
I did saw that, I wonder what other topics could be one. I admittedly had the topic of AI (particularly the generative/LLM kind) as one such candidate of being a future CTOP. FMecha (to talk|to see log) 02:51, 22 October 2026 (UTC)
Though I appreciate some might not find any harm in this type of idle chatter, personally I don't think it's a great idea to make any predictions about it (maybe if someone's planning to get involved with mediation or other efforts to defuse the situation, but even then I think doing it privately is better). It risks labelling editors interested in a given topic, and I don't think that's helpful to the collaborative process. isaacl (talk) 03:28, 22 October 2026 (UTC)
Should page protection requests be split by day instead of month?
I've noticed that Wikipedia is not easy to edit and now I understand more about what Wiikipedia volunteers have to go through and I have more of an appreciation of what they have to do than before. Drjoshcohen (talk) 08:50, 23 October 2026 (UTC)
Hi there,Thanks for your message.Is there anything you find hard that other editors could help with?Cheers. Equivalent-Text2598 (talk) 23:42, 26 October 2026 (UTC)
WP:LEADERBOARD and WP:MIA
[[WP:LEADERBOARD]] There should be separate list for those who make mass automated edits with tools as AWB than those who make manual edits. Even Twinkle Huggle STiki required individual edits not multiple edits in single click.
[[WP:MIA]]-- In past as editors were less so small number of edits were required. The editors should be listed as per total contributions and those with less contributions should be removed, Now very small number of edits are required for being added to this page.
Instead of apphabetical, listed as per total contributions.
Many thanks to everyone who has already submitted their scholarship applications for Wikimania 2027! Scholarships cover travel, accommodations, registration, and a daily per diem to attend the event in Santiago, Chile, from August 18 to 21.
Applications will be accepted for one more week. The final deadline is Wednesday, November 4 at the end of the day (Anywhere on Earth).
If you have any questions, please see the Scholarships FAQ on the Wikimania wiki, which has been expanded to include more detail on the review process. There are also recordings of the orientation sessions held earlier this month with tips on how to make the most of your online application.
It has recently come to light that Archive[.]today is serving malware (apparently ClickFix pages) when visiting certain PDF links. This has been discussed on Hacker News.
If you still use Archive[.]today to read paywalled articles, now is the time to stop doing so. Xacaranda (talk) 00:43, 29 October 2026 (UTC)
I hope it is appropriate to post this here—and if not, please take it down! I am trying to reach a broad cross-section of the Wikipedia community and not just editors who are already interested in Middle-earth pages. OrdinaryOtter(talk) 03:52, 29 October 2026 (UTC)
_screenshot.png){kind=link}