Wikipedia talk:Closure requests

Not marking conversations as done in triplicate

@Paine Ellsworth: Greetings! Regarding the edit summary note "gentle reminder to editor Beland to please sign your work": I am intentionally not doing so. I tweaked {{initiated}} so that it prints Done before items that are marked with "done=yes". I was tired of typing "done" three times every time I closed a conversation, once to mark done=yes, a second time to write a comment saying "Done!" and a third time in the edit summary. Now in addition to not being green or red, all the conversations that are done=yes are clearly marked with the word "Done" so it shouldn't be necessary to write a pro forma comment saying the same thing. -- Beland (talk) 08:33, 22 January 2026 (UTC)

To editor Beland: we agree that there is no need to be too "done redundant". What I ask is that you please remember to sign your work. Your sig includes a link to your talk page in case an editor has a question about your work. And although not as important as that, there are also editors like me who would like to see at a glance who closed a particular item without having to actually go to the discussion to see whodunnit. Not just here on this page, it would be good if you signed actual discussions you close, for example here, where I added your sig. So please, if it's not too much to ask, please let me and other editors know when you've closed a discussion, especially on this page (WP:CR), by including your signature to show your work. Thank you for your much appreciated help in closing these discussions! P.I. Ellsworth , ed. – welcome! – 09:42, 22 January 2026 (UTC)

PS. btw, I do like the "done" right at the beginning. It's always good to be right up front with a decision. P.I. Ellsworth , ed. – welcome! – 09:48, 22 January 2026 (UTC)

I already sign the close itself; anyone who has a question about the close should be looking at that page and not WP:CR. The person noting that the WP:CR request is satisfied is not necessarily the person who actually performed the close; sometimes I find that the discussion is already closed when I get there. If we are being paranoid that untrustworthy parties are closing discussions, we would actually want to check the pages where the close happens. -- Beland (talk) 10:27, 22 January 2026 (UTC)

As I said, we'd like to see at a glance who closed an entry rather than having to click a link and frequently have to scroll to find out who closed it. Life is short and there are a lot of other things we like to do, so why do you want to make it take longer for us to check these items? If you don't leave a signature, it's as if you're trying to hide something. or perhaps you're worried that someone might disagree with you? Why are you not proud enough of your work that you wouldn't leave your sig??? It's just 4 little tildes, after all. What's the big deal? P.I. Ellsworth , ed. – welcome! – 11:44, 22 January 2026 (UTC)

For the one-and-done cases (as opposed to where we're having a conversation about closing) I don't think it's useful to track on this page who did which closes. If there are people who can't be trusted to do closes without getting them reviewed but are in the habit of doing them anyway, then we should be just as interested in their closes that don't make it to this page.

No, I'm not boastful or prideful about my work. After reading through these heated discussions, I don't really have the emotional energy for that, and as uninvolved adjudicators, I actually think it's more appropriate for us to be humble. I'm not hiding anything, and resent the implication. My signature is plain as day on the page where I write the words that people disagree with. Given the disproportionate number of complaints and unwarranted appeals arising from closing these conversations (compared to the everyday ones that don't make it to this page), it seems people have few reservations about doing so. I haven't been doing closes because I'm looking for social approval or building karma (which isn't real, anyway). I've been doing them because 1.) I have made requests for closure, and I hope that doing the other tasks focuses attention and encourages cooperation on the discussions I can't close myself, and 2.) having unclosed discussions linger for weeks and months makes me anxious that we're wasting editor time and leaving some articles in a messy limbo.

Now I'm getting a complaint that I'm not double-signing and triple-done-ing every close. If we're going to build a bureaucracy like this on top of the already arduous close process, given everything else that's going on right now, I'd rather just not do them at all. So I'm going to take a break. Feel free to ping me if we get a streamlined process. -- Beland (talk) 18:36, 22 January 2026 (UTC)

This thread is as old as time itself, but FWIW I fully agree with you. I also sometimes avoid triple-signing the closures posted on this noticeboard. FaviFake (talk) 00:24, 10 August 2026 (UTC)

Retiring the Merge proposals section

Now that the Proposed article mergers process has been merged into AFD, the merge proposal section will need to be retired in a few weeks or months once the backlog of open PAM proposals is fully cleared. Since I've learned that I need to be very careful when editing this page, is there anything I would need to do other than simply remove the section? Again, this will only be relevant in a few weeks when the backlog of old discussions is cleared. I'm just asking early to see if there's anything else I will need to do when removing the section. @Redrose64? FaviFake (talk) 22:28, 24 June 2026 (UTC)

I don't think the section will need to be retired. Merges are still being requested, even though the place to request them has changed. BD2412 T 16:30, 25 June 2026 (UTC)

