Wikipedia:Village pump (policy)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.

• If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
• For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
• If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
• This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
• For proposals for new or amended speedy deletion criteria, use Wikipedia talk:Speedy deletion.

See the list of frequently rejected or ignored proposals. Discussions are automatically archived after 7 days of inactivity. To keep this page's size accessible, discussions with more than about 100 comments should be split to a separate page.

« Archives, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

RfC: Merge nominations at MfD

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)

  Wikipedia:Publicising discussions is the answer to that.

  Publicising uninteresting merge proposals to the small number of MfD regulars is a poor substitute. SmokeyJoe (talk) 22:51, 16 August 2026 (UTC)

  No per Godsy. voorts (talk/contributions) 00:34, 14 September 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)

  Do the Wikipedia:Talk page guidelines not apply to pages within the Wikipedia namespace? Katzrockso (talk) 03:00, 16 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)

  RFCs can't be used for merge proposals. Chess enjoyer (talk) 15:44, 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. Chess enjoyer (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)

  I notified WT:RFC FaviFake (talk) 16:35, 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:

  1. Why adding this type of discussion will make MFD less efficient/effective;
  2. Why the structure of MFD is not appropriate for project page merge discussions; and
  3. 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 per my prior comment in the pre-RfC discussion, and others. silviaASH (inquire within) 22:59, 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). Sdkb ^talk 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. Chess enjoyer (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. Chess enjoyer (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. Chess enjoyer (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)

  Yeah right. We needed an RfC with hundreds of participants to wound down a single automated list of transclusions. That makes sense. FaviFake (talk) 18:19, 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 ^(TALK_CONT) 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. Sdkb ^talk 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. Sdkb ^talk 02:23, 25 August 2026 (UTC)

  What stops editors from using traditional methods of Wikipedia:Publicizing discussions? Katzrockso (talk) 02:25, 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. Sdkb ^talk 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. Sdkb ^talk 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. Sdkb ^talk 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. — Rhododendrites ^talk \\ 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. Sdkb ^talk 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.

B) Move it to MfD.

FaviFake (talk) 09:42, 5 September 2026 (UTC)

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)

RfC on late signatures in RECALL petitions

What should happen if an administrator recall petition receives its 25th signature after the 30-day period has elapsed, but before the petition has been formally closed?

1. a petition always fails if it has not gained the required number of signatures within 30 days of opening; signatures added after this 720-hour period are not reverted but do not count towards the threshold, even if the petition has not yet been formally closed.

6. a petition always fails if it has not gained 25 valid signatures within 30 days of opening; signatures added after this 720-hour period are reverted or struck and do not count towards the threshold, even if the petition has not yet been formally closed.

3. (status quo): "If a petition reaches the required 25 signatures within 30 days, it should be closed. [...] A petition that has been open for 30 days and has not gained the required number of signatures should be closed as failed."

2. [failed] a petition always succeeds if it gains the required number of signatures at any time before it is formally closed, even if this occurs after the 30-day period has elapsed.

4. [failed] keep the current wording, but add that it is within the closer's discretion to decide whether late signatures count towards the threshold at the time of their closure.

12:00, 2 September 2026 (UTC) (B and D struck, and F added, on 20:22, 3 September 2026 (UTC))

Survey (RECALL)

• speedy close and workshop a larger RfC around recall. There's no rush to open more limited RfCs, particularly when discussion is ongoing. voorts (talk/contributions) 13:08, 2 September 2026 (UTC)
• Of the options above, option A is unambiguously the best but I'm not in love with the wording. I would prefer an RFC that was more along the lines of the one I suggested in the WT:RECALL discussion (or a larger one that discussed RECALL as a whole). Thryduulf (talk) 13:15, 2 September 2026 (UTC)
  • Option F added below is superior to Option A (which is my second choice). I Oppose options B & D and am neutral regarding C. Thryduulf (talk) 19:55, 3 September 2026 (UTC)
