Wikipedia talk:XFDcloser

Bug with RfD template update after relist

When updating the RfD template after a discussion is relisted, day/month parameters don't get updated (examples ), so it continues linking to the old entry. 9ninety (talk) 12:43, 1 December 2025 (UTC)

@9ninety: This is not a bug, but actually is functioning as intended and needed. The timestamps need to remain to ensure that both the redirects are in the proper RfD month category, in addition to forwarding the reader to the initial nomination date first. (FYI, this has been discussed on this page before with the same answer: Wikipedia talk:XFDcloser/Archive 5#Date not updated when relisted at RFD.) Steel1943 (talk) 22:32, 9 January 2026 (UTC)

How is forwarding readers to the initial nomination date, forcing them to click multiple times to reach their destination, helpful? 9ninety (talk) 11:32, 11 January 2026 (UTC)

Month categories are irrelevant to this. CfD also has them but when you click the link in the nominated category page, you get to the right place immediately without having to follow the link trail left behind by the relisting. Why does XFDcloser behave sensibly in the case of CFD (example) but not RFD? Warudo (talk) 20:58, 28 January 2026 (UTC)

Pinging @Steel1943. 9ninety (talk) 11:54, 20 February 2026 (UTC)

I already explained the reason why things function as they do. If you have issues with it, take it over to WT:RFD as this is no longer a XFDC issue, considering you are now going into the weeds of why all the XFD forums are set up differently. Steel1943 (talk) 22:08, 20 February 2026 (UTC)

Why is core.js minified?

Tracked in github.com
Issue #105

Gadget code has to be validated and will be minified by the server anyway, so all the minification in the MediaWiki namespace does is make it harder to locate which part of the code is responsible for what and it seems pointless and counterproductive. Nardog (talk) 15:05, 25 December 2025 (UTC)

I agree. Please feel free to join the discussion at https://github.com/wikimedia-gadgets/xfdcloser/issues/105. Patches welcome. –Novem Linguae (talk) 15:09, 25 December 2025 (UTC)

Problem with multiple-results CFD close

I am currently unable to close Wikipedia:Categories for discussion/Log/2025 December 15 § Category:Anthropophagy, which needs the "Multiple results" feature. I can select "Rename" for the first category, but when I try to type the name of the destination category (whether immediately when the border of the input box turns red, or after clicking it and turning it blue), text does not go into the input box. Instead, when I type "C", the pull-down changes to "Custom", which is obviously incorrect. If I select "Rename" for both categories, trying to type a destination starting with "C" changes both to "Custom". Trying to type in the "Rationale" input box after selecting "Rename" for both categories, leaving the destination input box borders red, has no effect. I am using firefox-146.0-3.fc43.x86_64 on Fedora Linux. -- Beland (talk) 03:08, 4 January 2026 (UTC)

Beland, I can reproduce this (also firefox). Pasting into the input field seems to still work. — Qwerfjkltalk 10:54, 4 January 2026 (UTC)

I'm using this workaround to close this specific discussion; for debugging purposes, I'm sure it can be reproduced with any multi-page nomination. -- Beland (talk) 04:48, 5 January 2026 (UTC)

Adding delete instead of custom result on TFD

See e.g. Special:diff/1331329095 and Special:diff/1331332383. I used a custom message both times. -- Beland (talk) 20:53, 5 January 2026 (UTC)

Question first, Beland, do you remember what you specifically laid out when you did this? I am assuming you used the Custom option with "redirect=yes" as the result, also unchecking the "result is a new sentence" box?

I ask because I think the = in the close is the reason; I made a test log entry with that rationale gave the same result, noting that removing the = gave the expected result. Primefac (talk) 11:37, 17 January 2026 (UTC)

I did select the Custom option and put "delete or add redirect=yes as specified by SilverLocust" as the custom outcome. I don't remember if I unchecked the "new sentence" box (I usually don't), but XFDcloser shouldn't put the wrong outcome whether it's checked or not. It seems properly handling the = is what's needed; I suspected that as well, because it's an unusual character to show up in this field. -- Beland (talk) 00:10, 18 January 2026 (UTC)

