Wikipedia talk:Closure requests

Clarifying point 1?

Point 1 at the top of the page currently states:

Do not list discussions where consensus is clear. If you feel the need to close them, do it yourself.

However, for someone who is WP:INVOLVED (especially the author of the RfC), closing the discussion is highly discouraged even if the consensus is clear. Closure requests by involved editors have been nonetheless been denied on this basis (e.g. this request by the RfC's author). should point 1 by amended to clarify this?

Do not list discussions where consensus is clear, except if you are involved. If you feel the need to close them, do it yourself.

Chaotic Enby (talk · contribs) 16:06, 19 December 2024 (UTC)

That would mean that every single closure would need to come here, even if the result is unanimous. Is that good? That said, refusing to do a requested close when the consensus is obvious seems profoundly unhelpful, and demoralizing to people who are trying to avoid even the appearance of impropriety. -- Beland (talk) 01:36, 18 September 2025 (UTC)

I would say that point 1 should not be amended. Only RfCs that actually need an external closure should be posted here. There was a time a few years ago where an editor used to mass-post unclosed discussions here, and CR was flooded as a result, delaying the closure of discussions that actually needed closing.

If consensus is clear and nobody is likely to dispute it, there is often no need for a formal closure at all, or the closure can be done by an involved party such as the editor who opened the discussion: see the guidance at WP:Closing discussions#Closure procedure, including the footnote at the end of the first sentence. Dionysodorus (talk) 10:01, 18 September 2025 (UTC)

The issue is that the consensus level that would justify an involved close is much higher than a non-involved close (the note you mention talks about in uncontentious circumstances and takes an example where the discussion is nearly unanimous). I'm also not talking about mass-posting any discussions, but specifically discussions where the poster is involved and the consensus isn't clear-cut enough for them to close it themselves, even though it would be acceptable for someone uninvolved to close it. Chaotic Enby (talk · contribs) 16:41, 18 September 2025 (UTC)

I think point 1 is only intended to exclude discussions where the outcome is so obvious that a close is not needed or that the participants involved in the discussion can legitimately close it for themselves. That is to say, if consensus is clear, the participants should either just proceed accordingly or should close the discussion for themselves; if consensus isn't sufficiently clear to do that, the participants should wait for an uninvolved closer, usually by asking for one here. In any given case, it is up to the participants whether they think the outcome of the discussion is clear or whether to post it here, and I don't think any closer would object to being asked to close any discussion that any participant in good faith considers even slightly too unclear for an involved close to take place.

If we rewrote point 1 as you are suggesting, that would imply that involved participants in a discussion should post listings here even where the outcome is absolutely clear (and where they could therefore close the discussion for themselves). That would be a bad thing in my view, because it could lead to discussions being listed here unnecessarily, which could contribute to long backlogs forming at CR (as in the case of the mass listings, but for a different reason), which would make it harder for discussions that really do need closing to be dealt with promptly.

Also, the current phrasing is perhaps helpful in discouraging the minority in an RfC from obstructively insisting on a formal close when the discussion has clearly gone against them. I think this sometimes happens even as things are, and in such cases a formal close is usually necessary (if only to prevent the losing side from further lawyering or edit-warring against the outcome of the RfC), but it is a waste of everyone's time, and editors who are on the losing side in an RfC ought to be discouraged from doing this as far as possible. There's no way of preventing one or two opponents of an otherwise agreed decision from insisting on a formal uninvolved close, but if we amended point 1 as you are suggesting it could potentially have the unintended effect of actually encouraging people to do that. Dionysodorus (talk) 17:12, 18 September 2025 (UTC)

Thanks! I had a broader reading of point 1, where consensus is clear would also cover non-WP:SNOW cases where a consensus is visible but an outside closure would still be ideal. I agree with your point of including that any participant in good faith considers even slightly too unclear for an involved close to take place, and wonder if that could be clarified in the text in any other way?

Regarding your last paragraph, wikilawyering is something that can always happen, and, if there is an involved close, disruptive editors on the minority side could also very much insist on undoing the close for that reason. Maybe that could also be clarified in the text here? Chaotic Enby (talk · contribs) 17:37, 18 September 2025 (UTC)

@Chaotic Enby: What if point 1 said something like this?

Do not list discussions where the consensus is obvious.

In discussions where consensus is entirely clear to everyone involved, there is no need for a formal close: just go ahead and implement the decision! Discussions should only be posted here when an uninvolved closer is actually needed to resolve the matter.

That might be clearer, since it would avoid suggesting to involved participants to "do it yourself", which might in some cases be misleading. Dionysodorus (talk) 18:05, 18 September 2025 (UTC)

That would work great for me! Chaotic Enby (talk · contribs) 19:03, 18 September 2025 (UTC)

FWIW, sounds good to me too. -- Beland (talk) 19:35, 18 September 2025 (UTC)

Hmm - perhaps ideally it would be good to have a slightly wider consensus for such a rewording; but maybe we could make the change in a few weeks' time if no-one has objected by then? Dionysodorus (talk) 11:28, 20 September 2025 (UTC)

I have boldly updated the text without prejudice to yet-unheard objections. -- Beland (talk) 22:29, 27 September 2025 (UTC)

Move and merge requests should have their own section.

I propse this page gets two dedicated sections titled #Merge proposals and #Requested moves between #Deletion discussions and #Other types of closing requests. This is to split up the latter section and hence make it easier to get an overview. Thoughts? Joe vom Titan (talk) 10:32, 11 May 2025 (UTC)

Support. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:09, 11 May 2025 (UTC)

Done marker

Would there be support for changing the mechanism for indicating completion? It seems flipping the template to "done=yes" without putting {{done}} happens a lot, and vice-versa. We could have the bot archive in response to seeing "|done=yes}}" and have {{initiated}} display the word "done" in a celebratory color or something? -- Beland (talk) 01:34, 18 September 2025 (UTC)

@Beland: They have different purposes. The |done=yes parameter in {{initiated}} removes its colouring, so that it gets the default colour - black text on white, unless you are in dark mode. The yes value also deactivates Category:Administrative backlog. Absence of this parameter displays the text in blue, green or red, depending upon (a) how long ago the timestamp is and (b) the value of the |type= parameter. This coloured text is the attention-getter: blue means "somebody would like this to be acted upon but a few more days won't matter"; green means "this is now due for action"; red means "this is long overdue". Setting |done=yes essentially means "no further action required". The archiving bot is ClueBot III (talk · contribs) which ignores {{initiated}} entirely - it looks for the presence of specific templates, these are listed in the |archivenow= parameter of {{User:ClueBot III/ArchiveThis}}. If none of these templates is present, the thread will not be archived for 4368 hours (6 months). If you want ClueBot III to be amended, you need to ask its bot-ops. Past experience suggests that there is reluctance. --Redrose64 🌹 (talk) 18:01, 18 September 2025 (UTC)

Yes, my understanding aligns with your explanation. It looks like there's no need to modify the bot; we control its behavior with the "archivenow" parameter in {{User:ClueBot III/ArchiveThis}} on Wikipedia:Closure requests itself. I do find the color change useful. It sounds like not adding "done=yes" would be a problem for catgegorization if the snippet gets archived, so it makes sense to me that the bot should refuse to archive it until that parameter is set properly? -- Beland (talk) 19:33, 18 September 2025 (UTC)

Even having been reminded about setting done=yes, I still occasionally forget. Part of the problem is that you can't see {{initiated}} if you hit "Reply" instead of editing the whole section's wikitext. Since no one has objected, I have attempted to tweak the ClueBot III directive to look for "done=yes". I'm not entirely confident I've done it correctly, due to escaping, but will wait a few days to see if it's still working. -- Beland (talk) 22:25, 27 September 2025 (UTC)

Archiving

Redrose64 It appears you were referring to this comment of yours, and similar comments:

we need the extra dummy subsections because of a bug in ClueBot III (talk · contribs), so instead, each new request is added as a last-but-one subsection. The dummy subsections are formatted as level 4 headings, the same level as the real requests, so that ClueBot III (talk · contribs) doesn't trash the following level 3 heading when archiving. See for example this archiving edit and this repair, dating from before we introduced those dummy subsections. There was a discussion on the bot talk page, which amounted to "this is how the bot works, get used to it". We tried hidden comments: they didn't work, as ClueBot III trashed the hidden comment too. After we made some more adjustments in May 2017, finishing with this edit, the archiving has worked smoothly.

I think you'll excuse me if I missed that; that discussion was 7 years old.

Do you think the bot would still work properly if the instructions weren't displayed in a hidden comment and we kept all the dummy headings, as you called them? I really think the instructions should be made more accessible to users of this page. FaviFake (talk) 14:58, 15 November 2025 (UTC)

@Redrose64 I have an idea; since the a header like ===Place new administrative discussions above this line using a level 3 heading=== is needed, we could use just a blank Unicode character instead of a header. This way, it'll mostly look like a blank line between h2 sections.

This would also have other benefits, as it would be less misleading. New discussions shouldn't be placed directly "above this line", they should actually be placed based on when they were initiated. I've seen this has also been brought up in past discussions as an issue. FaviFake (talk) 15:31, 17 November 2025 (UTC)

You're missing the point. Each request must be followed by a level 3 subheading because ClueBot III takes a block of text to archive as being everything from a heading of a given level to a point immediately before the next heading of the same level, regardless of the level of any intervening headings. So if a level 3 subsection is eligible for archiving, and happens to be followed by a level 2 heading, ClueBot III will suck up not just the level 3 subheading, but also that level 2 heading and any text that occurs between that and the next level 3 subheading. This has been covered several times on this page.

Chronological ordering is a nice-to-have, it's not essential. We order them chronologically so that people picking something to close will look at the older ones first. We ask people to place new requests above the line simply so that they don't put them above the next level 2 heading.

All these rules and instructions may seem petty, but they've been built up from years of experience observing problems as they occur, working out why something failed, and trying to devise some method that will prevent the issue from re-occurring. The present system has been both stable and reliable for some time now, so I don't see any reason to alter it. --Redrose64 🌹 (talk) 23:16, 17 November 2025 (UTC)

Yes! Sorry. I meant to suggest to still place the invisible character inside a h3 header like we do now, but I've not noticed my request was worded terribly.

So it sounds like these headers will remain as-is and the bot would also break if the instructions weren't displayed in a hidden comment. This situation sucks!

I had made a couple of other minor changes, like moving the archiving notice inside the archive box, and rewording the instructions for clarity. I suppose you're not against those if the instructions remain inside a hidden comment and the headers remain unchanged? FaviFake (talk) 05:19, 18 November 2025 (UTC)