What would be the criteria for including them? Should an AfD discussion be listed there only if the nominator proposed merging, or even when there's mostly consensus for merging but the nomination was different? Should AfD discussions be moved to the Merge proposals section if the nominator proposed a merge? Template and category merge proposals are already placed in the XfD section, why should article merge proposals be any different?

The section is already empty, and I don't think people will actually list an AfD outside the XfD header. Why would they? FaviFake (talk) 18:22, 25 June 2026 (UTC)

Merge proposals are still explicitly "merge" proposals, and therefore not "deletion" discussions. BD2412 T 13:34, 26 June 2026 (UTC)

But CfD rename nominations are also explicitly not deletion discussion, yet they are placed on that section. Maybe it's best if the deletion discussion section is renamed to encompass all of XfD? FaviFake (talk) 17:15, 27 June 2026 (UTC)

I suppose that you could propose this change, and seek a consensus for it, then. BD2412 T 14:11, 30 June 2026 (UTC)

Well, that's why I opened this section. Do you agree that the section should be removed in a few months when the PAM backlog is cleared? FaviFake (talk) 17:49, 30 June 2026 (UTC)

I think it is a good idea to remove the merge section of this page, although it might also be a good idea to change the heading for the deletion section from "Deletion discussions" (which might seem to leave no room for merge proposals) to "Articles for deletion" (which would at least clearly indicate the exact part of the website that the section is intended to cover) or "Deletion and merge discussions" (which allows for both possibilities). Dionysodorus (talk) 20:58, 30 June 2026 (UTC)

What if we have a header with separate subheaders? Closers who are keen to work on merges would then have an easier time finding those discussions. BD2412 T 03:14, 1 July 2026 (UTC)

fwiw, I support your original idea. There is no need to retire the "Merge proposals" section, which should stay just as it is, a level-2 heading. If we make it a subheader, and in that case editors would have to use level-4 headings for entries instead of level-3, that would not be helpful for editors. I do support changing the "Deletion discussions" header to something like "XfDs". P.I. Ellsworth , ed. – welcome! – 10:22, 1 July 2026 (UTC)

I don't understand. A merge proposal of an article/template/category/etc is an XfD. In your proposal, are people supposed to list a merge discussion twice??? FaviFake (talk) 12:58, 1 July 2026 (UTC)

Uhm, no. Of course not. They list a merge talk one time in the "Merge proposals" section under a level-3 header – just like it is now. I think it's far better to maintain the status quo for that and keep the merger close requests separate from the other XfDs. When the transition is all finished, we can call the section "XfD merge proposals", oslt. Hope this helps! P.I. Ellsworth , ed. – welcome! – 21:42, 1 July 2026 (UTC)

They list a merge talk one time in the "Merge proposals" section under a level-3 header – just like it is now. I think it's far better to maintain the status quo for that
That's not the status quo though. The status quo is that all merge proposals (CfD, TfD, etc) go under "Deletion discussions", except article merge proposals. Those go under "Merge proposals". Why should AfD merge proposals be categorised differently from every XfD? FaviFake (talk) 22:33, 1 July 2026 (UTC)

By "status quo" I meant "the way it is being done now, in the present moment". I think editors who come to this page who look for merge discussions to close them shouldn't have to hunt for them in the XfD section. Merge talks should continue to be listed separately. I understand that you don't want that to be the case; however, I do want merger closure requests to stay separate from other XfD closure requests. So we can hopefully agree to disagree! P.I. Ellsworth , ed. – welcome! – 22:45, 1 July 2026 (UTC)

By "status quo" I meant "the way it is being done now, in the present moment".
Yes, that is what I meant as well. Afaik, in the present moment, merge proposals for non-articles are not listed under the Merge proposal section. It sounds like you want that to change. FaviFake (talk) 09:43, 2 July 2026 (UTC)

Now I'm confused. Please explain. You say "merge proposals for non-articles are not listed under the Merge proposal section." Then where are they being listed? P.I. Ellsworth , ed. – welcome! – 02:27, 3 July 2026 (UTC)

Under Deletion discussions. A merge proposal of an article/template/category/etc is an XfD, so all [non article] merge proposals (CfD, TfD, etc) go under "Deletion discussions". The Merge proposals section was there solely for PAM, and soon PAM will cease to exist. FaviFake (talk) 08:41, 3 July 2026 (UTC)

All that has been made abundantly clear, aaand...!... I'm all for it. I just don't get what the big deal is. Here we separate out the merges to help editors find them more easily. That should not change just because the discussions are held in a different place. Attaching mergers to AfD should not make it harder for editors. If it does make it harder, then maybe we should rethink it? P.I. Ellsworth , ed. – welcome! – 09:22, 3 July 2026 (UTC)

That section was necessary because PAM discussion used to remain open for months and years without being closed. AfD is a more streamlined process: AfD discussions don't need to be listed like PAM discussions because they're closed about 7 days after their last relist.