TFD closures not listing correctly.

For the last few days I have noticed that TFDs closed as delete and listed as "Orphan" are showing up as "Ready to delete". Just one (of many) examples: this diff. I specifically filed that as "orphan" yet it was placed in "ready to delete". This is causing major issues at the holding cell. @Evad37 and Novem Linguae: is this something you can look into? Happy to provide more examples if it would help diagnose the issue... Zackmann (^{Talk to me}/_{What I been doing}) 04:17, 17 January 2026 (UTC)

Did this used to work but recently broke? If so, when did it start? –Novem Linguae (talk) 04:23, 17 January 2026 (UTC)

This was working perfectly for a LONG time. Best I can tell it started about a week ago? I've been noticing a lot of things listed in "Ready to delete" that have not been orphaned. Then when I closed things as "Orphan" I realized what was happening. Zackmann (^{Talk to me}/_{What I been doing}) 04:25, 17 January 2026 (UTC)

Do any of the December commits look like they could be the cause? I don't see any commits changing TFD, but if this suddenly started a week ago, it's worth checking. –Novem Linguae (talk) 04:42, 17 January 2026 (UTC)

Nothing jumps out at me, but I will be honest this is a bit beyond my level of expertise. I can assure you that it is definitely not working the way it was a few weeks ago. Sorry I can't give you an exact date...

@Gonnym, Plastikspork, Pppery, Jonesey95, Primefac, and HurricaneZeta: You all are frequent editors of the holding cell... Have you all been seeing the issue I describe above? Do you have any idea when it started? Zackmann (^{Talk to me}/_{What I been doing}) 04:50, 17 January 2026 (UTC)

Someone deleted a section called "Meta" between December 31 and today. Is the XFDCloser tool counting page sections and off by one? – Jonesey95 (talk) 06:35, 17 January 2026 (UTC)

Could the removal of the. eta heading be a problem?? (Pretty sure I did that....) Perhaps it is expecting X number of headings?? Zackmann (^{Talk to me}/_{What I been doing}) 06:38, 17 January 2026 (UTC)

Very short answer is yes, it goes by section number so if a section is deleted (or added) it messes things up. Primefac (talk) 11:15, 17 January 2026 (UTC)

This XFDcloser code in Venue.js does suggest that the holding cell section order is hard-coded: https://github.com/wikimedia-gadgets/xfdcloser/blob/f06a7a189f13966ba0c2ae2710a943d8e59f48bc/xfdcloser-src/Venue.js#L182-L193

Would recommend adding the meta heading back temporarily, or someone writing a patch for XFDcloser. Looks like an easy patch. I'll try to review it once it's written. –Novem Linguae (talk) 15:06, 17 January 2026 (UTC)

I've already readded the header (apologies for not making that more clear), though I object to making it temporary -- that section has been there since we reorganised the page a half-dozen years ago. Primefac (talk) 15:17, 17 January 2026 (UTC)

I saw the issue yesterday I think but didn't notice it before (but wasn't keeping too much attention recently). I also don't close discussions so wouldn't have seen it right away. Gonnym (talk) 11:15, 17 January 2026 (UTC)

Looks like it's fixed already but I noticed that here this went into the ready for deletion section when I closed it as orphan. HurricaneZeta^C 15:06, 17 January 2026 (UTC)

I mean, it got fixed four hours ago and your diff is from four days ago. Primefac (talk) 15:19, 17 January 2026 (UTC)

Playing catch up here... But looks like this is all on me for deleting the Meta heading! Facepalm That's on me!! Sorry folks!! Zackmann (^{Talk to me}/_{What I been doing}) 16:27, 17 January 2026 (UTC)

So this definitely appears fixed. Sorry again as this was all caused by my removal of the Meta heading! No clue why I did that.... Lesson learned! User:Novem Linguae really appreciate your quick response to my query here! Zackmann (^{Talk to me}/_{What I been doing}) 17:06, 17 January 2026 (UTC)