• Speedy close per above. I think there are definitely some questions to be asked about this process, but I don't think the above options necessarily sum up the meat of what we need to be asking the community. Thryduulf's list at WT:RECALL looks closer to the mark. I think we should workshop a bit more before launching the RFC. Cheers  — Amakuru (talk) 13:31, 2 September 2026 (UTC)

  Since this RFC seems to be running its course and isn't being closed, I'll favour option F. It's clear and explicit, both in terms of what happens at the end and precisely when the end is (720 hours). Cheers  — Amakuru (talk) 14:53, 4 September 2026 (UTC)

  Per below discussion, I actually favour option F but modified - do not include the option to "revert" signatures after the 720-hour period (unless they're invalid for other reasons). Simply strike them, so that the person who added that signature, and indeed everyone else, is clear why that signature was not counted.  — Amakuru (talk) 10:09, 6 September 2026 (UTC)

• A, but not sure about whether to speedy close or not. --SarekOfVulcan (talk) 13:41, 2 September 2026 (UTC)

  Currently at F > E > A, oppose B/D. --SarekOfVulcan (talk) 20:00, 3 September 2026 (UTC)

• Option A. This doesn't need to be speedily closed. A larger RfC on the recall process is unnecessary.Katzrockso (talk) 19:41, 2 September 2026 (UTC)
• Option C - Any signatures added after the 30-day period should be reverted off lest there are questions down the road about whether or not signatures were valid. All other positions are non-starters. —Jéské Couriano v^_^v ^{Look out it's Jimothy!} 19:47, 2 September 2026 (UTC)

  That's not actually what option C says, though. It does not say whether the 25th signature should be counted if it was added after 30 days have passed; these kinds of closures do not happen immediately. It sounds like Option A is more similar to what you're looking for, at least in terms of determining the result.​ FaviFake (talk) 20:48, 2 September 2026 (UTC)

  I invite you to re-read my comment and then Option A. —Jéské Couriano v^_^v ^{Look out it's Jimothy!} 01:40, 3 September 2026 (UTC)

  Option C, in conjunction with talk page guidelines, does not permit reverting late added votes. Katzrockso (talk) 04:21, 3 September 2026 (UTC)

  With Option F now available I'm supporting that instead of C. —Jéské Couriano v^_^v ^{Look out it's Jimothy!} 14:49, 4 September 2026 (UTC)

• Anything but Option D as that is a drama nightmare waiting to happen. Gnomingstuff (talk) 20:23, 2 September 2026 (UTC)

  Update: Meaning F is OK too Gnomingstuff (talk) 14:59, 7 September 2026 (UTC)

• A without prejudice to a larger discussion on recall. Tazerdadog (talk) 20:30, 2 September 2026 (UTC)
• Option A Option F (second choice: A for the reasons below) The current wording (option C) is super ambiguous and does not say what should happen in the (admittedly rare) case where 720 hours have already passed but nobody got around to closing the discussion. Sure, we can say the discussion "should have been closed", but it has not been closed, and traditionally on Wikipedia late comments are considered by the closers in their closures. RECALL should be an exception to this rule due to it being intentionally deterministic.
  I find this comment in the RFCBEFORE discussion to be very well-written; it explains why this change is necessary:

  [...] I expect that if this ever gets tested, it will be a major drama, because there will be editors with very strong opinions on both sides of whether the petition succeeded or failed. As I also said earlier, the more I see conjecture about situations where the line between 24 and 25 signatures gets crossed late, the more strongly I feel about the need for a firmly articulated deadline.
  — User:Tryptofish 21:41, 23 August 2026 (UTC)

  FaviFake (talk) 20:52, 2 September 2026 (UTC)
• A, and strongly oppose B and D. I think A is an improvement over the status quo (C), because it eliminates ambiguity in cases where the formal close is slightly delayed and the 25th signature comes in during the delay. And this is something where we absolutely should not have ambiguity. When a 25th signature comes in, we cross a very serious line, and the current consensus of the community is 25 signatures within a month – not 25 in however much time it happens to take. I'm not seeing the need for a speedy close, because there has been pre-discussion, linked below, and I think the formatting of the RfC question adequately reflects that. However, I do think there needs to be a formal discussion if anyone thinks that it's OK to extend the petition open-time beyond 720 hours, or to do so depending on whether or not somebody feels like extending it. --Tryptofish (talk) 22:02, 2 September 2026 (UTC)

  Update: A and F are both equally fine with me. (As long as late signatures are not counted, I'm OK with either reverting them entirely, or with leaving them un-reverted but essentially ignored.) --Tryptofish (talk) 22:16, 3 September 2026 (UTC)

  Updating further, based on the most recent discussions, I think that modifying F for late signatures to be struck, but not reverted, may be the optimal way to close this discussion. I'm still good with anything in the A/F range, but striking does seem to be the best approach. --Tryptofish (talk) 19:12, 6 September 2026 (UTC)

• Support status quo for now. None of the recall petitions have encountered this late 25th signature issue yet, or anything even close to it, so let's just cross that bridge when we come to it. Some1 (talk) 00:05, 3 September 2026 (UTC)

  That sounds more like a disaster waiting to happen. FaviFake (talk) 09:20, 3 September 2026 (UTC)

• Support C as clear and unambiguous. This is a detail that should apply to any administrator recall system. Support for the still newish administrator recall system has not yet solidified (see current RFC comments & !votes). — Neonorange (talk to Phil) (he, they) 02:22, 3 September 2026 (UTC) —

  How exactly is that clear and unambiguous? It's the only option that doesn't specify what should happen in case of late signatures... FaviFake (talk) 06:46, 3 September 2026 (UTC)

  Well they don't count for one. I suppose it would be up to the closer to decide if those comments were moved to a sub-section, stay where they are with the number stricken, or some other option. --Super Goku V (talk) 08:30, 3 September 2026 (UTC)

  Some editors in the previous discussion have argued that the current wording means that late signatures should count because the discussion wasn't closed when they signed. This is the reason why the RfC was started. FaviFake (talk) 09:19, 3 September 2026 (UTC)

  I recall that there was a lot of debate over using should, would, could, shall, must, and any other words I missed, but I guess I didn't get the point about it. (Personally then, I think that is silly as the wording is clear that petitions automatically fail at the 30 day mark.) --Super Goku V (talk) 09:45, 3 September 2026 (UTC)

  You missed "may"! FaviFake (talk) 10:32, 3 September 2026 (UTC)

  That does not make sense to me, it does not say 25 signatures before being closed, it clearly says "25 signatures within 30 days" an explicit timeframe. If you wanted to go with a technicality, it does not stop someone counting any 30 day period so if you had enough last minute signatures to get 25 from day 1-31 instead of 0-30. KylieTastic (talk) 13:53, 3 September 2026 (UTC)

  The interpretation was first brought up starting from this comment in the original discussion, in case you're interested. I note that Some1 has !voted for Option C, so I really hope I didn't misunderstand or misrepresent their earlier comments. FaviFake (talk) 14:03, 3 September 2026 (UTC)

  To clarify: I don't believe every late 25th sig should count (e.g. a petition receives 24 signatures in the first week, then an inactive EC account randomly shows up to sign the petition after the deadline. In that scenario, that late 25th sig should not count). But I do believe there are certain situations where the late 25th sig should count (e.g. an admin subject to the recall petition does something controversial/questionable hours before the deadline, and because of that, more people start to sign the petition; let's say 5 sigs, including the 25th one, came after the deadline, but before the formal close. I don't think the closing admin should revert/remove/strike all 5 of those late signatures and declare that the petition has "failed", in that scenario). I don't like either options A or F, especially with the word "always". Each late 25th signature petition should be judged on a case-by-case basis, imho, but apparently I'm in the minority on this one. Some1 (talk) 23:21, 3 September 2026 (UTC)

  Thank you for the clarification! FaviFake (talk) 23:23, 3 September 2026 (UTC)

  If that scenario occurred and the deadline passed without 25 signatures, there's a high chance of an arbitration request being filed and a case accepted. I don't think the recall process needs to stretch to cover all eventualities. isaacl (talk) 23:29, 3 September 2026 (UTC)

  Same here that it doesn't make sense, but it does seem that some people hold that position. --Super Goku V (talk) 20:04, 3 September 2026 (UTC)

  Having a sliding window of time was rejected during the discussions that established consensus for the current process. Thus the petition ends at the designated time, and a new petition period can't start again for six months. isaacl (talk) 22:10, 3 September 2026 (UTC)

• No change (C) per Some1 and Neonorange. If we change the docs for every potential problem that we can imagine, we'll be constantly changing the docs. "Should" is the right amount of flexibility. Let's see how the status quo plays out at least once (preferably more than once) before trying to improve it. Or in other words, "if it ain't broke, don't fix it." Levivich (talk) 02:25, 3 September 2026 (UTC)
• Support A/C + Oppose B/D: We already have it so that you don't need to provide a reason to sign the petition. If someone really ends up at the last minute signing it, then they have the option to sign it without any comment and can explain it later if they really want to. Once the time on a petition elapses without 25 signatures, then the petition attempt has expired and is not in effect. We don't count late votes at RfA or for elections, so I fail to see why we would count late signers for petitions. (Personally, I don't care if the late signature is reverted or not.) --Super Goku V (talk) 02:45, 3 September 2026 (UTC)

  Supposedly, C means that someone can try to sign after 30 days has passed and have it count, which goes against my understanding of the Phase II RfC. So, I support A and Option E: "Petitions open for 30 days without receiving 25 valid signatures are closed as failed." --Super Goku V (talk) 10:13, 3 September 2026 (UTC)

  As of 17:33, 3 September 2026 (UTC), I am supporting Option A (still), Option E (still), and Option F (new) with no preference between them. I am still opposed to Option B and Option D. I am still thinking about Option C due to what others are claiming it says that I do not agree with. --Super Goku V (talk) 17:33, 3 September 2026 (UTC)

• A (edit: or F), which I'll claim as my idea. I disagree with Voorts about the speedy close because I think lots of small RfCs mean that some might succeed, whereas one big fat RfC tends to fail as no consensus.—S Marshall T/C 09:25, 3 September 2026 (UTC)

  For record purposes, I note that this unsigned proposal is one of the many, many proposals about our processes recently started by FaviFake. To my despair, the community continues to insist that signing your RfCs is optional, so the obfuscation is within the rules.—S Marshall T/C 09:30, 3 September 2026 (UTC)

  Yeah that rule is weird, I've never understood why not signing is allowed. However, I wouldn't say I have started many, many proposals; I've only started a few of these, and only the last one was a failure. It seems I did a good job with this one, since consensus to change the rules is starting to form but it wasn't obvious. And yes, I was inspired by your "720-hour" comment for the wording of option A! FaviFake (talk) 10:36, 3 September 2026 (UTC)

  As the preliminary statement is a neutral overview, and is copied to the central RfC page up to the first timestamp, some editors prefer just having a timestamp. That does not preclude signing a subsequent paragraph which makes it clear who created the RfC discussion. Most of the time, the creator also immediately expresses a viewpoint, and so their signature is evident there. In cases such as these where that did not occur, a short following signed paragraph would not be amiss. isaacl (talk) 13:32, 3 September 2026 (UTC)

• A - For any process that has a clear time limit and a clear vote threshold (not !vote), the time limit should be strict. — Rhododendrites ^talk \\ 12:18, 3 September 2026 (UTC)
• Option F "A petition always fails if it has not gained 25 valid signatures within 30 days of opening; signatures added after this 720-hour period are reverted or struck". Basically A now tweaked to add entirely; I would say C was OK, but if people really are reading it as votes after 30 days but before closure count I guess not. Strong oppose B & D as unfair to admin being recalled. KylieTastic (talk) 14:14, 3 September 2026 (UTC)
• Option F as apparently this needs to be said explicitly, option A is fine otherwise. B/D were rejected in the RFCs that created RECALL. Petitions have 30 days to get 25 signatures, any less and they fail. Petitions are not CONSENSUS based but numerical, just because a petition doesn't have a close doesn't mean it is still ongoing. At 30 days it either has 25 signatures or it has failed, any kind of formal closure doesn't change that. -- LCU ActivelyDisinterested «@» °∆t° 17:15, 3 September 2026 (UTC)
• Speedy close. The (surviving) options are all the same, and the difference is cosmetic. Even if A won, untimely signatures could still be struck. If F won, nothing would change because we can already strike and remove untimely signatures, and a not-struck/not-removed untimely signature (in the case that no one has remembered to strike it) has the same null effect as a struck/removed untimely signature. And if this is about a license to strike/remove over objections, that is too trivial an issue to even discuss, since, as stated, it's all the same. And both of these options are the same as C. Waste of time.—Alalch E. 23:15, 5 September 2026 (UTC)
• Speedy close per above. This RFC is a waste of time as there is nothing of substance being proposed. -- LWG ^{talk (VOPOV)} 23:51, 5 September 2026 (UTC)

  @LWG and @Alalch E. previous discussions (linked) have shown that these questions are not a waste of time as people have genuine disagreements about what the present wording means. Options A, C and F are not identical and while the differences may seem trivial, in the context that is explained in multiple of the comments above, they are actually not. It is simply incorrect to state that nothing of substance is being proposed. Thryduulf (talk) 09:07, 6 September 2026 (UTC)

  From reading the linked discussions, it seems that the only thing of substance under discussion is "In the event that a recall petition receives its 25th vote after 30 days but before anyone closes the petition, will the admin be recalled?" Since all three remaining options in this RFC seem to answer that question with "No, the admin will not be recalled in such a case" I don't see what else of substance remains to discuss. If I'm missing something please inform me and I'll consider changing my vote. -- LWG ^{talk (VOPOV)} 13:13, 6 September 2026 (UTC)

• F, though A is also okay. A single signature can have a large impact (4% of the total), so we should keep things consistent between petitions by fixing the duration regardless of when someone happens to come along and close it. Toadspike [Talk] 02:56, 22 September 2026 (UTC)

Discussion (RECALL)

• Isn't A and C the same but worded differently?– robertsky (talk) 12:14, 2 September 2026 (UTC)

  A is for some reason keeping signatures that are late on the petition for some reason, but they won't count. --Super Goku V (talk) 02:47, 3 September 2026 (UTC)

  Option C doesn't specify what should happen in case of late signatures, which a couple of editors interpreted as meaning that they should count even if they were posted after the 30-day period because the petition was still open. Option A clarifies that they should be disregarded.​ FaviFake (talk) 10:40, 3 September 2026 (UTC)

• Where is the WP:RFCBEFORE discussion? voorts (talk/contributions) 12:38, 2 September 2026 (UTC)

  Wikipedia talk:Administrator recall#Closing failed petitions and other discussions linked from there contain extensive discussion about the issue, but not about an RFC with this wording. Thryduulf (talk) 13:00, 2 September 2026 (UTC)

  This RfC seems to show a lack of understanding of why a time limit was imposed and open-ended petitions were rejected. voorts (talk/contributions) 13:07, 2 September 2026 (UTC)

  Voorts Since a few editors have disagreed with your suggestion to procedurally close this RfC, could you explain what you meant with this comment? It sounds like you have an opinion on the topic. FaviFake (talk) 13:52, 3 September 2026 (UTC)

  The time limit was imposed to prevent open-ended petitions. If you had had an RFCBEFORE discussion, that might have been pointed out to you. Now we've got a few half-assed options to !vote on. I don't get why there's such a rush to start RfCs. Creating a false sense of urgency is not a good way to create or amend policies, guidelines, or processes. voorts (talk/contributions) 14:06, 3 September 2026 (UTC)

  What false sense of urgency? The previous discussion was open for over two weeks and couldn't reach a consensus. These options are based on that discussion. The proposal is not "half-assed". FaviFake (talk) 14:13, 3 September 2026 (UTC)

  I meant half-baked, not half-assed. voorts (talk/contributions) 18:38, 3 September 2026 (UTC)

  Establishing consensus requires patience, particularly in a global editing community. I do think it's helpful to have that discussion in a broader venue such as this one, but it's possible that an ordinary discussion would have been enough regarding understanding the currently documented process. Now, discussing a change to the process may be worthwhile, but there's no urgency to making a change. I think it's unfair for a process change to take effect in the middle of a recall petition, so in my view, there's no deadline for a change. isaacl (talk) 22:24, 3 September 2026 (UTC)

  I agree with the last part; the result of this RfC should not affect the currently open petition. FaviFake (talk) 22:29, 3 September 2026 (UTC)

  I don't agree with that in principle. If the community reaches a consensus, then the community's consensus applies to all applicable situations. This isn't a court of law, and our policy and procedure pages are not statutes. WhatamIdoing (talk) 04:32, 4 September 2026 (UTC)

  How much discussion is necessary to initiate an RfC? Katzrockso (talk) 14:40, 3 September 2026 (UTC)

  The answer to that question is the same as always:

  "Multiple prior discussions may have been held, but these can be dismissed as having been insufficiently advertised, having happened on the wrong page, or showing insufficient participation (meaning any number of people not including the threatened power user). For example, the watchlist formatting change in 2012 resulted from an overwhelmingly positive, community-initiated, CENT-listed RFC at the Village pump (proposals), but, when it was implemented, these power users claimed that there was no RFC, no prior discussion, nobody knew about it, and nobody supported it."

  WhatamIdoing (talk) 04:35, 4 September 2026 (UTC)

  It felt like we were wrapping things up and were going to decide between an RfC or accepting the proposed wording. --Super Goku V (talk) 18:42, 3 September 2026 (UTC)

• If there had been a WP:RFCBEFORE maybe we would have the missing option with any signatures after the the 720 hours reverted or struck not left. Leaving late signatures not reverted or struck is just leaving it open to confuse people who just look and see 25+ signatures. KylieTastic (talk) 14:03, 3 September 2026 (UTC) strike as I missed there was some discussion Wikipedia_talk:Administrator_recall#Closing_failed_petitions KylieTastic (talk) 14:20, 3 September 2026 (UTC)

  I specifically crafted the wording "are not reverted" precisely to avoid having to deal with this minutiae. The actual controversial question is whether or not the 720 hour limit should be fully enshrined into the process page or if the current (and imo vague) wording is sufficient. Once we achieve consensus that these signatures don't count, then we can figure out how they should be handled, but that would not be controversial and can be decided at WT:RECALL. (Case-in-point, this was basically not discussed during the RFCBEFORE discussion.)

  "Not reverted" means that they're not deleted outright, as we generally don't do that on Wikipedia. We can then decide that they should be left exactly as-is, struck-through, moved to a different section, moved to the talk page, moved to a hall of shame, etc. But that's not controversial and doesn't have to be decided in conjunction with whether they influence the result or not. Do you think option A could be reworded, like "are not reverted entirely" or "can be struck or moved"? ​ FaviFake (talk) 14:22, 3 September 2026 (UTC)

  Yes, "are not reverted entirely" would be better. Then the advice to the closing admins could be to strike, move, or add something like "signatures below this point were not counted as made after 720 hours". The whole idea that 30 days does not equal 30 days baffles me. We rely on people to close things and although most such things are closed quickly sometimes there will be a delay, especially if it ends at the least active admin time (I guess around 06:00 UTC?). Or we just use a template/module/bot to mark as closed to new signatures waiting admin closure. KylieTastic (talk) 14:52, 3 September 2026 (UTC)

  I updated the text of option A and added a note, I think you can now rewrite your !vote comment to avoid confusing the closing editor :)   ​

  I agree, but I think this process is already very controversial (just look at the opposes in the RECALL that's currently open) and the last thing I would want is to have instructions that are not absolutely crystal-clear during the most crucial moments of a petition. FaviFake (talk) 15:11, 3 September 2026 (UTC)

  think this process is already very controversial [...] the last thing I would want is to have instructions that are not absolutely crystal-clear This is why in my draft I included those things you describe as uncontroversial and nitpicky - I felt it is desirable to have explicit consensus to avoid as much controversy as possible. Thryduulf (talk) 15:43, 3 September 2026 (UTC)

  You think that deciding the precise wikimarkup used to mark a signature that has been discarded by the closer in the extremely unlikely case that a petition receives its 25th signature late would be so controversial that it would need to be decided using an RfC at the village pump? FaviFake (talk) 15:55, 3 September 2026 (UTC)

  That's not what was proposed (it was strike, move to discussion, move to the talk page, remove or do nothing) but yes, I do think the choice to do any one of those could be controversial. Thryduulf (talk) 17:09, 3 September 2026 (UTC)

  Sure. But I'm not saying it's not controversial, I'm saying it's not controversial enough that it needs to be discussed in an RfC at the VPP. FaviFake (talk) 17:17, 3 September 2026 (UTC)

  There was a suggestion in the recall archives to use bots to close them which had a few opposes. Personally, I would say that most to all of the issues raised then would be resolved now by having a bot close the discussion for review at the 30 day mark and having an editor confirm if 25 votes were not received at the deadline or if a 25th signature just made it in and the petition had yet to be checked and closed. --Super Goku V (talk) 18:30, 3 September 2026 (UTC)

  That doesn't sound like a good idea. Nobody would be accountable if there were procedural errors like a blocked editor, as was suggested in the discussion you linked. FaviFake (talk) 19:43, 3 September 2026 (UTC)

  Huh? I don't see what you are meaning here. --Super Goku V (talk) 19:56, 3 September 2026 (UTC)

  If a bot closes a discussion, we can't contact the bot to ask it to reconsider its closure. As much as I like bots, we need a human in the loop in this case. FaviFake (talk) 19:59, 3 September 2026 (UTC)

  First sentence: That's the idea? Second sentence: We would. The reviewer. --Super Goku V (talk) 20:01, 3 September 2026 (UTC)

  So basically we have a bot give its unreliable reading of the discussion and then a second person (how would it be chosen?) would perform the job of the closer? At this point it's best to just have a bot place {{Closing|lock=yes}} on the page so that people can't use the "Reply" button while we wait for a real closer. FaviFake (talk) 20:10, 3 September 2026 (UTC)

  I was in the middle of giving a second reply, so let me copy and paste that as I bet it will clear this up. (Though, based on your usage of Template:Closing, I think you are starting to get my point.)

  Let me repeat what I said again at the end with more detail. I personally believe that the majority, if not all, of the issues that have been brought up here and elsewhere would be resolved by the following: When a petition is still open at the 30 day mark, a bot closes it per its programming with a note near the top that the discussion needs reviewed. (A brief note here that so far, every petition has closed early and never hit 30 days. All we want in this situation is for a bot to say the discussion is closed and have a notice at the top that a review is needed.) Within the next hour or so, an editor checks the discussion to see the state of the petition at the end. If there are not 25 signatures, then it should be easy for the editor to remove the review text and add a comment near the top that the petition has failed to gather 25 signatures. On the other hand, it is possible that the 25th person to sign the petition did so before the bot closed the discussion. In this situation, the editor will then proceed as normal and review the signatures to confirm that each signature is a valid one. If the editor finds that there were 25 valid signatures, then they validate the petition as normal and the editor is up for RRfA. Otherwise, if there is invalid signatures that brings the total below 25, then the petition is deemed deficient and the editor would add a comment near the top that the petition failed to gather 25 valid signatures. --Super Goku V (talk) 20:15, 3 September 2026 (UTC)

  Thanks! I still think the closer's job should be to actually close the discussion, but I would support making a bot that just adds {{Closing|lock=yes}} with a custom |comment= parameter saying the timestamp has passed and we're awaiting a closer. Disabling the "Reply" button in this way should at least make it less likely that an editor edits the petition, but it can simply be removed if the closer finds out that a signature was invalid and reopens the petition. FaviFake (talk) 20:31, 3 September 2026 (UTC)

  Your idea is functionally similar to mine, so I wouldn't mind that. Though, note in my plans that a bot would only run at the 30 day mark. If a signature is invalid, then the petition would not reopen due to the 30 days passing. --Super Goku V (talk) 21:52, 3 September 2026 (UTC)

  Personally, I'd rather not incur the cost of maintaining a bot for what has been a low occurrence event, particularly since there's no way for a bot to make an edit at a specific time, so it doesn't really solve the problem of having to examine when the signatures were added. Plus if this situation does occur, I imagine with all the interest there'll be sufficient volunteers checking the eligibility of all the signing editors and just waiting for the deadline to arrive. isaacl (talk) 22:17, 3 September 2026 (UTC)

  I think that we could do something similar with a countdown timer template such as Template:Days left. It won't be perfectly up to the minute, but it should give editors a notion of whether the deadline is close. WhatamIdoing (talk) 04:39, 4 September 2026 (UTC)

  If it is that much of a cost, then gotcha. --Super Goku V (talk) 05:30, 4 September 2026 (UTC)

  If you don't want to strike or revert late signatures, there's always the option of adding an explanatory note. WhatamIdoing (talk) 04:36, 4 September 2026 (UTC)

• Seems that 90% of editors are in favour of A and F but the options are almost identical. I suspect we will end up deciding that these signatures should be struck with a small explanatory note after the signature, an option compatible with both A and F (the signature is not reverted, which satisfies A, and it is struck, which satisfies F). Should we start thinking about closing this RfC? FaviFake (talk) 15:13, 4 September 2026 (UTC) —  Signature struck because it was posted after 15:16, 4 September 2026 (UTC). FaviFake (talk) 15:13, 4 September 2026 (UTC)

  I personally think it is important that we do strike them (by using strike out that is, not by removing them altogether) rather than just leaving them in place and not counted, because the latter (as is suggested by option A) would be confusing for those looking at the petition after the fact, particularly if the struck votes make the difference between a pass and a fail. Cheers  — Amakuru (talk) 15:47, 4 September 2026 (UTC)

  Yes, that's what I'm saying. A signature that is not reverted (A) can and should be struck (B), so by striking a signature we satisfy both options. FaviFake (talk) 16:01, 4 September 2026 (UTC)

  I agree. KylieTastic (talk) 17:23, 4 September 2026 (UTC)

  An additional benefit of striking is that it is less likely to be reverted by a confused editor who thought that the signature had been deleted by mistake. --Tryptofish (talk) 18:18, 4 September 2026 (UTC)

  Good point! FaviFake (talk) 09:20, 5 September 2026 (UTC)

  That's fine as long as that's what's implemented, and the new text should make it clear. Option A does not say this though, it says "signatures added after this 720-hour period are not reverted but do not count towards the threshold", which on its own does not give permission for anyone to strike a signature and actually rather implies that they should not. Option A is IMHO clearly not the same as option F for this reason. Cheers  — Amakuru (talk) 09:59, 6 September 2026 (UTC)

  really good point, whatever we pick should be as clear as possible Gnomingstuff (talk) 15:02, 7 September 2026 (UTC)

  (Incidentally, I think I missed one aspect of option F before - it says "signatures added after this 720-hour period are reverted or struck"... I actually don't support that verbatim, I think the reverted part should be removed, so the new wording simply says "signatures added after this 720-hour period are struck"". I suspect that sentiment is what you guys also favour based on the above comments...)  — Amakuru (talk) 10:05, 6 September 2026 (UTC)

  I actually do support F verbatim, including "reverted or struck". Thryduulf (talk) 10:11, 6 September 2026 (UTC)

  I stand by my opinion that all of this is irrelevant to the actual question which led to the RfC, which has long been resolved. What we do with the signatures doesn't matter, what matters is whether they count or not. This situation will likely never happen in the first place. FaviFake (talk) 10:12, 6 September 2026 (UTC)

  While I do still support my original F as "reverted or struck" I think the consensus here is leaning for a compromise of just struck. KylieTastic (talk) 13:27, 6 September 2026 (UTC)

  I feel bad for the closer of this, but I am fine with this compromise. --Super Goku V (talk) 23:56, 6 September 2026 (UTC)

  Might be best to let it run at least a full week or two before seeking a closer, but I agree that it appears to be between the two options and that both together might be ideal. --Super Goku V (talk) 21:55, 4 September 2026 (UTC)

TAs overwriting redirects

So TAs aren't permitted to create articles in mainspace, only drafts which then get submitted to AfC. But they can overwrite redirects, which seems functionally the same (ig they can't troll with article titles)? Should that be allowed? What prompted this was looking at Axios512 (talk · contribs)'s creations and seeing IPs had overwritten a lot of the redirects they'd made, I don't know if these were socks but it does still look like something that can be abused to mask authorship and avoid WP:G5 deletions Kowal2701 (talk, contribs) 11:36, 14 September 2026 (UTC)

AIUI when a redirect is removed, the new article appears in the Special:NewPagesFeed queue for Wikipedia:New pages patrol to review. Therefore such pages aren't going to be overlooked. A look at RecentChanges shows that this happens a handful of times per day, that about half of them get promptly reverted, and some others get reverted fairly soon. But a few survive, and that's okay. WhatamIdoing (talk) 03:56, 15 September 2026 (UTC)

See Wikipedia:Village pump (proposals)/Archive 206#Proposal: extend ACPERM to IP editors overwriting redirects, which was derailed mainly due to implementation concerns. Extraordinary Writ (talk) 04:15, 15 September 2026 (UTC)

• I think this is fine per the previous discussion. Crouch, Swale (talk) 18:24, 16 September 2026 (UTC)
• Great point. We shouldn't let logged out users create new articles. FaviFake (talk) 11:25, 22 September 2026 (UTC)

  Letting logged-out users create articles is why Wikipedia:Articles for creation was created in the first place. WhatamIdoing (talk) 15:58, 22 September 2026 (UTC)

  Yes. They should at least go through that process if they want to overwrite redirects. FaviFake (talk) 16:05, 22 September 2026 (UTC)

  I'm not convinced that's necessary. A one-size-fits-some bureaucratic process, such as blindly dumping all such articles into the AFC process, is really just going to create needless pain and strain on AFC. I suggest letting the NPP crew figure out which ones need additional attention. WhatamIdoing (talk) 16:24, 22 September 2026 (UTC)

  blindly dumping all such articles into the AFC process
  That's not what I'm suggesting. I'm saying TAs should not be able to remove a redirect, just like they're unable to create a new mainspace page. FaviFake (talk) 16:41, 22 September 2026 (UTC)

  Do you mean "We should set up something in the Special:AbuseFilter to prevent TAs from editing existing pages in ways that remove redirects" or do you mean "If a TA removes a redirect, we should just delete it because they're breaking The Rules™", or something else? WhatamIdoing (talk) 16:59, 22 September 2026 (UTC)

  The former! FaviFake (talk) 17:03, 22 September 2026 (UTC)

  The 2023 discussion on this shows a 50–50 split, plus concerns about whether it would have unwanted side effects (e.g., a TA might not be able to revert redirect-related vandalism). WhatamIdoing (talk) 18:40, 22 September 2026 (UTC)

  Good point. I guess we'd need to implement something like a 30-day window where a TA can overwrite the redirect. FaviFake (talk) 21:08, 22 September 2026 (UTC)

  So if the vandalism is older than 30 days, only registered editors can reverse it? Katzrockso (talk) 18:44, 23 September 2026 (UTC)

  Yes. I can't think of a better system right now. FaviFake (talk) 18:45, 23 September 2026 (UTC)

  Can we allow a TA to overwrite a redirect if their edit is a revert? That leaves open a workaround, but only one that's already available now. Certes (talk) 21:22, 23 September 2026 (UTC)

  Uuuu that's good! TAs can only remove a 30-day-old redirect using the undo function. FaviFake (talk) 21:54, 23 September 2026 (UTC)

Onus for maintenance templates

In the article Deep State, a user has placed the {{AI-generated}} tag on the article, with the reason field stating, Wikipedia:AI noticeboard/Archive 4#Quickdrew and possible AI hoax edits to contentious US politics topics (WP:WWT is useful). I found this to be less than informative, and so opened a talk page discussion asking what passages or sections are suspect so I could help review. The response has frequently been a variant of, "Use a tool and figure it out", including references to some nonstandard tools, and an insistence that the tag should remain.

My question is: who has the onus of identifying problem areas when it comes to maintenance tags? I note that WP:WTRMT specifies they shouldn't be removed until the identified problem is resolved, but what if the problem is never identified? Discussing with the editor is proving challenging, so I'm hoping someone can point me in the right direction here. EducatedRedneck (talk) 17:08, 18 September 2026 (UTC)

The person adding content always has the burden of substantiating it. voorts (talk/contributions) 17:10, 18 September 2026 (UTC)

This doesn't seem to be about content. What seems to have happened here is

• Editor A states an article includes AI-generated text by placing a tag on it
• Editor B looks at the article with the goal of cleaning up the highlighted problem, but doesn't see any obviously AI-generated content.
• Editor B asks editor A to clarify
• Editor A says "figure it out yourself" and repeatedly refuses to explain what the issue is.

That is, in my opinion, not acceptable. An editor placing a maintenance tag on the article should be required to respond to good-faith queries about that tagging. If they do not do that, and other editors are unable to see the problem, then those editors should feel free to assume that the problem no longer exists in the article and remove the tag.

In the case of AI, our policies are explicit that external tools must not be relied upon to determine whether a page is or is not AI-generated (although they may be used to assist in making a determination based on factors observed by a human). Accordingly it is not acceptable to require another editor to use an external tool to understand your tagging. Thryduulf (talk) 17:23, 18 September 2026 (UTC)

I agree. I think the burden of a maintenance tag is on the editor who places the maintenance tag - and I also think the editor who places a maintenance tag also should do some of the work to address the reason for the tag, especially if it may be something easyish to do (such as finding a citation, or nominating a page for deletion if there are no references). - Enos733 (talk) 17:32, 18 September 2026 (UTC)

Could we not use the word “Onus” for this? That term has a specific meaning here on WP, which does not relate to this situation. When there is a problem at an article, EVERYONE has a responsibility to help fix that problem. Placing maintenance tags is part of that process… but so is responding to questions when others are not clear as to why the tag was added. Communicate! Blueboar (talk) 17:50, 18 September 2026 (UTC)

Agreed. voorts (talk/contributions) 17:36, 18 September 2026 (UTC)

I don't think the tag is at all confusing here. The problem is very clear: a significant contributor to the article is suspected of inappropriate AI use, and we can only be confident that the article is free of AI-generated material once that editor's contributions have been removed. It seems to me that Kowal has explained this quite clearly on the article talk page, and it's not at all the case that anyone has to use WWT to see what parts of the article are problematic; all that is needed is to look at the diffs. It's not practicable to ask AI cleanup people to deal with the problems at the same time as they place the tag, since very often they are tagging multiple articles at once. Dionysodorus (talk) 17:38, 18 September 2026 (UTC)

To clarify, is it your understanding that this level of burden applies to all maintenance templates, or is AI cleanup a special category? Is that documented somewhere as a guideline, or is that a guidance gap that should be filled? Also, thank you for your response; I obviously disagree, but that makes a dissenting voice like yours all the more important. Thanks for taking the time to give your opinion and help clarify things. EducatedRedneck (talk) 17:42, 18 September 2026 (UTC)

In my understanding, the whole point of maintenance templates is to allow editors to indicate problems with articles that need to be fixed, but which the editor placing the template does not have the time or ability to fix immediately. If editors had to fix the article themselves when adding the template, there would be no need for us to have maintenance templates at all.

The fact that it is AI cleanup doesn't change the principle of how maintenance templates work, but the nature of AI cleanup does in practice make it almost impossible for editors involved in cleanup to deal with problems as soon as they see them, since the nature of AI cleanup is such that large numbers of articles often have to be gone through and tagged all at once, and the problems with articles are often somewhat complicated (as in this case, where multiple contributions from long ago need to be gone through and removed). Dionysodorus (talk) 17:50, 18 September 2026 (UTC)

Thank you for the detailed response. I really appreciate it!

I suppose I'm confused about the difference (or lack thereof) between performing the cleanup, which I agree is not practical to do, and identifying what must be cleaned up, which is something that I only believe is required when asked. (I.e., I place a POV tag on an article, and if someone asks me, "Hey, why'd you put this here?" then I need to explain at least some of which parts are NPOV or else let the tag be removed.) To be clear, I'm not demanding they do the work immediately (or there'd be no need for the tag), only that, when asked, they identify what portions are problematic. Otherwise, I could put AI-generated tags on any article, refuse to elaborate other than "It has lots of WP:AISIGNS", and the tag would stay even if nobody else could find any AISIGNS. This is why I'm so confused; can you point out where I'm getting mixed up? EducatedRedneck (talk) 17:57, 18 September 2026 (UTC)

But Kowal has actually explained to you exactly what the problem is. There is one user, Quickdraw, who has clearly been engaging in AI use across that user's contributions. That user has written a large part of this article. Therefore, someone needs to go through and delete all the bits of the article that Quickdraw has written, because they are probably AI-generated. Indeed, they are clearly at least partly AI-generated, as can be seen most clearly from the communication intended for the AI, cf. WP:COLLABCOMM, in this diff. There is a vast amount of this problem going on on Wikipedia, and Kowal is heavily involved in the AI cleanup process, as you can see if you look at WP:AIN. For this reason, the tag needs to be left until someone actually has time to deal with the problem. I might have a look and see if I can in a moment. Dionysodorus (talk) 18:04, 18 September 2026 (UTC)

Thanks again for responding. While I'm not convinced, I'm much more confident that leaving the tag was the right call. I feel that there's a big difference between "a user used AI and did a large part of this article" and "here are the diffs of their work that need to be reviewed." The first one I can't do much with. (That diff is over a year old, and I don't use many tools.) The second is something actionable by anyone. That said, your view is reasonable, and I see how you get there. Thank you again for taking the time to explain. EducatedRedneck (talk) 18:13, 18 September 2026 (UTC)

I feel that there's a big difference between "a user used AI and did a large part of this article" and "here are the diffs of their work that need to be reviewed."

It takes less than 1 minute to do this without tools. Here they are. This isn't even an especially hard case because Quickdraw's edits are concentrated in one period of time, and every intervening edit between the ones they made is either removing content or making cosmetic tweaks to it, so you can just compare the revisions before and after they started editing.

And I don't mean to be rude here, but if you're not willing to spend 1 minute looking at the edit history, then maybe you should just move on. Gnomingstuff (talk) 22:20, 18 September 2026 (UTC)

If you look at the top of a history page, there's a linked tool "Find edits by user". If you have an editor's name, you don't even have to look through all of the history page. WhatamIdoing (talk) 00:42, 19 September 2026 (UTC)

That's not a feature I was aware of. I'm not super technically proficient, as I'm sure you can tell, and reactions like this are making me want to help out less. I wanted to help, so I asked which parts of the article were suspected of AI use. I didn't need a list of signs, only, as I said repeatedly, some indication of which portions of the article need to be reviewed. Once I had that, I could have read through them, verified sources, etc. If they had issues, they could be removed. Otherwise, they could be kept having been determined to be good by a human.

You've provided that list. It took a minute, you claim. Less than the time Kowal2701 spent arguing. I don't understand why they didn't just do that. Frankly, what I'm hearing from you and them is that I messed up so badly, I should just not even try to help in this arena. That hurts, and I don't understand, but perhaps me not understanding is the problem. I'm sorry I seem to have aggravated you and them so. EducatedRedneck (talk) 00:49, 19 September 2026 (UTC)

I don't think anyone's blaming you for not understanding the processes around AI cleanup: they are a bit on the complicated side. However, what we are saying is that Kowal did in fact attempt to point you to the relevant documents, and that it is difficult for anyone to work effectively on this kind of cleanup without a certain amount of basic willingness and ability to look through diffs and that kind of thing. If you want to participate in cleaning up AI-affected articles in a way that is actually helpful, then you do need to be willing to do a bit of detective work in the page history for yourself.

In this respect, AI cleanup isn't really unique: after all, all forms of cleanup require some kind of technique or skill, for instance in finding and adding references, or applying the manual of style, or whatever. Likewise, in the case of AI cleanup, looking through the diffs for yourself is really the most basic first step for anyone who wants to clean up any given article. The most helpful thing you can do if you want to clean up an article with AI problems is to do that for yourself, and then to remove the problematic material, if you feel confident that you can identify the problem and know how to address it appropriately. If you don't feel confident doing all that, that's absolutely fine, but in that case it's most helpful if you don't raise too many objections that will take up the time of the editors who do understand how it works. Dionysodorus (talk) 01:38, 19 September 2026 (UTC)

Frankly, what I'm hearing from you and them is that I messed up so badly, I should just not even try to help in this arena

Not my intention, apologies that it came off that way. Otherwise can't really put it better than Dionysodorus above. Gnomingstuff (talk) 05:03, 19 September 2026 (UTC)

This is also a good meta example given the diff EducatedRedneck linked above. If you look at that diff, it shows that Quickdrew added the following to the article: Here’s a revised version that maintains neutrality by acknowledging that deep state allegations have varied in accuracy—some being unfounded conspiracies, while others reflect genuine concerns about entrenched power structures. So the fact that you are still "not convinced" tells me that one of two things has happened. Either:

• You didn't actually look at the diff
• You do not currently know enough about AI-generated text to weigh in on whether something is AI-generated or not.

Gnomingstuff (talk) 22:31, 18 September 2026 (UTC)

Can you link to the diff? I don't think I actually linked to any in this discussion. The only thing I linked to was a quote of the tag, which goes to an archive, which does not mention Deep State. EducatedRedneck (talk) 00:51, 19 September 2026 (UTC)

The diff was actually posted by Dionysodorus. You responded, "While I'm not convinced, I'm much more confident that leaving the tag was the right call."

If you looked at the diff, one would hope you were convinced that the content was AI-generated. Davidwbaker (talk) 01:32, 19 September 2026 (UTC)

I am not disputing that it was AI generated. I don't recall ever asserting that it was not, and I wish people would stop assuming that's my stance. I was and remain unconvinced that the tag was adequately explained, but per above, I don't have to be convinced, I just have to step back. EducatedRedneck (talk) 02:04, 19 September 2026 (UTC)

Got it, thanks for the clarification. Gnomingstuff (talk) 02:41, 19 September 2026 (UTC)

@EducatedRedneck -- I never assumed you were disputing the content was AI-generated. You asked for someone to point you to the diff, I thought I'd be helpful and do as you asked. I assumed good intent. I said that if you looked at the diff, I hoped you were convinced it was AI-generated. Maybe you've looked at the diff, or maybe not. Whatever your convictions are on various matters, I'm assuming good intent. I'm sorry if I've troubled you. Davidwbaker (talk) 06:21, 19 September 2026 (UTC)

I find it's a bit more complicated than this. In reading Talk:Deep state#AI Usage, one editor feels they have substantiated the problem by pointing to a thread that explains the issue and identifies the editor whose contributions need to be reviewed, and then suggesting a procedure for conducting that review. The tone was pretty gruff and I understand why OP was put off by it, but I wouldn't reduce the response to "figure it out yourself". —Myceteae‍🍄‍🟫 (talk) 17:46, 18 September 2026 (UTC)

My concern is that the Deep state article isn't mentioned in that archive. It is uninformative with respect to what parts of Deep state require attention. Does that change your opinion? Either way, thanks for replying and helping to clarify. EducatedRedneck (talk) 17:48, 18 September 2026 (UTC)

The linked discussion says all of this user's edits display the gamut of WP:AISIGNS and goes on to say that many of their edits are in articles related to the Trump administration, QAnon, etc.; Deep state is reasonably associated with that topic area. The archived WP:AINB post also includes a link to Wikipedia:AI noticeboard/2026-08-05 Quickdrew, where Deep state is listed along with an indication of the status of the review and a list of diffs. On the article talk page, Kowal more or less said that every edit by the named user needs to be reviewed. They could have been nicer about it and included a direct link to the tracking tool (Wikipedia:AI noticeboard/2026-08-05 Quickdrew) or provided or pointed to other suggestions for evaluating and addressing suspected AI-generated edits. AI cleanup is a challenging area. There is a group of editors who spend a tremendous amount of time and energy on it. I am grateful for their work. I do sometimes find their engagement on the issue with other editors terse and their processes opaque. —Myceteae‍🍄‍🟫 (talk) 18:27, 18 September 2026 (UTC)

That makes sense. I'm still not 100% on board, but I'm convinced enough that I feel good about not reverting the tag. Dionysodorus has solved the underlying dispute, but I really appreciate you taking the time to explain your view to me. It makes sense and while before I was flummoxed, now I at least understand it. Cheers! EducatedRedneck (talk) 18:46, 18 September 2026 (UTC)

Totally understandable. Good on you for seeking help, engaging with different views, and ultimately moving the actual cleanup work forward. —Myceteae‍🍄‍🟫 (talk) 18:50, 18 September 2026 (UTC)

I agree that the basic expectation that an editor should be able to identify and specify the problem if a maintenance tag should apply here. Katzrockso (talk) 17:39, 18 September 2026 (UTC)

• I agree, the burden would normally be on the user adding the tag, if a template has only recently been added then BRD might well apply. Template:POV does give reasons when the template can be removed in the "When to remove" section. If the tag is notability then AFD should be used if the tag is disputed. Yes I know things are different with people with a COI and new users who remove tags might be expected to get consensus to remove but I'd say in general if experienced users disagree then in general the burden should be on the tagger. Crouch, Swale (talk) 17:47, 18 September 2026 (UTC)

Wow, not even a courtesy ping, while also misrepresenting my position. FTR articles are only presumptively tagged sometimes when presumptive removal is invoked, it's the logical extension. It's done for articles where the cleanup is more time-consuming, i.e. when the content needs to be preserved in some form (like when the prior revision was terrible, when it's a creation with large edits from others, or when the addition is an important aspect of the topic). What is good about this, is it it distributes some of the work across the wiki to local editors, instead of the entirety of AI cleanup left with a handful of people, but if no local editors fancy doing it, it'll get done when people start clearing the backlog (here that's Category:Articles containing suspected AI-generated texts). What is bad about this is that people don't like having a garish tag on their pet articles, which is apparently a bigger concern than PAG violations likely being present. If you remove the tag without cleaning it up, you're effectively enshrining the LLM-generated content in the article. LLMs specialise in plausible nonsense, something "looking alright" is not enough, the content needs to be reviewed for WP:V (primarily). It is hard work and it sucks, but the wonderful thing is: you don't have to do it if you don't want to!

And yes, I'm burnt out if you couldn't tell. I'm doing this ~50-60 hours a week, postponing job searching and living off savings, because I care about this fucking project. So no, I don't have any patience for people demanding to be spoon-fed. I still don't know what they wanted (was it diffs? a list of all the sentences? me to review it and tell them all the problems I find?). I've stopped for the day and probably tomorrow anyway. Kowal2701 (talk, contribs) 21:08, 18 September 2026 (UTC)

Please read the WP:LLMPRV that you linked. It does not mention maintenance tags. It refers only to PRODs and reverts. Also, I'm really feeling like you're coming off as hostile. I wanted to review the portions of the article that were claimed to be AI. I'm sorry you're burnt out; perhaps a WP:Wikibreak is in order? WP:You are not irreplaceable; the project will be just fine until you've rejuvenated enough to return. EducatedRedneck (talk) 00:39, 19 September 2026 (UTC)

Well, no, not really, there is no one else who wants to do this sort of job. AI removal is done by a handful of people and if they're gone there's no guarantee anyone will do the task; if they were, they'd be doing it now. See User:Pppery/The iceberg. PARAKANYAA (talk) 13:39, 19 September 2026 (UTC)

So there are a number of complications here:

• There are indicators, that text is AI-generated, but they are not the things that need to be fixed. But if you point out the indicators, people will assume that if you just tinker with the wording then the issue is solved. (There are also usually a lot of indicators if an article is being tagged, so if you point out every one it will generate a huge wall of text.)
• Similarly, WP:BEANS applies, the worst case scenario here is handing people a guide to covering up their AI misuse, people already do that with the AI signs page as it is
• People seem to think AI-generated tags are exempt from WP:AGF. If someone adds an AI-generated tag to an article, they do a lot of AI cleanup, they specify the diff/user the tag is about, and there is literally a noticeboard thread about someone's use of AI -- which, if you read it, includes a mention of that person making an article about the nonexistent "Margo Largo Accord" which was near-unanimously deleted -- then it feels like that is enough information to trust that the person who tagged it knows what they are talking about.
• At a certain point people need to actually, you know, read. If there was no context whatsoever that would be one thing, but if someone provides a link to the diff in question, a link to the WP:AISIGNS page (and usually the specific sections of it that apply), and a link to a noticeboard discussing someone's AI use, then it feels like a bare minimum assumption that if someone wants to argue with the tag they should at least read those things first. After all, the person tagging it did.

Gnomingstuff (talk) 22:13, 18 September 2026 (UTC)

I wonder if we could improve the documentation. Help:Maintenance template removal#Specific template guidance does not sound very helpful to someone seeing this for the first time. Perhaps more of a checklist would be handy? For example:

"Step 1: Check that all the cited sources actually exist. Sometimes a link will be broken, so if it appears non-existent, please check (e.g., by searching for the source's title in your favorite web search engine).

Step 2: Check that the cited sources directly support the text as written in the Wikipedia article. For example, if the Wikipedia article says it's a seaside town with a historic church building, but the source only mentions the beach, then an AI may have hallucinated the bit about the church. Remove things that no source supports.

Step 3: Look at ..."

(or whatever you want for the steps). I think it needs to be something like Help:Referencing for beginners or Help:Introduction: enough to do most of the ordinary and important work, but not mentioning every possible thing. WhatamIdoing (talk) 03:35, 19 September 2026 (UTC)

I gave it a re-write, let me know what you think. -- LWG ^{talk (VOPOV)} 05:12, 19 September 2026 (UTC)

I think it's an improvement. I expanded a little bit of it. WhatamIdoing (talk) 19:01, 20 September 2026 (UTC)

I feel our entire culture around expectations, duties and requirements of maintenance tags is too loosey goosey.

If you toss up a banner-type tag, you, the adder of the tag, should be obligated to own framing it on Talk of that article within x days. If you don't, anyone should be thoroughly encourage and free to rip it down. The re-addition of same tag within x days (far shorter) without obligated explanations on Talk should lead to the tag getting ripped down again and any re-addition treated as disruptive.

Nature of the tag shouldn't matter. You put up a notice, you should be made to own it. — VPP (t/c) 18:46, 22 September 2026 (UTC)

Some tags, like Citation Needed, are self-explanatory. I agree that tags like POV or LLM need to have enough explanation for future editors to tell whether the issue has been resolved, but it doesn't have to be on the talk page. Filling out the reason= parameter is sufficient. -- LWG ^{talk (VOPOV)} 19:32, 22 September 2026 (UTC)

Unfortunately there are users that have stated that they will remove {{ai-generated}} tags if the reason isn't stated in the tag itself, the edit summary and on the talk page. So to avoid driveby untagging, everything needs to be filled out in triplicate. The tags are still removed though. There is an edit filter tracking it now, but that's an extra task for someone to do. ‑‑gurkubondinn 20:33, 22 September 2026 (UTC)

Unfortunately there are users that have stated that they will remove {{ai-generated}} tags if the reason isn't stated in the tag itself, the edit summary and on the talk page. While I haven't personally encountered this behavior, IMO persisting in removal of tags that have the reason= parameter filled out after you have been asked to stop should be sanctioned as disruptive editing. And I say this as someone with thousands of edits in which I removed dead or unexplained maintenance tags. -- LWG ^{talk (VOPOV)} 20:42, 22 September 2026 (UTC)

I agree that some tags are self-explanatory, so the nature of the tag does matter, and an adequate |reason= should often be sufficient otherwise. I don't think an additional talk page post should always be required though of course editors placing the tag should be expected to respond to any inquiries about it. The response to questions or challenges should be reasonably thorough and aimed at helping others contribute but there is a limit. If the disputing editor doesn't know how to accomplish the necessary review or is unwilling or unable to follow the suggested approach, that should not default to removing the tag. —Myceteae‍🍄‍🟫 (talk) 00:48, 23 September 2026 (UTC)

Part of my worry with this is always the notion that some articles will bear tags indefinitely.

Would it be unreasonable to expect the "tagger" to always have a qualified change/boundary by which they have to accept tag removal...? So things are never squiggly and to make all editors always play with their card hands showing. — VPP (t/c) 01:45, 23 September 2026 (UTC)

I mean, the tag says the article contains AI-generated text, so the boundary would be the point where it no longer contains AI-generated text (i.e., the text has been rewritten, stubified, or removed) Gnomingstuff (talk) 01:49, 23 September 2026 (UTC)

Sure, the AI one or certain others are usually binary/bright line. I meant more the ones that are a bit subjective. — VPP (t/c) 01:52, 23 September 2026 (UTC)

We don't want articles to be tagged forever but that is primarily because we don't want the (purported) problem to persist forever. The tagger should have a good sense of what a resolution will look like. But the specific cleanup approach and final product can take many forms. As much as the tagger has a responsibility, an editor seeking to remove the tag should also be able to demonstrate that either the issue has been resolved or the tag was not appropriate in the first place. I appreciate the problems of drive-by tagging and fuzzy/subjective problems but I'm not sure we can define a strict approach that will satisfy everyone. If there is disagreement then editors should seek more input. —Myceteae‍🍄‍🟫 (talk) 14:19, 23 September 2026 (UTC)

A talk page consensus should always be sufficient to remove a tag, and the tagger should not be able to veto its removal if they can't or won't explain the issue in a way that convinces other editors that it is necessary. If they try to prevent such a consensus (e.g. by stonewalling a discussion) then that should be treated as disruptive editing. Thryduulf (talk) 14:49, 23 September 2026 (UTC)

if they can't or won't explain the issue in a way that convinces other editors that it is necessary

If you're going to try to bulldoze an entire gaping loophole into the AI policy it would be courteous to at least say that's what you're doing. As usual, imagine doing this with any other policy or guideline. "Well, I don't believe that this is actually the entire collected text of Harry Potter books, I don't care what Google thinks and I don't believe that the google.com link you have provided is actually Google so I'm not clicking it, and moreover I think that it's actually OK to have the entire collected text of the Harry Potter books in the article so stop talking to me about "copyright". Gnomingstuff (talk) 15:55, 23 September 2026 (UTC)

First, please assume good faith. Second, I'm not actually try[ing] to bulldoze an entire gaping loophole into the AI policy. Third, one person not looking at evidence is the exact opposite of "can't or won't explain". Fourth, nobody is going to get consensus to host a copyright violation. Fifth, not everybody who has a different opinion to you is attempting to harm Wikipedia. Thryduulf (talk) 18:03, 23 September 2026 (UTC)

I agree with this statement as written but maybe we will disagree about the interpretation of particular incidents. If the tagging editor describes a fairly typical process and even suggests tool to aid in review and cleanup and the disputing editor doesn't know how to complete the task, that is not stonewalling. —Myceteae‍🍄‍🟫 (talk) 17:36, 23 September 2026 (UTC)

I was not attempting to describe a particular incident, and don't understand why I gave that impression? Thryduulf (talk) 18:04, 23 September 2026 (UTC)

I think people are assuming your comments are directed at the situations that have happened recently (one of which is at ANI right now I think) where people have essentially tried to override WP:NOLLM by local consensus and advocate for known LLM content to stay up. I can see how someone could read your comment above as supportive of that, even though I can also see how that might not be your intent. -- LWG ^{talk (VOPOV)} 19:42, 23 September 2026 (UTC)

I'm not aware of any relevant current relevant cases other than the one mentioned in this thread. However, I believe that editors at an article should be able to arrive at a consensus regarding what text is acceptable in that specific article. NOLLM is there for practical reasons (i.e. ensuring text is well written and supported by sources, etc) not an ideological drive to remove any trace of LLMs from the encyclopaedia, regardless of what some people would like it to be there for. So if there is a consensus that text in a specific aritcle is well written, is supported by the cited sources, etc, then that consensus is not contrary to NOLLM (and even if it were, a consensus that keeping given text is better for the encyclopaedia than removing it, then that's why we have IAR). Thryduulf (talk) 20:29, 23 September 2026 (UTC)

I'm only just now seeing this thread, but prior to my own commentary, I'll note that this largely matches my views on the matter. Even if the ONUS is on those adding content to substantiate it, that doesn't give users a right to throw out effectively baseless accusations in the hopes that something sticks, because, in some cases, their real issue is something within the text that they dislike but can't justify removing on its own. On something like NOLLM, I'd argue the charging editor has a responsibility to (if requested) provide some analysis that substantiates their claim, as otherwise it effectively serves a blank check to remove anything someone personally disagrees with without cause.

CSGinger14 (talk) 20:58, 23 September 2026 (UTC)

FWIW I completely agree except for cases where WP:LLMPRV applies. I'm not aware of any bad-faith tagging though? Kowal2701 (talk, contribs) 21:03, 23 September 2026 (UTC)

In the generic case, they should provide some analysis. It may not be a detailed account of every single problematic passage but they should be able to point to specific examples and describe what they think should be done. Pointing to a specific guideline or discussion post and defining the problematic edits/content without identifying each instance (e.g., "every diff by this editor") may be sufficient. The tagging editor should make a good faith effort to help other editors validate the problem and participate in the cleanup. But other editors' failure to understand how to accomplish the review and cleanup does not necessarily mean that the tagging rationale was insufficient. —Myceteae‍🍄‍🟫 (talk) 21:43, 23 September 2026 (UTC)

An example test: if someone fixed the issue but forgot to remove the tag, it should be possible for an editor working through the backlog years later to determine that that happened. If it's impossible to tell whether the problem has been fixed since the tag, then the tag didn't have enough info in the first place. For LLM tags that means identifying the editor and/or diffs that inserted the suspect text. It would also help to have at least some indication of why they are suspect, but I think some people are setting that bar too high (certainly if there's an AI noticeboard section then linking to that section is sufficient). -- LWG ^{talk (VOPOV)} 22:07, 23 September 2026 (UTC)

If the tag is old and I am confident that I know how to assess the issue and that it is resolved/does not apply, I would remove it. I would leave a clear edit summary and depending on the details I might leave a more detailed message on the talk page. —Myceteae‍🍄‍🟫 (talk) 06:35, 24 September 2026 (UTC)

The problem is that people generally do provide that analysis, but if someone doesn't read it, believe you, or give a fuck, then what's the point?

A recent example is Talk:Tbilisi#Probable_AI_generated_text, which I stumbled upon three separate times in over a year due to stumbling three separate times upon its blatantly obvious AI-generated text. But the tag kept getting removed despite my pointing out exactly whose edits were the source of the tag, and though they claimed the text was reviewed it clearly was not, because not even the most trivial and easily noticeable things (e.g. markdown formatting) were fixed. Gnomingstuff (talk) 14:27, 25 September 2026 (UTC)

That's an issue, but it's not the one we're discussing here. Thryduulf (talk) 14:30, 25 September 2026 (UTC)

I think that is the issue a lot of us are discussing here, because that's the issue most of us are actually seeing in our watchlists. If we want to discuss the issue of effectively baseless accusations in the hopes that something sticks, because, in some cases, their real issue is something within the text that they dislike but can't justify removing on its own what is there to discuss? We all agree that people shouldn't be using NOLLM as an excuse to throw baseless accusations at non-LLM content they dislike, and no one here is doing that as far as I can tell. At least, I haven't seen that happening. It would help me understand where you are coming from if I could see some examples of the kind of behavior you consider problematic happening in the wild, because otherwise it's hard not to keep drifting back to assuming you are talking about the behavior of the people in this thread in the articles that are linked from this thread. I'm not saying this to be snide-- I genuinely do want to understand your position and if people are using LLM tags on content that isn't LLM just because they don't like that content I genuinely do want to know about it. -- LWG ^{talk (VOPOV)} 20:28, 25 September 2026 (UTC)

I'm trying to distinguish between three different scenarios:

1. The tagger responds to questions with evidence and explanations, other editors engage with them in good faith but ultimately the tagger's view is not in accordance with the tagger's view
2. The tagger responds to questions with evidence and explanations, but other editors ignore that and/or don't engage in good faith.
3. The tagger does not respond and/or does not provide evidence or explanations.

Examples of all three have been provided in this thread. Thryduulf (talk) 22:15, 25 September 2026 (UTC)

Another example is Open energy system models, which I eventually gave up on. ‑‑gurkubondinn 14:31, 25 September 2026 (UTC)

What's wrong there?

https://en.wikipedia.org/wiki/Talk:Open_energy_system_models#Sources_added_since_Dec._2022 — VPP (t/c) 20:33, 25 September 2026 (UTC)

It seems like there was no convincing evidence that there was any AI generated text in the article at all. I agree that there didn't seem to be a problem there. Katzrockso (talk) 22:00, 25 September 2026 (UTC)

The evidence is that the person literally said themselves that I might occasionally run a sentence or two through DeepL Write more recently to see if the text could be better framed. Like... they said it... themselves................

This is the kind of infuriating refusal to get the point I am talking about. Gnomingstuff (talk) 18:07, 26 September 2026 (UTC)

First, I am capable of reading and was able to read that comment posted by them. What's important to note is that:

1) They did not confirm to using any DeepL text in the article in question. The idea that if someone once used DeepL to translate something, that every article they every contributed to must be immediately tagged without even identifying one single actual problem with the article is ludicrous.

2) At the time the tag was first added, rewriting a sentence with DeepL was not strictly banned.

3) Even with this "admission", there is no clear identification of the actual content that needs to be remedied. Are editors supposed to trawl through every edit to find the one sentence that could have been rewritten using DeepL?

Johnjbarton cleaned up the article. The only text added by RobbieIanMorrison that he flagged was this edit , which doesn't appear like AI to me or Pangram. Katzrockso (talk) 01:10, 27 September 2026 (UTC)

Cleanup done

@EducatedRedneck and everybody else: I've just gone through the article myself and done what needed to be done, and so have now removed the tag. Hopefully the whole issue is now resolved. Dionysodorus (talk) 18:29, 18 September 2026 (UTC)

Thanks so much! I really appreciate your work, and especially you discussing and getting us closer to being on the same page. Cheers! EducatedRedneck (talk) 18:40, 18 September 2026 (UTC)

RfC: Permitting or prohibiting AI in creating/formatting Wikitext

Since I clarified that the original discussion was not an RfC and was also getting off-topic (sorry, Gurkubondinn), here we are. The discussion yielded an unclear result, so I figured I would just move ahead with a clearer RfC. Hopefully consensus will be clearer. Courtesy-tagging original discussion participants: @Gnomingstuff @SuperPianoMan9167 @Katzrockso @NicheSports @LWG @Fermiboson @Thryduulf @InfernoHues @Chipmunkdavis

Should WP:NOLLM be updated to explicitly permit or explicitly prohibit the use of AI/LLMs to create/format Wikitext (hereafter referred to as "WT")?

Option 1 — No change to NOLLM.

Option 2 - Add some form of explicit exception to PERMIT the use of AI to format WT, with the caveat that the user is responsible for ensuring it is non-disruptive and publishes without error.

Option 3 — Add some form of explicit prohibition to PREVENT the use of AI to format WT.

This RfC also invites discussion as to the wording of an exception or prohibition — MWFwiki (talk) 22:12, 19 September 2026 (UTC)

Note: This isn't an WP:RFC. Merely putting the letters "RfC" in a section heading does not create an RFC. The purpose of the RFC process is to advertise the discussion to uninvolved editors. If you don't follow the process outlined at WP:RFC, then that advertising never happens, and it's not an RFC. I have removed the misleading "RfC" label from the section heading. WhatamIdoing (talk) 19:09, 20 September 2026 (UTC)

Resolved. — MWFwiki (talk) 21:13, 20 September 2026 (UTC)

Option 2 or Option 3 — I feel we should go with option 2 or 3, as I don't care for the current ambiguity and I fail to see how a clearer guideline in either direction could cause issues. If it does? We can always gain consensus to change it back. — MWFwiki (talk) 22:12, 19 September 2026 (UTC)

Bad RFC. Sigh. This is just a broader version of the citation RFC that just closed. -- LWG ^{talk (VOPOV)} 22:18, 19 September 2026 (UTC)

Per the the closer's commentary: "Nevertheless, the discussion did not establish consensus on whether WP:NOLLM currently prohibits all LLM-assisted citation formatting or whether accurate, carefully checked citations should attract sanctions. While this RfC rejected adding a written exemption, it should not be read as resolving either of those questions" — I would argue that, at least in-part, this is one of the questions this RfC seeks to resolve, as citations are WT. It also asks if explicit prohibition is not the best course of action. — MWFwiki (talk) 22:22, 19 September 2026 (UTC)

I guess if we need another whole RFC to determine that no consensus for change 5 days ago means consensus for status quo now, then Option 1. I still wish we could just have a couple scoops of ambiguity tolerance in our morning cereal and not open RFCs every time we think of an edge case. Options 2 and 3 will both cause problems and have little to no benefit. -- LWG ^{talk (VOPOV)} 22:32, 19 September 2026 (UTC)

Please do not ping me to a discussion I have been active in less than 24 hours ago and whose existence I am clearly aware of. Gnomingstuff (talk) 23:30, 19 September 2026 (UTC)

Why would I assume you to be "clearly aware" of an RfC on a different page and in a RfC you have never been "active in"? Regardless, I'm happy to respect your preferences moving-forward. — MWFwiki (talk) 23:45, 19 September 2026 (UTC)

Nevertheless, Option 1. The simpler the guideline, the better, and frankly "Don't use AI" would be an improvement on what we have now, because it would put an end to the endless attempts to undermine the guideline at any possible perceived weak point. Gnomingstuff (talk) 23:32, 19 September 2026 (UTC)

"'Don't use AI' would be an improvement on what we have now[...]" — unless I'm misunderstanding you, then don't you mean option "3"?  — MWFwiki (talk) 01:12, 20 September 2026 (UTC)

How does adding more clauses to the existing guideline make it simpler? —ClaudineChionh (she/her · talk · email) 01:21, 20 September 2026 (UTC)

It makes the guideline technically "more complicated" as one is adding text to it, but it makes the enforcement practices easier (it codifies that the only use of LLMs are in the explicit exceptions) and takes-away an oft-used excuse that individuals like to seemingly use when confronted over AI use. It doesn't need to be overly-verbose. "LLM-use to produce or format wikitext is prohibited." — MWFwiki (talk) 01:26, 20 September 2026 (UTC)

I mean option 1. I'm not actually proposing to rewrite the guideline, as much as I think it would improve matters. Gnomingstuff (talk) 06:43, 20 September 2026 (UTC)

I think "re-write" is a strong term. The prohibition could be a small blurb, "LLM-use to produce or format wikitext is prohibited."  — MWFwiki (talk) 18:15, 20 September 2026 (UTC)

Option outcome of Wikipedia:Village pump (policy)#RfC: AI use for generating citations within articles, lest everyone repeat the same points made there and in subsequent discussion again. CMD (talk) 23:36, 19 September 2026 (UTC)

Option 1 per Gnomingstuff and the previous rfc. —Leaf.Sheap ⇖ /.°°.\ ⇗ (They•Them) 00:05, 20 September 2026 (UTC)

Option 1 - per Katzrockso in the original discussion linked. InfernoHues (talk) 00:34, 20 September 2026 (UTC)

Option 1 – The stalwarts at AINB are overworked and burnt out. They don't need their time consumed by endless relitigation of previous RFCs. —ClaudineChionh (she/her · talk · email) 01:20, 20 September 2026 (UTC)

Option 1. No change. We don't need to incentivize people to do it wrong (as explicitly allowing it would entail) - but if you do it right no one will ever notice! This is not an issue! PARAKANYAA (talk) 01:30, 20 September 2026 (UTC)

Maybe we can add after the bit on LLMPRV on a new line

Editing Wikipedia is often challenging at first; newcomers may find help pages and this brief summary of policies and guidelines useful.

Kowal2701 (talk, contribs) 08:25, 20 September 2026 (UTC)

I'm gonna boldly add this along with Editors generally should not edit a Wikipedia edition whose language they are not proficient in (see Meta:List of Wikipedias for all existing language editions). as I think I'd do it anyway regardless of the result of this RfC (been meaning to do something similar ). Anyone should feel free to revert and discuss at WT:NOLLM Kowal2701 (talk, contribs) 12:18, 20 September 2026 (UTC)

FWIW option 1, this'd get wikilawyered about a hell of a lot and lead to AINB cases getting bogged down even more than they already do, for otherwise minimal benefit Kowal2701 (talk, contribs) 12:50, 20 September 2026 (UTC)

Option 1 - per Claudine, Gnoming, and everything else that's been said in all of the other discussions. ‑‑gurkubondinn 08:33, 20 September 2026 (UTC)

Option 2 per my comments above and in the previous RFC. Policies and guidelines should mean what they say and say what they mean. Thryduulf (talk) 10:09, 20 September 2026 (UTC)

Option 1 - Is the current guideline perfect? No… but… we have been over this again and again. It reflects current consensus. My suggestion is that we give it time… we need to see it in action and chart its flaws. After (say) 6 months to a year we will better know what needs to be amended. Blueboar (talk) 12:16, 20 September 2026 (UTC)

Option 3 or option 1, and it would be nice and further Wikipedia's unique approach to AI to not allow AI posts on talk pages or in discussions. Randy Kryn (talk) 12:22, 20 September 2026 (UTC)

it would be nice and further Wikipedia's unique approach to AI to not allow AI posts on talk pages or in discussions Just FYI this is already more-or-less the case. -- LWG ^{talk (VOPOV)} 17:07, 20 September 2026 (UTC)

Option 1 per LWG above and at the original discussion NicheSports (talk) 13:55, 20 September 2026 (UTC)

Option 3, the less AI the better. It may start with formatting, then... As they say First They Came for formatting, and we did not speak... Yesterday, all my dreams... (talk) 15:31, 20 September 2026 (UTC)

Option 1 or 2. Using an LLM to format wikitext is already allowed per the guideline:

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.

We could tweak this to call out formatting specifically but I don't feel strongly either way. Anne drew (talk · contribs) 19:07, 20 September 2026 (UTC)

option 1 not required. I also agree with other editors that this will only result in more wikilawyering. -- LCU ActivelyDisinterested «@» °∆t° 20:09, 20 September 2026 (UTC)

Option 1 to avoid more wikilawyering. A carveout for wikitext formatting may be used by editors arguing (or being advised by LLMs to argue) that large content additions inside, say, templates would be acceptable as only "wikitext" was edited, and more generally encourage editors to rely on AI to make such changes. Minor formatting (e.g. consistently italicizing genus/species names) already falls under basic copyediting and shouldn't be an issue. Chaotic Enby (in solidarity · talk · contribs) 20:27, 20 September 2026 (UTC)

Option 1 as per Chaotic Enby. * Pppery * _{it has begun...} 21:28, 20 September 2026 (UTC)

Option 1 – Does not make sense for consensus to go a different way here than it did for the citations RfC. Also little to no benefit. Every sentence added to WP:NOLLM enables more wriggling/wikilawyering and has WP:BEANS issues. Editors who are capable of using LLMs to format wikitext are already not being sanctioned, because nobody can tell that they are doing it due to the results of formatting wikitext with and without an LLM are indistinguishable when done correctly. –Maltazarian ^{ᚾparley$\lor$investigateᛅ} 10:11, 21 September 2026 (UTC)

Option 1. Honestly, if I were to write a "nutshell" for NOLLM, it would be something to the effect of "If anyone can actually tell that you're using an LLM, you're using one in a way you shouldn't be." If a human editor really is carefully checking over the LLM output, and changing it as needed, the final result will be indistinguishable from something they wrote themself. (Why they wasted time with the intermediate step is a separate question, but in the end I don't care how the sausage got made.) If anyone is able to tell that an LLM was used to generate something, then whoever generated it is doing it wrong. So, if someone uses it to generate an infobox, and actually carefully double checks that the output is correct, how would I know the difference between that and them doing it themself? Seraphimblade ^{Talk to me} 12:17, 21 September 2026 (UTC)

The issue is that this isn't want the policy says and as has been noted several times, this view is not universal. There are editors who do care about how the sausage is made and believe that any use of an LLM, detectable or otherwise, is prohibited. Thryduulf (talk) 12:23, 21 September 2026 (UTC)

Thryduulf, in the end, what practical difference does that make? If something looks like you wrote it, it's not like I'm going to stand over your shoulder and watch what you do on your own machine. And realistically, if someone wrote a bunch of fake citations up completely by hand, that in itself would be a problem too. Seraphimblade ^{Talk to me} 16:46, 21 September 2026 (UTC)

I completely agree with you that if you can't tell it shouldn't matter. My point is only that (a) not everybody does agree with this (as I understand it, they see it as a point of principle) and (b) the policy does not currently say that. The latter means that those who disagree with us can (and per other comments in this discussion, do) point to the policy and say it backs their viewpoint. If there is a community consensus in favour of the view you and I hold then the policy should say that. Thryduulf (talk) 17:06, 21 September 2026 (UTC)

French Wikipedia recently changed their AI policy to prohibit LLMs, except for copyediting and when the content is PAG-compliant (with lots of caution stressed). We can see how their experience with that goes ig, but yeah for some it'd be a non-starter Kowal2701 (talk, contribs) 18:38, 21 September 2026 (UTC)

If a human editor really is carefully checking over the LLM output, and changing it as needed, the final result will be indistinguishable from something they wrote themself.

This. While I don't think this should be added to the NOLLM page (as per others, "wikilawyering"), if someone decides to use AI to help with their edits but review its suggestions before publishing, then the end result would not look like a LLM wholesale wrote it (and thus should not warrant a user warning). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:48, 26 September 2026 (UTC)

Option 1: Editors should use their best judgement as to whether they should use AI to format (but not add content) wikitext, although this should be strongly discouraged for new editors who are not familiar with many of Wikipedia's policies. If we want this change then I suggest adding "formatting of wikitext" into point 1 of NOLLM (ie copyediting), while making sure the changes it has made has been adequately/reasonably reviewed (through using the "Show changes" button before publishing). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:28, 26 September 2026 (UTC)

Option 2, even though I sense that we are at an impasse of insincerity. I agree with MWFwiki and Thryllduff that polities should mean what they say. The desirable solution is to minimize, carefully review, and assign editors full responsibility for Wikitext formatting that is LLM-assisted. We should explicitly carve out non-disruptive formatting from either the policy altogether (my preference) or from enforcement by banning (a reasonable fallback). I'll share process comments below.--12:56, 27 September 2026 (UTC)

Discussion regarding wording of a proposed exception or prohibition

Prohibition proposal: "Use of an LLM to produce or format any form of Wikitext is prohibited. For example, this prohibition includes but is not limited to: utilizing an LLM to wikilink, create citations, create infoboxes, etc."

Exception proposal [to become point "3" of NOLLM: "LLMs may be utilized to assist users in generating Wikitext, to a limited extent, and all work must be checked thoroughly before final publication. Such exceptions include basic and simple tasks, such as adding Wikilink bracketing, crafting an infobox, etc. Users are still responsible for 'hallucinated' or otherwise false content and are responsible for ensuring all of their inserted content publishes without error." — MWFwiki (talk) 22:20, 19 September 2026 (UTC)

My issue is that wikitext needs to be clearly defined if not wikilawyered. Is everything we type not technically wikitext too? Katzrockso (talk) 01:08, 20 September 2026 (UTC)

Well, we could call it wiki-markup. But WT is defined at Help:Wikitext. We could just wikilink "WT" to there. Or we could use its definition in the exception. "Text which formats the page." But indeed, your question is yet another reason we need to clarify the guideline, as people can argue "all text is wikitext" or that "all wikitext is text."  — MWFwiki (talk) 01:23, 20 September 2026 (UTC)

Many word processing programs (e.g., Microsoft Word) are now also embedding LLM-based AI functionality, as are email platforms, social media platforms, and so forth. Are we going to get to a point where any kind of application that contains a spellchecker will end up being prohibited because they are accomplishing the task with AI rather than a traditional spelling library? BD2412 T 01:25, 20 September 2026 (UTC)

Well, I would argue that this is already covered (as an exception) under the current wording of NOLLM. Basic copy-editing, spell-checking, etc. If you are asking whether I think a prohibition on the use of an LLM in formatting WT would contradict the current exception, no, I do not. Otherwise, why have explicit exceptions at all?  — MWFwiki (talk) 01:34, 20 September 2026 (UTC)

It's covered if you actually use it for "copy-editing, spell-checking" etc.

E.g., if you copy paste a proquest header (citoid usually does not work with proquest), with the source details (title/publication/date/volume/issue/page/location/author/etc) into an LLM and ask it to format it into wikitext cs1 templates and make no other changes, then check it after. I've tested this out offwiki and it worked basically perfectly and any hypothetical errors would be easy to catch (LLMs tend to make stuff up less when they're working directly with a small amount of text you give them). I see no problems with that basic usage, and there's no way to tell the difference - unlike with generating new prose.

However, explicitly saying it is allowed will make some people who don't know any better use it to generate full citations, which is totally problematic, and to defend themselves against sanction that way. PARAKANYAA (talk) 13:57, 20 September 2026 (UTC)

I was discussing prohibiting (formatting wikitext) in the thread you replied to. Again, if the concern is your last sentence, why have explicit exceptions at all? It's either used well and it's no problem and no one knows... or it causes an issue. Very generally speaking, at least. The current guideline is already overly-ambiguous and ripe for wikilawyering  — MWFwiki (talk) 18:13, 20 September 2026 (UTC)

Because having no exceptions will make people go the opposite way and attack people for mundane, correct uses that are baked into all spellchecking programs. If you use a modern program with a spellchecker you are "using AI" - the problem is letting it rewrite larges swathes of text. PARAKANYAA (talk) 14:01, 21 September 2026 (UTC)

The issue is proving it, short of an admission. LLMs are getting better, slowly, but they are getting "better." A year ago, it was extremely obvious when an LLM was used. I feel those days are waning (though they are not completely gone, to be clear). Regardless, having no exceptions isn't on the table, so I suppose the point is moot. My argument is simply that virtually nowhere else is having clearer, less-ambiguous guidelines an issue. Funnily enough, the way this RfC is heading, its consensus can be used to show that there is no prohibition against formatting wikitext, the community simply does not want to codify it... nevertheless, the consensus is there.  — MWFwiki (talk) 18:49, 21 September 2026 (UTC)

There is no prohibition against formatting wikitext, the community simply does not want to codify it... Precisely this: acceptable types of formatting are already de-facto permitted under the current guideline, so codifying an exception accomplishes nothing except encourage wikilawyering in support of unacceptable types of formatting. If you have to ask which side of the line a particular use case falls on, it probably falls on the prohibited side. In the rare case that someone is asked to stop using LLMs even though they would have used them responsibly, the mild inconvenience to that person is a more than worthwhile cost to pay for the streamlining of the slop cleanup process. It's just like our rule about disclosing conflict of interest: COI editors are required to disclose their COI. Yes, they could theoretically make non-controversial edits to their pages without disclosing, and if their edits really are non-controversial they are unlikely to be sanctioned for it, but the COI guideline doesn't and shouldn't say "you don't have to disclose as long as you only make totally non-controversial edits", nor is it acceptable to waste our time arguing that your particular undisclosed COI editing was fine. -- LWG ^{talk (VOPOV)} 20:20, 21 September 2026 (UTC)

Personally, I'm leaning towards codifying a prohibition, but that is neither here nor there. Maybe I'm dumber than I thought, but I just can't wrap my head around not wanting to codify an exception that there is clearly consensus for... while simultaneously arguing (not you) that wikilawyering will be an issue if we clarify the guideline. I understand your COI analogy, but we decide these things independent of each other.  — MWFwiki (talk) 21:02, 21 September 2026 (UTC)

As I've discussed in my essay on addressing problems without creating new specialized rules, it's impractical to codify all guidance. As far as reasonably possible, it's better to lay out general principles to be followed. As I discussed previously, the general guidance is that guidance about content is about what the reader sees: the rendered HTML output. There's no special exception for one type of tool being used to generate the underlying wikitext. Guidance on using wikitext (like how to format lists) explicitly refers to wikitext. isaacl (talk) 22:02, 21 September 2026 (UTC)

this slope is so slippery it has ceased to be a slope and is now just straight oil Gnomingstuff (talk) 03:10, 20 September 2026 (UTC)

Was it ever realistic for anything like a hard ban to be viable? — VPP (t/c) 18:41, 22 September 2026 (UTC)

Reading these evolving discussions I'm more worried over time that we're being ideological rather than realistic. Your examples of AI-native tooling getting embedded into so many products is a perfect example. — VPP (t/c) 18:40, 22 September 2026 (UTC)

Most writing-related guidance on English Wikipedia focuses on the rendered HTML output, rather than the wikitext source, since that's what affects reader experience. Historically, tools have generated wikitext through a deterministic process, whether it is using templates, Visual Editor, or off-wiki tools filling in skeletons based on some data source. With a generative tool, though, the result is produced through a black box that no one explicitly programmed. If there is a consensus that the risk of users not verifying the result is greater that the benefit of using such tools, then it's not clear to me how to carve out a set of allowable uses in a practical way. Although it might be the case that a user is less likely to check the result of a generated infobox than a single verb tense change, I think there is a point where the probability of that user checking a mass set of grammar and spelling changes starts approaching the same level. isaacl (talk) 18:10, 20 September 2026 (UTC)

Process comment: As with the prior RFC on LLM-assisted citations, we have a substantial set of editors !voting to keep the policy as it is (Option 1 here; No on the prior RfC) with the understanding that non-disruptive LLM-assisted Wikitext formatting will not get anyone in trouble. And we have another substantial set of editors arguing to keep the policy as it is with the understanding that any LLM-assisted Wikitext formatting should get editors in trouble. Resolving this tension is what I take to be MWFwiki's purpose in opening the RFC.

To put too fine a point on it, these are statements in this and the prior RFC that are all in the prior camp:

• PARAKANYAA: but if you do it right no one will ever notice! This is not an issue!
• Seraphimblade: Honestly, if I were to write a "nutshell" for NOLLM, it would be something to the effect of "If anyone can actually tell that you're using an LLM, you're using one in a way you shouldn't be." If a human editor really is carefully checking over the LLM output, and changing it as needed, the final result will be indistinguishable from something they wrote themself.
• Hason-LEK-SIN: If someone decides to use AI to help with their edits but review its suggestions before publishing, then the end result would not look like a LLM wholesale wrote it (and thus should not warrant a user warning).
• From here on, from the citation RFC Fermiboson: In practicality, anything they did which we are unable to tell was done with an LLM is permitted, and anything they did which we are able to tell was done with an LLM is not.; we are swamped enough with the rate of obviously bad AI edits that, quite frankly, we are happy to let your slightly sloppy wikitext formatting go
• InfernoHues: My rule-of-thumb is that if I can tell that an LLM was used, it's likely a violation of this guideline. How would you know an LLM was used for wikitext unless a hallucination/errors occurred?
• Katzrockso: If it was perfectly accurate and introduced no issues, I would argue whoever is strictly enforcing the guideline is putting the letter of the guideline over the spirit to the detriment of the encyclopedia., seconded in this by HTGS
• SarekOfVulcan: If you check it thoroughly enough so that you're sure there's no error, you're not going to get flagged, and if you don't, you should be.
• Mycetae: I would not expect a well formatted, error-free citation to raise any eyebrows unless there is something else going on.

The impasse that we stand in is that some editors believe that no written change (Option 1) means that the policy is effectively Option 2 (in competently executed cases) -- presumably those quoted here -- and others believe that no change means the policy is effectively Option 3. I'm not sure how to get out of this impasse, but do think that we should use this RFC to do so.--Carwil (talk) 13:02, 27 September 2026 (UTC)

Our votes for status quo aren't motivated by a misunderstanding of what the status quo is, they're motivated by the understanding that the status quo includes some useful ambiguity and reasonable restraint in enforcement while leaving no excuse for defending AI text when it is challenged. This status quo is better than what we'll get if we adopt either of the other options proposed here. -- LWG ^{talk (VOPOV)} 14:12, 27 September 2026 (UTC)

That's not the issue. The issue is that two groups of people are voting to support the status quo based on different interpretations of what the status quo allows. That is not "useful ambiguity", that is bad policy that allows for inconsistent enforcement and biting of good faith editors. Thryduulf (talk) 14:36, 27 September 2026 (UTC)

I just re-read all the votes and I'm not seeing this "substantial set" of editors with the "status quo is option 3" interpretation? Every single Option 1 voter appears to broadly agree with my position. -- LWG ^{talk (VOPOV)} 15:42, 27 September 2026 (UTC)

It seems pretty clear that Gnomingstuff's !vote (plus comments here: Wikipedia_talk:Writing_articles_with_large_language_models#Proposed_reword) is based on reading Option 1 as implying that Option 3 is already in effect; their opinion was seconded as well. Numerous examples in the citation RFC. Ditto this essay.--Carwil (talk) 16:53, 27 September 2026 (UTC)

RfC: Allow autoconfirmed users to archive MfD pages, instead of being bot exclusive.

Can the MfD guidelines be changed to allow autoconfirmed users (or above) to archive non-controversial discussions? 🐴🌀^{[citation needed]} 04:26, 20 September 2026 (UTC)

Reason

I have tried to archive pages by myself, but I might get into a bit of trouble, considering the guidelines mentioning that only bots can do it. I'm making this RfC because if this does get allowed, we wouldn't have closed discussions on the MfD page just sitting there, and would make newer discussions get more !votes, instead of being overshadowed by older closed discussions.

Thanks for cooperating in my RfC. From, 🐴🌀^{[citation needed]} 04:26, 20 September 2026 (UTC)

This RfC is premature. Before starting an RfC, try discussing it at WT:MFD. Axolitl (talk | contribs) 05:20, 20 September 2026 (UTC)

Not to mention that RFC's should start with a neutral statement of the issue and not advocate for one side or the other. Also, this RFC was multi-posted at Wikipedia talk:Miscellany for deletion#RfC: Allow autoconfirmed users to archive MfD pages, instead of being bot exclusive.. This all started at Wikipedia:Administrators' noticeboard#Issue with redirecting an MfD because the user was prevented from completing an MFD closure by an edit filter due to not being extended-confirmed, and then moved to this thread on my talk page. Graham87 (talk) 05:34, 20 September 2026 (UTC)

Yea, I might have accidentally added too much requests on multiple pages. 🐴🌀^{[citation needed]} 06:06, 20 September 2026 (UTC)

I closed the RFC that was opened at WT:MFD per WP:MULTI. Chess enjoyer (talk) 06:31, 20 September 2026 (UTC)

Oh, also, the relevant page is Wikipedia:Miscellany for deletion/Administrator instructions. Graham87 (talk) 10:59, 20 September 2026 (UTC)

"Can the MfD guidelines be changed to allow autoconfirmed users (or above) to archive non-controversial discussions?" is a neutral question. The RFC process does not prohibit the OP from explaining why they're making a proposal, including giving reasons why they think the proposal is desirable. WhatamIdoing (talk) 19:11, 20 September 2026 (UTC)

I'll concede those points. I'm used to reading one-sentence RFC statements with more of the explanation in the initial !vote, but I realise now that that's not the only way. Graham87 (talk) 06:53, 22 September 2026 (UTC)

Responses re Allow autoconfirmed users to archive MfD pages, instead of being bot exclusive

• This doesn't seem needed. Let the bot do its job in a predictable fashion. CMD (talk) 06:53, 20 September 2026 (UTC)
• Allow. Some people are more bothered by visual clutter than others. For the majority of Wikipedians who read fluently (and most of us do; the nature of Wikipedia means most editors are above-averagely literate and comfortable with large amounts of text), this is a non-issue. But decluttering has real benefits for some people, including but not limited to people with specific disabilities. There is no reason to prevent a Wikipedian from manually cleaning up if it helps them.—S Marshall T/C 09:37, 20 September 2026 (UTC)
  • @S Marshall: Closed discussions are already collapsed in show/hide boxes. As an example that works at the time of writing, see the entry for "September 18" in this edit of mine (which was ironically nixed by the archiving bot). Graham87 (talk) 10:12, 20 September 2026 (UTC)
    • I understand that. What I don't understand is why we should stop this volunteer from working in the way he wants to. Is he doing some kind of harm?—S Marshall T/C 13:13, 20 September 2026 (UTC)

      As a collaborative project, though, the preferences of one volunteer shouldn't be imposed upon all others. If a daily archiving cadence fits everyone else's workflow, then it's reasonable to stay with it. The custom CSS provided by OutsideNormality allows for individuals to decide to hide the sections in question. isaacl (talk) 17:21, 20 September 2026 (UTC)

      Indeed. Especially in this sort of case when a volunteer is working in an area they almost certainly don't understand sufficiently. To continue with the construction site analogy I used below, it's like radically reshaping a long-established construction site based on the whims of a rookie employee on their first day on the job. Graham87 (talk) 06:30, 21 September 2026 (UTC)

  • decluttering has real benefits for some people, including but not limited to people with specific disabilities. There is no need to manually archive the page (forcing everyone else to trawl through the archives to find the outcome of a recently closed discussion) when the following CSS I whipped up just now seems to work (although only for Parsoid, and doesn't remove empty section headers):

    section:is([aria-labelledby="Current_discussions"], [aria-labelledby="Old_business"]) section .mw-collapsible {
      display: none;
    }
    

    OutsideNormality (talk) 16:44, 20 September 2026 (UTC)
• Don't allow/leave it alone. Let the dedicated bot do its job as they have for many years now, since 2010. The XFD pages (and particularly those besides AFD) are not for inexperienced users to peruse and this sort of activity is highly unusual. Universal accessibility is very much essential in a completed building, not so much on a live construction site where only qualified workers tend to go. By this I *don't* mean that our accessibility guidelines shouldn't apply to non-article pages, just that unless we hear a complaint from an experienced Wikipedian who regularly peruses MFD (or if there's a significant minority who are put off by the discussions being live on a page for a little while), we shouldn't change how things are done. And, as I noted at the admins' noticeboard discussion that started this whole thing off, there's abuse filter 174 that stops non-extended-confirmed editors from removing MFD templates in the first place. Graham87 (talk) 10:26, 20 September 2026 (UTC)
  • As a counterexample, if we had an RFC saying "a few regular and experienced Wikipedians have complained that XXX Wikipedia namespace venue is impossible to load because of page size; let's explore solutions to make it easier for those people", I'd have absolutely no problem with that. But that's not what we have here. Graham87 (talk) 10:31, 20 September 2026 (UTC)
• No - We have a bot that does this. If you would like to propose that the bot act more frequently, that's fine, but it looks like the bot comes by after ... one day? Hard to think of a case where we'd need to move faster than that -- it's not like MfD is particularly busy these days. If the issue is readability of text clutter, that's more the fault of the voluminous instructions at the top of WP:MFD. It should be easy enough to create a custom page or propose to separate the list and the instructions. — Rhododendrites ^talk \\ 13:40, 20 September 2026 (UTC)
• Manual archiving imposes a burden on everybody that sees the diff and then goes to verify that the discussions were in fact archived correctly, instead of just being disappeared or having their results on the monthly archive page misrepresented. And there are people who check, because why else would someone do that when there's a bot to do it? And even if there were no Petty Nefarious Plot, there's plenty of room for error. It'd take a very extraordinary situation to be worth ignoring this rule, on the order of dozens of closed discussions from the same day. —Cryptic 00:30, 21 September 2026 (UTC)
• No Why make onlookers wonder if manual archiving was done correctly? What about time wasted when there is a disagreement about whether manual archiving was appropriate? Let the bot do its job until consensus shows there is a problem. Volunteering is good. Imposing one's ideas on others is not. Johnuniq (talk) 09:25, 21 September 2026 (UTC)
• No. Don't fix what isn't broken applies to too many proposals these days, this one included.Katzrockso (talk) 02:08, 26 September 2026 (UTC)

Redirect deleted article name to article where the name is mentioned at top?

I Have searched and searched to try to find policy on this question. Is there any? --LogIsland (talk) 13:30, 20 September 2026 (UTC)

There is no specific policy I'm aware of. If you believe that the title of a deleted article would make a good redirect, regardless of why you believe that, then you should create the redirect if you are able (if you are not able then you can request it at WP:AFC/R).

There are two exceptions to this general case I can think of:

• The redirect was suggested and rejected in the deletion discussion for the deleted page.
• The redirect was previously discussed and deleted at WP:RFD.

If you are unsure whether these apply you can ask the administrator who closed the deletion discussion. Thryduulf (talk) 13:36, 20 September 2026 (UTC)

Thank you! Good question and good answers. I am thus asking Dclemens1971 whether or not these exceptions apply to making a redirect from Ritch Esra to MubuTV. I believe that redirect would be helpful and would like it created unless it goes against policy in some way thet we are not aware of. SergeWoodzing (talk) 16:52, 20 September 2026 (UTC)

PS Just found this too. --SergeWoodzing (talk) 17:16, 20 September 2026 (UTC)

I don't know of any rule preventing you from creating a redirect. Dclemens1971 (talk) 20:16, 20 September 2026 (UTC)

 Done SergeWoodzing (talk) 00:28, 21 September 2026 (UTC)

Remove gender diverse people’s deadnames from intro and infobox?

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.

---

Currently, the deadname of a gender diverse person is either in the first sentence of the introduction or in the infobox on most pages. I don’t propose removing it entirely - that’s unencyclopedic - but being moved into a subsection would prevent bigots from finding a deadname as easily, and from supportive people accidentally stumbling upon a deadname (most trans people do not want to know someone’s deadname) RealA55A (talk) 08:44, 21 September 2026 (UTC)

See WP:DEADNAME. We should only include a mention of someone's deadname when it is encyclopaedically relevant to do so, how prominent that mention should be depends on the circumstances and isn't something that can be decided at this level. For example, the mention of Caitlyn Jenner's deadname is correctly more prominent than Curly Lawrence's. If you think the mention is too prominent in a particular article then that's something to discuss on the talk page. Thryduulf (talk) 09:55, 21 September 2026 (UTC)

WP:DEADNAME is useful, but the fact that a deadname can be prominent if the person was notable really is just poor. It should never be prominent, it’s really offensive and horrible RealA55A (talk) 10:35, 21 September 2026 (UTC)

Hard disagree. Some people have been vastly more famous under their deadnames than their new names. Prominence is required in those instances. — Czello ^(music) 10:53, 21 September 2026 (UTC)

I agree with Czello. It's also worth pointing out that how trans people regard their deadname varies, to some people it is "really offensive and horrible" while others actively embrace it, and of course everything in between. Thryduulf (talk) 11:04, 21 September 2026 (UTC)

"while others actively embrace it", yeah that's a lie. Are any of you replying actually trans? No! You don't understand shit. RealA55A (talk) 20:09, 21 September 2026 (UTC)

WP:CIVIL. Calm yourself down. — Czello ^(music) 20:12, 21 September 2026 (UTC)

This isn't someone we can have a reasonable conversation with.—S Marshall T/C 20:16, 21 September 2026 (UTC)

[personal attack removed]. RealA55A (talk) 20:25, 21 September 2026 (UTC)

For what it's worth, I'm trans and I believe Thryduulf is correct. Not all trans people fervently attempt to erase their pre-transition histories. Anecdotally, for me, labels such as names are arbitrary, so I'd be fine with being called most things. My past isn't uncomfortable to me like it is for some people. The intent in using an old name might be to insult a trans person, but that's not universally how it's received.

I also don't think articles should be designed to hide things below the lede because we assume nobody will read further than that. ~2026-51123-12 (talk) 09:30, 22 September 2026 (UTC)

That's not a very nice thing to say. MEN KISSING (she/they) Talk to me, I don't bite! - Solidarity 12:21, 22 September 2026 (UTC)

Just for the record I am trans and I am fine with WP:DEADNAME.

In addition, please refrain from using phrases similar to "Are any of you replying actually trans? No! You don't understand shit." Setting aside the vulgar language, this behaviour makes collaboration and communication with you impossible. I understand that you have strong feelings on this issue, but you should seek to explain these feelings rather than resorting to "you guys will never understand it". Because once again, the latter makes you incommunicable.

Leslie255 (talk) 00:48, 23 September 2026 (UTC)

No, not if they were notable under that name. The whole point of having it in the lead is because many people might be looking for someone under their deadname innocently, and this is a signal they've found the right person. I do endorse what Thryduulf says, however, in that it's done on a case-by-case basis. — Czello ^(music) 10:52, 21 September 2026 (UTC)

being moved into a subsection would prevent bigots from finding a deadname as easily

Can't speak for the other point (I don't really have a strong opinion on this) but the kind of people who are maliciously motivated to look up someone's deadname are not going to be stopped by this. Gnomingstuff (talk) 11:41, 21 September 2026 (UTC)

Hi @RealA55A, I stumbled on this topic and figured I would reply, as I am a trans woman and you seem interested in having a trans person's input.

I agree with the folks above that the way our policies on this topic look currently is quite fine, for a lot of the reasons the folks above have already said.

I'd like to disagree that it is offensive and horrible as a rule to make known a trans person's deadname. Not all trans people are going to feel so strongly about deadnames the way you describe, because trans people aren't going to all have the same preferences and perspectives. Calling a trans person by their deadname, that's almost never a nice thing to do, but documenting the encyclopedic fact that someone used to go by a different name that was associated with a different gender, I actually think that's beautiful. I do think people should be able to find trans folks by searching up the wrong name, and to then know more immediately that they are looking at the right article, because the alternative is to make it more difficult for people to navigate to articles about trans people.

There's not much that Wikipedia can do to make it harder for bigots to find a trans person's deadname in a lot of cases, I'm afraid. But, in the cases where the deadname truly is otherwise obscure, and the article is making a mention of it in an obscure but reliable source unnecessarily public, then that's likely to be the sort of privacy violation that ought to be removed under WP:BLP. On articles where you think the mention of someone's deadname is too prominent or even unnecessary, you can already go ahead and fix it. MEN KISSING (she/they) Talk to me, I don't bite! - Solidarity 23:58, 21 September 2026 (UTC)

This would make a few articles quite confusing. For example, Elliot Page is most famous for starring in Juno and Inception prior to his transition in 2020, and wasn't really in anything big until playing a minor role in The Odyssey back in July. A very large number of people searching for the Juno actor would have no idea he's now a trans man and would be very confused how they've landed on a page for someone called Elliot, if we didn't list that prominently.

Or take for example Maddy Thorson. When you download and boot up Celeste, the title card will tell you that the game was made by the studio "Matt Makes Games" (see e.g. mattmakesgames.com). When you look that up, obviously you get Maddy's article. If we don't prominently explain to people that this is actually the same person, that article would be very confusing for people reading it. Endwise (talk) 10:23, 22 September 2026 (UTC)

• Consider an academic like Megan Povey: "Previously, Povey published her scientific findings under the name Malcolm Povey, and she embraces that past. 'I want to claim my academic work produced in my past gender,' she says." from an article in Nature. She was a well-known academic and activist as Malcolm before becoming Megan in 2017. Her deadname of Malcolm belongs in her lead and infobox. PamD 14:02, 22 September 2026 (UTC)

  Someone looking for the author of a book such as this (Worldcat) needs to be able to see that the article they are finding is about that author. PamD 14:09, 22 September 2026 (UTC)

I agree with the others here that it would be inappropriate to never mention these names prominently. This is an area of frequent discussion and refinement. I suspect we will continue to make adjustments, and there will always be individual cases that require a special approach, but I object to this proposal. —Myceteae‍🍄‍🟫 (talk) 22:53, 22 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.