My point is that the section will remain empty. How many AfDs are there in Deletion discussion right now? None. And only about 5-10% of new AfDs are merge proposals. It is extremely unlikely that a merge discussion will ever need to be listed here, and if it does, it doesn't harm anyone if it's listed at XfD.

Also, again, if a section is named Merge proposals and another XfDs, an editor in theory should list it into both sections. Why wouldn't they? An AfD is an XfD. FaviFake (talk) 10:06, 3 July 2026 (UTC)

And yet, we see XfD entries here frequently in spite of it's streamlined process. The purpose of a separate merge section was and is to make merge entries easier to find for editors. Entering them twice is unnecessary – editors are sometimes unaware or unmindful, but they're not stupid. I support waiting to see what happens. P.I. Ellsworth , ed. – welcome! – 11:43, 3 July 2026 (UTC)

The purpose of a separate merge section was and is to make merge entries easier to find for editors.
That's already fulfilled by Category:Articles proposed for merging, and that wasn't really the initial purpose. When that section was created, the backlog of open merge discussion was years-long, and now it's down to just a few months.

At least we agree that § Deletion discussions should be renamed to "XfD discussions", right? (even though that would mean editors could pick either section to list a merge nomination...) FaviFake (talk) 11:47, 3 July 2026 (UTC)

Yes. (I've been transferring entries to their correct sections for many years now.) P.I. Ellsworth , ed. – welcome! – 13:10, 3 July 2026 (UTC)

Not a comment of support or opposition for anything; however, if some change is arrived it, it should probably be communicated with the maintainer of the ANFRC lister script. TarnishedPath^talk 03:19, 1 July 2026 (UTC)

I notified the maintainer. FaviFake (talk) 13:01, 1 July 2026 (UTC)

Thanks. Please ping me when this is removed, then in the user script, I can take it out of the dropdown box where the user chooses the section. –Novem Linguae (talk) 18:11, 1 July 2026 (UTC)

@Novem Linguae Heya, we haven't removed it yet, but we've renamed § Deletion discussions to § XfD discussions. FaviFake (talk) 13:15, 3 July 2026 (UTC)

Fixed. Although because that section was the only one with an HTML anchor, required extra code to unbreak things. –Novem Linguae (talk) 20:55, 5 July 2026 (UTC)

The extra section for merge proposals is confusing and unneccessary, given that the line between merge proposals and other AfDs is blurred. Joe vom Titan (talk) 16:08, 12 July 2026 (UTC)

Backlog tag

Does anyone know: Is the backlog tag added/removed automatically or manually? How many pending items trigger a backlog? Levivich (talk) 16:06, 12 August 2026 (UTC)

Manual. As far as I know, the automatic system only works on category pages. LightlySeared (talk) 16:20, 12 August 2026 (UTC)

Thanks! I wasn't sure, then, if the backlog tag should be removed? It seems to me that there isn't a backlog on this page, just a normal amount of pending requests (about 10), but is that considered a "backlog"? Levivich (talk) 20:03, 12 August 2026 (UTC)

Good question, but I'm the wrong person to ask, given that I haven't been around that long. Any of the more experienced closers want to weigh in? LightlySeared (talk) 09:22, 14 August 2026 (UTC)

There being no objection, by the power vested in me by virtue of my sacred office of Random Person on the Internet, I hereby declareth there beith not a backlog. Levivich (talk) 02:34, 17 August 2026 (UTC)

Filling out Initiated done= when a discussion is relisted

User:Redrose64 and I seem to have a different understanding of when to enter |done=yes on the {{Initiated}} template. See Wikipedia:Closure requests#Talk:Çekmeköy school stabbing#Requested move August 10 2026 and the thread below it (permalink). I relisted both of these RMs and indicated that in the CR listing. In my experience, we don't mark close requests as 'done' until the thread is closed. I routinely see editors make note that they have relisted a discussion or make other comments that other CR watchers may find relevant, and the discussions remain live until the thread is closed. Thus I did not mark |done=yes however Redrose64 keeps "correcting" me and saying |done=yes means "no further action required, thread may be archived". I don't want the threads to be archived. I don't see other CR closers doing this. My understanding is that the request is not fulfilled until the thread is closed or a decision is made that it does not require a close. Am I missing something? —Myceteae‍🍄‍🟫 (talk) 19:01, 23 August 2026 (UTC)

I would also request that @Redrose64 self-revert so that we can avoid an edit war while we sort this out. Again, I do not want Wikipedia:Closure requests#Talk:Çekmeköy school stabbing#Requested move August 10 2026 or Wikipedia:Closure requests#Talk:Kuopio school stabbing#Requested move August 10 2026 to be archived until the RMs are closed. —Myceteae‍🍄‍🟫 (talk) 19:04, 23 August 2026 (UTC)

I mean, this is Closure requests, not Relist requests. I don't think we should consider a request fulfilled until the discussion has actually been closed, so I agree that they shouldn't be archived. It's technically not true that no further action [is] required, since the discussion will still have to be closed later. Chess enjoyer (talk) 19:17, 23 August 2026 (UTC)

How much later? Closure requests is not an indefinite holding pen for anything that's not closed. RMs are routinely relisted without ever being mentioned at Closure requests. As for we don't mark close requests as 'done' until the thread is closed, we only need to go back two days to find this. --Redrose64 🌹 (talk) 20:28, 23 August 2026 (UTC)

How much later? – Seven days or so after being relisted, usually. I don't think that's a lot of time for this page.

RMs are routinely relisted without ever being mentioned at Closure requests – I'm not arguing that every elapsed RM should be listed here.

Editors list discussions here because they want them to be closed. Sometimes the responding editor decides that more participation would be helpful, and decides to relist it. There's nothing wrong with that, but the original editor's request hasn't been granted yet. Suppose they (or someone else who's involved) see(s) the discussion a week later, and thinks that it finally is ready for closure? They might list it here again, resulting in two listings for the same discussion. Does that sound good to you? Personally, I think it would be simpler if we just kept the first request unarchived until it actually gets closed. Even if that doesn't happen, keeping it around might get the discussion closed sooner since the listing adds visibility. I'm going to invite @Maddy from Celeste to this thread, since I'm disagreeing with an action they took. Chess enjoyer (talk) 20:58, 23 August 2026 (UTC)