Sure no worries. Fixed. –Novem Linguae (talk) 21:22, 17 January 2026 (UTC)

Suggestion for "Outline" pages

Hey, It looks like XFDCloser removes newly-minted redlinks but keeps the text intact when a page is deleted. That makes sense in most articles.

It doesn't make sense on outline pages, though.

See here for one example:

Actual behaviour: see above

Suggested behaviour: because an outline page is always a collection of (mostly) internal links, IF a link in an Outline page appears in a list (bullet pointed or numbered) AND it doesn't have any sub-items in that list AND it has to be removed by XFDCloser THEN XFDCloser should remove the whole line instead of just the hyperlink.

The reasoning behind this is that it looks weird for just the text to be there, as if an article should exist (it probably shouldn't because it was just deleted), or it has to be replaced by an external link (potentially messy).

What do you think? 🔥Komonzia (message) 01:36, 1 February 2026 (UTC)

I feel like that would be horribly messy to code. I will note that XFDC already gives the option to remove list items when closing a discussion, so I think it's more the case that closers should be more considerate of what should be removed and what should be delinked (instead of what I would guess is simply an all-or-nothing approach). Primefac (talk) 15:16, 1 February 2026 (UTC)

Okay, that sounds reasonable, thank you :) 🔥Komonzia (message) 16:06, 1 February 2026 (UTC)

Delete TfD subpages

Tracked in github.com
Issue #85

I'm gonna raise this 4 year old request again: Wikipedia_talk:XFDcloser/Archive_5#Feature_request:_Delete_TFDd_template_subpages. I would use this feature essentially every time after manually doing a quick check. Much faster than using twinkle on them all separately. I don't know how other TfD closers do it but I reckon I'm not the only one. Trialpears (talk) 18:01, 5 February 2026 (UTC)

I don't hit them all separately, I use d-batch after getting the list of subpages (though that does require manually typing in the rationale).

But yes, a nice little poke for this showing that it's wanted by more than just a couple of admins is good! Primefac (talk) 10:22, 6 February 2026 (UTC)

Agreed. I added a comment to the GitHub ticket and I added the "frequently requested" tag thanks to this post. Someday if myself or someone does a burst of work on this, and we filter by the "frequently requested" tag, that'll put this near the top of the list. –Novem Linguae (talk) 08:00, 7 February 2026 (UTC)

Typing in "multiple results" fields yields strange results

Tracked in github.com
Issue #103

Instead of text appearing, the dropdown menu options change/cycle as raised and confirmed here. Iseult ^Δx talk to me 16:56, 21 March 2026 (UTC)

Iseult, could you be a little more specific about what you're doing and what's happening instead? Maybe I'm just misunderstanding, but I don't see why you would be typing in the dropdown menu rather than selecting one of the options (such as "custom"). Extraordinary Writ (talk) 17:06, 21 March 2026 (UTC)

Extraordinary Writ, I'm trying to close a batched CfD as custom rename. The consensus I read was for the categories to be renamed to something not in the original nom, so I selected "multiple options" in the bottom left of XFDCloser and tried to close the renames individually to their new target, which I tried to type in the non-dropdown. But even if I'm not supposed to type in the open field, the rationale field under multiple options also doesn't take input. Iseult ^Δx talk to me 17:19, 21 March 2026 (UTC)

Iseult, this is how it looks for me—is it different for you, or am I just confused? Extraordinary Writ (talk) 17:34, 21 March 2026 (UTC)

Extraordinary Writ, that's what I see asides from the non-dropdowns being able to take input. This persists for me even without browser extensions; I'm using Safari on desktop. Iseult ^Δx talk to me 17:47, 21 March 2026 (UTC)

Okay, it works for me on Chrome but not on Firefox. It looks like it's been previously reported here and here. (Firefox did still let me paste into the box, for what it's worth.) Extraordinary Writ (talk) 17:56, 21 March 2026 (UTC)

Thanks, EWrit. Pppery, workaround identified. Iseult ^Δx talk to me 18:16, 21 March 2026 (UTC)

Thanks Novem Linguae for filing the bug. Could not respond or thank you in the previous thread which got archived. Jay 💬 16:36, 5 May 2026 (UTC)

Problem with beta

The close etc buttons did not show until I disabled the beta version using the XFDC prefs menu which still was accessible. I don't know what clashed with the script - feel free to check my js pages. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 01:16, 31 March 2026 (UTC)

Beta and non-beta code appear to be in sync ( and ), and I don't see anything crazy in your user .js files. Anyway, if turning off beta fixed it, that's great and we can probably just leave it at that.

A year or two ago I actually modified the deploy script to publish exactly the same thing to beta and non-beta since it's a burden to remember to update both of them, and sometimes I was forgetting and it was causing beta people to report bugs that had already been fixed. So if everything is working correctly, there is currently no difference between beta and non-beta.

Hope that helps. –Novem Linguae (talk) 08:03, 31 March 2026 (UTC)

Extra steps needed for merge closures

Flagging @FaviFake's note as I'm sure others aren't as updated on the post RfC changes. This is one step that the script doesn't (yet?) handle that we'll need to. Star Mississippi 21:23, 10 April 2026 (UTC)

I don't see any xfdcloser text in the edit summaries on the history page of that diff. I don't think xfdcloser was used to generate the code that was corrected in that diff.

Looking at xfdcloser's code, xfdcloser appears to use {{Afd-merge from}} and {{Mfd-mergefrom}}, which are different templates. –Novem Linguae (talk) 22:02, 10 April 2026 (UTC)

XfD shows here @Novem Linguae which is the AfD close. I guess it's less tool issue and more new step needed? I don't recall running into this when closing AfDs as merge before, but it's possible editors cleaned up without flagging. Star Mississippi 22:49, 10 April 2026 (UTC)

Thanks. Maybe @FaviFake can weigh in to clarify. –Novem Linguae (talk) 03:37, 11 April 2026 (UTC)

Sure. Prior to the PAM-AFD merge, only the source article was marked as "being merged into" another, so the destination was not tagged. (I suspect this was because AfD merges were mostly used for small articles or stubs, while bigger merges were proposed at PAM.) PAM, however, required both pages to be tagged as being "proposed for merging" and, after the discussion was closed, as "being merged" per consensus.

Once Twinkle will be updated, the {{merge from}} tag will be automatically added to both pages after the discussion is started. After an AfD is closed with consensus to merge, the tag on the destination article should therefore be updated by XFDcloser, from {{merge from}} to {{being merged}} (or one of their many redirects). If it's not already present, its format should be:

{{Being merged from|Nominated article|afd=Debate name|date=April 2026}}

See WP:AFD § Merge for all the necessary template updates after a merge closure. FaviFake (talk) 06:04, 11 April 2026 (UTC)

I also realised that more than 1 destination page can be tagged as being proposed for merging, so these tags should also be removed. For example, the tag removed in Special:Diff/1348191195 was added by me after this comment.

I think the removal could be technically implemented in XFDCloser by checking the "What links here" of the AfD discussion page, checking every page to see if the link comes from a {{merge from}} tag or one of its redirects, and and remove it from all pages that contain that template.

Or maybe the closers should just be required to check if anyone in during the discussion has mentioned having tagged other pages as destinations, and remove them manually? FaviFake (talk) 07:03, 11 April 2026 (UTC)

If you can type up a ticket here with the exact changes you want, similar to the format you used in this comment (a bulleted list of things to change in the user interface and in the wikicode writing algorithm), that'd be super helpful. –Novem Linguae (talk) 21:33, 11 April 2026 (UTC)

 Done . FaviFake (talk) 08:09, 12 April 2026 (UTC)

@Novem Linguae I've thought about which tool you should update first, after the first small Twinkle patch (#2345) is implemented, and I now think XFDcloser should be updated (Update and remove leftover {{Merge}} templates after closing an AfD as "merge" #135) before the rest of the Twinkle module. The main problem with Twinkle was the tagging, but that will be fixed in the Monday patch, so now we have two smaller problems:

• Use more detailed tags on the pages (allowing the user to pick a target and tagging the target as well), or
• Update or remove the existing tags on the target articles, so that they don't remain in the wrong backlog.

The second issue seems more pressing to me, because AfD closers (rightfully) don't update the tags on the target, but only on the source. This causes the articles to remain in the wrong backlog until someone (usually me) updates them. BUT, if Twinkle is updated first, these tags will be placed automatically on even more target pages by the nominators, so there will be even more target pages that are incorrectly categorised.

So I just think XFDcloser should be updated before Twinkle, to avoid creating more of a mess, especially now that the backlogs are being cleaned up. As I said on GitHub, there won't be any issues if my proposed XFDcloser fix is implemented before the full Twinkle update. FaviFake (talk) 13:15, 26 April 2026 (UTC)

Twinkle PR 2345 is actually a pretty big patch.

It sounds like you are going to need another big Twinkle patch in the future? This is news to me. I thought Twinkle updates would be done after deploying 2345. Can you do me a favor and file a ticket for the remaining Twinkle work?

Anyway, I was planning to deploy 2345, then work on XFDcloser ticket 135. It sounds like that is the order you're proposing above, so I think we're still in alignment. –Novem Linguae (talk) 11:08, 27 April 2026 (UTC)

@Novem Linguae Whoa, I did not realise that patch would include every feature I suggested! How did you write it and release it that fast? I stepped back from GitHub in the last few days, and for some reason I thought it only included a couple of interim improvements.

If it included everything in the ticket, than there aren't any other Twinkle updates needed, thanks so much! I'm impressed! Sorry for my misunderstanding :) FaviFake (talk) 17:00, 27 April 2026 (UTC)

Seems like closing does not include removal of the {{merge from}} tag and replacing it with {{afd-merge from}} on the target's talk page still, only the initial placement on creation of the AfD, if I understand correctly.

Also see this comment; there are still going to be quite a few more changes required for this whole transition to be "complete". |target= is really only a temporary solution. ~ oklopfer (💬) 17:24, 27 April 2026 (UTC)

@Oklopfer Yes, this patch was just for Twinkle. XFDcloser will be updated later and it'll fix all the various templates on the source and destination pages. The issue is at #135 FaviFake (talk) 17:56, 27 April 2026 (UTC)

@Novem Linguae, I found another issue that should probably be fixed. When an article at AfD has already been merged and the discussion is closed with XFDcloser, the {{Afd-merge to}} template is added to the page even if by now it's already a redirect, thus breaking it. See Special:Diff/1354706733. Could you prevent the banner from being added to the source?

Also, when discussions will be closed as merge after the huge XFDcloser patch you're currently working on, second banner will incorrectly be added to the destination article. I thought you might need to consider this in case you haven't coded that part yet. Should I add this to the GitHub issue? FaviFake (talk) 14:17, 18 May 2026 (UTC)

Yes. Please add all that to the GitHub issue. You design and I code :) –Novem Linguae (talk) 14:22, 18 May 2026 (UTC)

I like this arrangement! I'll try to find the time to do it :D FaviFake (talk) 14:29, 18 May 2026 (UTC)

@Novem Linguae  Done. Everything should be ready now! FaviFake (talk) 16:13, 23 May 2026 (UTC)

Wrong date relist shortly after midnight

Special:Diff/1348490598 was relisted today at 00:05 (UTC), but was instead moved to the end of yesterday's CfD log page. –LaundryPizza03 (dc̄) 00:08, 13 April 2026 (UTC)

Adding a link to internal search in Template:Rfd2

See Template talk:Rfd2#Adding a link to internal search. Please reply to indicate whether this change can be made without impacting XFDcloser. Thanks, wbm1058 (talk) 15:08, 20 April 2026 (UTC)

Could not close discussion with italicized title

Tracked in github.com
Issue #137