I don't really have a strong opinion on this and nobody should presume that I did that because of some kind of special knowledge. For RMs I usually just work my way through WP:RMB and not here. This time I happened to know it was also listed here so I noted it here, and marked it done assuming it was a "dealt with for now" kind of thing. -- Maddy from Celeste (WAVEDASH) 21:08, 23 August 2026 (UTC)

Perhaps editors differ in their practice more than I realized. We also don't have to go back far to find examples like this where the relist comment was left in place for over a week before the template was marked as done. There's another current example on the page now at Wikipedia:Closure requests#Talk:EMI (disambiguation)#Requested move 10 August 2026. I learned the practice of making a note that I have relisted something, or taken some other action or have some insight to share, by observing other editors here. These updates, while not required, let other CR monitors as well as the requesting editor know that the request has been acknowledged even if it has not been completed. I find them helpful and my intention with making them is not to signal that the request is fulfilled or that other potential closers should not make their own independent assessment. These little status updates from other editors sometimes factor into my prioritization or call my attention to an aspect of the discussion that informs my assessment. As someone who also lists requests here, I don't think I've ever seen one marked done and archived before the linked discussion was closed. Anyway, I'm going to change two requests that started this back to |done=no for now while we continue this discussion. —Myceteae‍🍄‍🟫 (talk) 21:29, 23 August 2026 (UTC)

IMHO editor Redrose64 is correct in that WP:CR has in the past not been a holding area for relisted discussions. In the past I've marked CR entries relisted and have been reverted, but usually not. It's been a gray area for which I am lukewarm one way or 'tother. I do know that edit wars are to be avoided. Edit wars are another issue entirely. Talking about it here is the right thing; edit warring is just wrong. No more edits should be made on this subject until it has been fully discussed and editors come to consensus. P.I. Ellsworth , ed. – welcome! – 01:30, 24 August 2026 (UTC)

I don't think anyone has suggested CR's purpose is or should be to be to serve as a holding area for relisted discussions. But discussions do get relisted. Sometimes the relist is noted here but often not. —Myceteae‍🍄‍🟫 (talk) 07:29, 27 August 2026 (UTC)

Re. the repository, it's an implicit thing, I suppose. When I close a relisted CR item, it's usually after more than one relist. It can get a little long. I closed an RM recently that was relisted five times – rare, but it does happen. P.I. Ellsworth , ed. – welcome! – 09:54, 27 August 2026 (UTC)

I recently closed an RM that was listed here and was, in my opinion and several other editors here, in desperate need of a close despite having recently been relisted. I was glad the request had remained here so I could see and act on it, despite the relists. I could imagine a situation where an editor relists a discussion and determines that the closure request was unnecessary and the discussion is likely to be closed in the normal course following the relist. Ideally, I think the action and intention should be noted explicitly and the request marked 'done'. But I don't assume that every relist means "I think this should be off our radar". I have seen decisions to not close a discussion stated here, though not necessarily related to a routine relist. Not a perfect comparison, but I think there's some analogy to edit requests. Sometimes an editor will respond with a question, comment, refinement, opinion, or insight related to the requested edit but not mark it answered if they determine that the request is not resolved and is still worthy of consideration. This is distinct from declining the request. —Myceteae‍🍄‍🟫 (talk) 22:40, 27 August 2026 (UTC)