I wasn't able to close WP:Redirects_for_discussion/Log/2026_April_28#Baculentulus_species until I removed the italics markup from the topic title. The error "Closing discussion: Aborted. Possible edit conflict detected, found section heading.. was similar to this issue from 3 years back. Jay 💬 16:50, 5 May 2026 (UTC)

Same for WP:Redirects_for_discussion/Log/2026_April_29#Culoptila_species. Got error: Possible edit conflict detected, found section heading"Culoptila species" Jay 💬 05:37, 6 May 2026 (UTC)

Is the new AFD merge thing messing up TFD?

I saw it once yesterday and thought it might be a glitch on my end, but I just closed a TFD as "merge" and saw that {{John Lennon songs}} wasn't edited and {{John Lennon singles}} didn't have the TFD banner removed. I know there has been some mucking about on the backend with the new AFD-also-does-merge-discussions thing, has that had a knock-on effect to TFD? I know you watch the page Novem Linguae but this seems like a slightly more ping-worthy issue given how many discussions I usually close this way (and now how many I'm going to have to go back and double-check to make sure they all closed properly. The last-known good merge close for me was 10 May, if that helps any.

I would note this only seems to be affecting TFMs, I did a spot-check of my recent no-consensus closes and they all did what they should do (i.e. close discussion, remove tags, add old TFD notice to talk). Primefac (talk) 12:21, 31 May 2026 (UTC)

I don't think the changes to afd should have affected tfd. I will need to do some more thorough testing though. I can rule it out by reproducing this on test wiki, loading an old version of xfd closer, and then testing on testwiki again. Stay tuned. –Novem Linguae (talk) 06:46, 1 June 2026 (UTC)

Rash of unhelpful XFD users

Over the past 6 months, there have been a number of relatively new wikipedians who have stumbled onto this tool and wreaked havoc on the XFD process by improperly relisting or closing discussions. I will not list names here, but I think it is time for a discussion about whether or not this tool should have some restrictions on who can use it. Setting aside how that would be done from a technical standpoint, I am wondering if there is any support for restricting this tool so that it cannot be used by new inexperienced users. I have found that these new users stumble onto this tool and decide to quickly start closing things that they have no business closing. The nature of the way that this excellent tool works means that these edits are very complicated to undo as they usually involve edits to multiple pages at the same time. Does anyone have any thoughts on this? Zackmann (^{Talk to me}/_{What I been doing}) 22:01, 31 May 2026 (UTC)

If we were to do it (not sure I have an opinion on that at the moment), WP:AFCH and WP:AWB have checkpages, we could use a similar setup (my preference would be more towards the AFC model where admins/NPP are automatically enrolled). Primefac (talk) 22:05, 31 May 2026 (UTC)

I think this would be a great idea and would help trim down the issue. As a non-admin who actively uses this script, I would even be in favor of giving up my access to it if the decision was made to restrict to admins-only. At this point I think allowing anyone to use it, is doing more harm than good.

@Primefac: as an admin yourself, can you advise on best way forward? Obviously I just started this discussion and want to hear other input, but does this require an RFC to enact? Can it be simply discussed on this page? Zackmann (^{Talk to me}/_{What I been doing}) 22:09, 31 May 2026 (UTC)

Eh... it's a formal gadget so it would probably require an RFC, but there would be a lot of hashing out to do in order to present a single (or maybe two) option(s). It would be best to get a small/local consensus before anything like a full-on RFC. Primefac (talk) 23:38, 31 May 2026 (UTC)

Agreed. I will let this play out a bit more but plan to present an RFC down the line. Zackmann (^{Talk to me}/_{What I been doing}) 23:47, 31 May 2026 (UTC)

@Novem Linguae and Evad37: as the author/maintainers would love to hear your input on this as well. Zackmann (^{Talk to me}/_{What I been doing}) 22:10, 31 May 2026 (UTC)

Sounds like it's already restricted to extended confirmed users. Anyway, I would recommend taking a look at the type of users that are causing problems, and then proposing a specific restriction that would exclude these users. What did you have in mind? A whitelist? A higher edit count than 500? Admin only? Would this apply only to afd?

Also, myself and some others have long been in favor of only admins being able to close or relist afds. That might be worth RFCing on the main afd page. In your RFC vote, consider providing recent diffs to strengthen your case. –Novem Linguae (talk) 06:48, 1 June 2026 (UTC)

Only restricting access to XFDcloser (beyond the current 500/30 requirement) would just lead to more manual closures, which tend to be even more of a disaster, so this would probably need to be a conversation about tightening WP:NACD. On that front, I sympathize with the problem, but I'm not sure the cost-benefit ratio of what you're suggested would really make sense. The guideline gives admins a lot of tools for dealing with bad closures—most importantly WP:REOPEN, which quite a few of us are not shy about using—so I think the issue is less about the rules and more about bringing problems to admins' attention. If you do see a issue and you've unsuccessfully tried to address it with the closer (recognizing that they're likely acting in good faith—I know I was back in my BADNAC days!), then you're always welcome to leave me a note. It would be nice to make NACs easier to track, though: there are definitely plenty of things that have slipped through the cracks over the years, including closures by UPEs. Could we get a tag for edits made with XFDcloser? I know I at least would find that useful. Extraordinary Writ (talk) 23:16, 31 May 2026 (UTC)

@Extraordinary Writ: while, you make a good point, I disagree that it would just lead to more manual closures. The numerous cases that I have seen in the last few months were all new users who stumbled upon this script and very clearly realized that they could quickly make massive changes with a few clicks of a button using a script. The act of manually closing a discussion is much more labor intensive and I just don't see a sharp rise in these occurring. In each of these cases, ultimately an admin DID step in and in at least one of the cases I believe a TBAN was issued to a user (note that I am intentionally not listing usernames here).

There will always be bad apples who seep through the cracks, but I think upping the requirements here could really help. Primefac makes a great point about WP:AFCH having a check page. Technically, anyone can review and accept drafts, they don't need to have access to the WP:AFCH script. But we put safeguards in place to limit those who can use the tools we already have. I.E. we aren't going to make it easier for those without what the community has deemed "appropriate experience" to perform edits using scripts.

I do agree that a review of WP:NACD may need stricter standards and I will likely initiate that discussion as well regardless of the outcome here, but I think this could genuinely be a step in the right direction. Zackmann (^{Talk to me}/_{What I been doing}) 23:30, 31 May 2026 (UTC)

(edit conflict)Weird, I thought it had a tag already. Primefac (talk) 23:38, 31 May 2026 (UTC)

The automatic summary does, but not in the same way as, like, Visual edit or something. 🫀 Crash // Organhaver ( it / he | talk to me, maybe? ) 01:27, 1 June 2026 (UTC)

Right, my point was that I thought we already had one. XFDC should absolutely have a tag. Primefac (talk) 21:56, 4 June 2026 (UTC)

Primefac what is the process for getting a specific tag? I legit have no idea how that works... Zackmann (^{Talk to me}/_{What I been doing}) 22:08, 4 June 2026 (UTC)

I split this thought into a new thread; I'll add some more later when I'm done with what I'm doing. Primefac (talk) 22:17, 4 June 2026 (UTC)

Bumping this. Does anyone else have any opinions on this before I work on formulating an RFC? Zackmann (^{Talk to me}/_{What I been doing}) 23:11, 3 June 2026 (UTC)

I left a notification at WT:DELPRO and WT:AFD. Extraordinary Writ (talk) 23:37, 3 June 2026 (UTC)

Does this apply to just AFD, or to all the deletion venues? — Qwerfjkltalk 13:43, 4 June 2026 (UTC)

@Qwerfjkl: this would apply to the use and implementation of the XFDcloser tool, so anywhere that the script runs. I.E. All deletion venues. Not trying to be pedantic in my response, just clarifying that the implementation of this restriction would be at the code level of the script so it would not be based on what page/deletion venue you are at but instead run at the time you try to load the script. Zackmann (^{Talk to me}/_{What I been doing}) 16:13, 4 June 2026 (UTC)

Zackmann08, in that case I think this is a very bad idea as it stands. I'm mostly familiar with CfD, which has the majority of discussions closed by non-admins and is perpetually backlogged. I fear such a move would be a death knell. Even a whitelist à la AWB or AFC would discourage editors from joining in. — Qwerfjkltalk 17:57, 4 June 2026 (UTC)

The process for whitelisting editors takes minutes. I think you are dramatically overestimating the requirements for making this happen. Zackmann (^{Talk to me}/_{What I been doing}) 18:37, 4 June 2026 (UTC)

CFD is already overwhelming enough with the process for closing discussion; I can't imagine that adding more impediments will improve that situation. And I have some doubt that I could ask to be whitelisted and minutes later find myself on the whitelist. — Qwerfjkltalk 20:07, 4 June 2026 (UTC)

Sorry, that is 100% correct. The process of actually adding a name is quick, but yes it requires someone to check the page and add the name. I think that the initial setup would be pretty straight forward. We can quickly and easily whitelist names of those who are already active in the CfD process.

However, if your specific concern is about CfD exclusively (which it sounds like it is) I don't see any technical reason that the whitelist check could not be skipped for CfD? That should be a pretty easy regular expression to write...

As an alternative idea, we could also do a slow rollout. This is a half-baked idea, but we could basically send out a message to people using XFD saying "hey, in the coming weeks this tool is changing so you have to be whitelisted to use it. Submit your request here now to make sure that in 30 days when the change happens, you don't loose your access." (obviously can workshop the language...) Zackmann (^{Talk to me}/_{What I been doing}) 20:14, 4 June 2026 (UTC)

Zackmann08, to be frank, my concern is that you have a problem at AfD with badnacs and you want to fix it by making other deletion venues harder to close. I apologise if I'm misconstruing the situation, but your decision to not point to any examples of this problem (which I appreciate is to avoid "naming & blaming") makes it hard to actually assess how much of a problem this really is. — Qwerfjkltalk 09:48, 5 June 2026 (UTC)

• We really need concrete examples to show how much of a problem this actually is. I'm a bit sceptical as I haven't noticed an up-tick of deletion reviews or ANI referrals. I would oppose limiting closures to admins as there are a number of very good experienced NAC closers and also a minority of admin closers who are let us say sometimes over-imaginative in some of their closures that end up at deletion review, imv Atlantic306 (talk) 00:31, 6 June 2026 (UTC)

  @Primefac: as an admin, can you advise here? I am willing to try to go back and pull usernames from past examples of issues at TFD. But I worry about being slapped with calls that I am intentionally besmirching another editor or something of that nature. There have now been multiple calls for examples to be provided... Is it safe to do so? Zackmann (^{Talk to me}/_{What I been doing}) 05:48, 6 June 2026 (UTC)

  Yes, but just present facts, no commentary. Let others make up their minds about the potentially problematic editing. Primefac (talk) 09:20, 6 June 2026 (UTC)

Feature request: adding a tag

Tracked in github.com
Issue #123

I hate to admit that the process for getting WP:AFCH a tag completely flew past me (it happened, and I'm not entirely sure how that happened), but XFDC should have its own tags for edits. There have been some grumblings about inexperienced users using this tool, and having a tag would make it a lot easier to grab all of those edits at once if it becomes necessary. I don't suspect there will be any opposition but before I go through the process of getting it 90% of the way there (so someone else can push the right button) I figured I'd get opinions on the matter. Primefac (talk) 21:58, 4 June 2026 (UTC) Added a link to the AFCH tags, git will need to be updated to play nice with the API and recognise the tag. I've also created the tag. Primefac (talk) 09:58, 5 June 2026 (UTC)

Support - Good call making this a separate thread. Independent of whether or not we put restrictions in place, we should definitely add a tag! Zackmann (^{Talk to me}/_{What I been doing}) 22:25, 4 June 2026 (UTC)

• Support – makes things easier to track. Extraordinary Writ (talk) 22:41, 4 June 2026 (UTC)