Update the closing steps following the merge of PAM into AfD

Introduction

Details

Now that PAM and AFD have been merged, there are two distinct cases. Note that in both cases, `Source page` is the article that was nominated and `Target page` is the page inputted in the "to:" field of XFDcloser (the field appears only for redirect and merge closures and it is required) during the closure. Note that these are just the additional steps. The other steps that are already being performed by XFDcloser when a discussion is closed as "merge", "redirect", etc. remain unchanged.

Note that in these steps I used the "What links here" as a way to see which articles or drafts might be tagged, but there might be more efficient ways to do this, for example checking every wikilink on the discussion.

When closing an AfD as "merge"
When closing as merge, all related pages need to be updated by XFDcloser to fix or add the tags, thus adding the articles to the backlog. Note that, since the Twinkle patch, the {{merge from}}[/-] tags are automatically added to both pages if the discussion is created using Twinkle. After closing as merge, the tag on the Target page and any other pages in the (Article) or Draft namespaces which have been tagged during the discussion should therefore be updated by XFDcloser. Its format is:
```
 {{Being merged from|Source article|discussion=NominationName|date=Date of the closure}}
```
Note that more than 1 page can be tagged as being a proposed target for merging, so these other tags should be removed (unless the consensus is to merge an article into multiple pages, but this is rare and it can be done manually by the closer). For example, I added a tag as explained in this comment and, once the discussion was closed, it was removed in this diff. Note also that the Target page may itself be tagged for several unrelated discussions at once, for example if articles A, B, C, and D are all separately proposed to be merged into the same page X: closing any one of those discussions must never disturb the tags belonging to the other three.
When closing as anything but "merge"
When an AfD is closed as keep, delete, no consensus, redirect, or custom, no merge is taking place, so no tags need to be added anywhere, only removed. Unlike a merge closure, XFDcloser should simply remove any merge-related tags that were added to the articles during the discussion (including on the source page itself, unless the closure is redirect).

Algorithm

AFD - Changes to "Merge" outcome

When closing as merge, XFDcloser should also do the following:

AFD merge: add "soft" and "selectively" check boxes #138 Add a "Soft" checkbox for merge closures, similar to the existing "Soft" checkbox for the delete and redirect options. It should simply link to WP:SOFTMERGE instead of WP:SOFTDELETE, and the wording of the closure should be updated based on the wording of the WP:SOFTMERGE paragraph.
AFD merge: add "soft" and "selectively" check boxes #138 Add a "Selectively" checkbox for merge closures, which would simply change the bolded result in the closure / template parameters / edit summaries / etc from merge to merge selectively, as AfDs are often closed as selective merges (that is, merge only the most relevant and well-sourced paragraphs and discard the rest)
Add a "Reverse merge" checkbox for merge closures. A WP:REVERSE merge closure happens when there's consensus to merge the articles, but the nominated page is actually the target article and not the source article (i.e., instead of merging the nominated article into some other article, we merge some other article(s) into the nominated article). When the "Reverse merge" checkbox is selected, the "To:" field shown to the closer is now pre-filled with the name of the nominated article and cannot be modified by the closer (it's greyed out). In addition, the closer will be shown a new field right below the "To:" field, called "From:", which they are required to fill. This is because we already know that the new target is the original nominated article, but the closer needs to tell us the new source page (which could be the Target page originally proposed by the nominator or a different page entirely). Like the "Selectively" checkbox above, the bolded result / parameters / etc now say '''reverse merge''' from [[New source]] instead of '''merge''' to [[Target]] , but in this case XFDcloser also needs to place the templates differently! For example, if a discussion is closed as reverse merge from New source article, the {{being merged from}} template should be placed on the original Nominated article and {{Afd-merge to}} should be placed on New source article: they're simply swapped. Some example diffs of correct template placement: nominated article, nominated article's talk page, new source article, and discussion subpage.
Tweak wording of closure: For merge closures, the closure statement above the discussion should be updated to use the word "into" rather than "to" (as in "The result was '''merge''' into [[Target]] because ..."), to match the wording used on all merge templates and merge pages. A page is merged into another, not really to another. This change should also be applied to all other XfD venue closures and their edit summaries/parameters/etc, since the word "merge" refers to the same concept. (Take for example the wording of {{Merge from TfD}} or {{Merge from MfD}}.) (Since we're rewriting a lot of the code, I figured we might as well fix some other smaller things.)
Nice error if the nominated page is already a redirect when applying … #150 Gracefully handle the placement of the merge templates if the source page or its talk page are redirects. This tries to prevent things like example on Source page and example on Talk:Source page from happening. Before placing {{Afd-merge to}} on the Source page and {{Old AfD multi}} on Talk:Source page, check whether the Source page and/or Talk:Source page are already redirects.
- If the Source page or its talk page is not a redirect→ keep placing the {{Afd-merge to}} or {{Old AfD multi}} tags as usual.
- If the Source page is now a redirect, check if there is a {{R from merge}} template or one of its redirects:
  - If there is → Don't tag the page, and show this error to the closer: "Nominated page X is currently a redirect tagged with {{R from merge}}. Has the article already been merged?"
  - If there isn't → Is there a {{R from move}} template or one of its redirects?
    - Yes:
      - Follow the redirect and tag the destination of the redirect with {{Afd-merge to}}. For example, if Source page redirects to Sauce page and it is tagged with {{R from move}}, then don't edit Source page and place {{Afd-merge to}} on Sauce page instead.
      - Show this to the closer: "Nominated page X is currently a redirect tagged with {{R from move}}, so the article has likely been renamed during the discussion. The template has been placed at the new title."
    - No:
      - Tag the article anyway, even if it breaks the redirect (like this). (Since the redirect was not categorised, we need a human to review what happened. Ideally, someone will arrive from the backlog, they will wonder "Who put a tag on a redirect?!", they will read the discussion, and they will make the correct decision to remove the tag or to move it to the correct article. And even if they wrongly remove it, the destination article will still be tagged with {{Being merged from}} to function as a backup tag to keep the merge in the backlog.)
      - Show this to the closer: "Nominated article X has been tagged, but it is currently a redirect." This is a third safeguard: if the closer is intrigued, they might want to check what happened and move the tag themselves.
- If the Source page's talk page is a redirect, perform this check: is there a {{R from move}} template or one of its redirects on the Source page we already checked in the previous step?
  - Yes:
    - Follow the redirect and tag the destination of the redirect. For example, if Talk:Source page redirects to Talk:Sauce page and Source page was tagged with {{R from move}}, then place the tag on Talk:Sauce page
    - Show this to the closer: "The [[Talk:X|talk page of the nominated article]] is currently a redirect. The template has been placed at the talk page of the renamed article." (We previously told the closer that the article was moved during the discussion, so there's no need to repeat it a second time.)
  - No:
    - Don't add the talk page tag. (Since we're not absolutely sure if the article it depends on was moved, there's no need to risk placing a template on the wrong page. The talk page tag {{Old XfD multi}} isn't tracked, and XFDcloser already tags the destination article's talk page for posterity.)
    - Show this to the closer: "The [[Talk:X|talk page of the nominated article]] is currently a redirect, so the {{Old XfD multi}} template has not been placed.
If and only if the discussion was closed as merge, place {{Being merged from|Source article|discussion=NominationName|date=Date of the closure}} always at the top of the Target page, below hatnotes. Otherwise, don't add anything. (Placing it at the top of a section rather than always at the top of the article is not worth the extra effort.)

AFD - Changes to "Merge" and "Redirect" outcomes

Only when closing as merge or_redirect_, XFDcloser should also do the following:

Add target to Merge and redirect closes #152 For merge and redirect closures, add the name of the Target page in the result in all the closures / template parameters / edit summaries / etc. For example, this edit summary ("Closed as redirect") should be changed to say "Closed as redirect to Mosha Gaolaolwe", and in this edit the parameter should be changed from |result='''redirect''' to |result='''redirect''' to [[Mosha Gaolaolwe]]. For merge closures, the most correct and common wording is actually "merge into" and not "merge to", so the updated edit summaries and parameters for merge closures should say "Closed as merge into" and |result='''merge''' into .... (Notice how only the actual result is bolded and not the name of the target; this is intentional to prevent excess boldface formatting.)
Now that merge closures are much more common, make "Merge" the third option on the list rather than the fourth (i.e., swap the placement of the "Redirect" and "Merge" buttons):

AFD - Changes to ALL outcomes

Regardless of how the discussion was closed, XFDcloser should always also do the following:

Cleanup merge templates in target article v3 #157 Clean up merge-related templates on the pages affected by this discussion:
1. Build the list of pages to check:
  - If the discussion was closed as merge or redirect, add the Target page to the list, unless it is currently a redirect or it doesn't exist, in which case leave it out. (If it is a redirect, checking if it contains any merge templates is useless because it's just a redirect...)
  - If the discussion was closed as keep, no consensus, or custom, add Source page (the nominated article) to the list, unless it is currently a redirect or it doesn't exist.
  - For delete closures, there is no additional specific page to check.
  - In addition, add to the list every page in the (Article) or Draft namespaces in the "What links here" of the AfD discussion subpage, excluding the Source page and the Target page themselves. (These two are already covered by the rules above or deliberately skipped, as XFDcloser already updates the Source page correctly for merge and redirect closures, with edge cases handled separately by the checklist item #150 above "Gracefully handle the placement of ...")
2. Now that you have that list of pages, look at every instance of {{Merge}}, {{merge from}}, {{Merge to}}, {{Article for deletion/dated}}, {{being merged to}}, {{being merged}}, {{being merged from}}, {{Merge portions from}}, or one of their redirects, and remove every one where the Source page or the NominationName appear {{inside it}}. Leave every other one in place, even if it's one of these 8 templates and even if it contains the same Target page as this discussion. (This is because several unrelated AfD discussions can each propose the same Target page, and each such tag belongs to a different discussion.)
  - When removing {{Article for deletion/dated}} or one of its redirects, also remove the hidden comments around it.

Thanks! Sounds like this needs to come after wikimedia-gadgets/twinkle#2335, so I've added it to the checklist there, and we can circle back to this once that ticket is in good shape.

@NovemLinguae

@NovemLinguae It doesn't have to come before the Twinkle update, because the tags that would be automatically placed on the target articles by Twinkle are currently being placed manually by me and User:ScrubbedFalcon. Twinkle can be updated after XFDcloser, or vice versa; the order doesn't matter. They're both relatively urgent, but maybe Twinkle is slightly more annoying to fix manually so it'd be ok with it being done first.

@NovemLinguae

@NovemLinguae Heya, will this issue be worked on in the near future? I've been updating the tags manually for the last few months, but having to monitor and watch so many AfDs is becoming a bit tedious, especially now that more and more people are getting comfortable with creating merge nominations at the new venue. Thanks!

Sure. I'll try to get to this soon. I spent a good 1-2 weeks on the Twinkle patch, then travelled internationally for a week. This one will probably take 1-2 weeks as well (big patch).

Perfect, thanks so much for your work!

OK, I'm starting this.

I edited the ticket to add check boxes, collapse the intro, and some other minor stuff to make it a bit more programmer friendly.

Exploration of how XFDcloser currently works (before this patch):

quickClose only has "Quick Keep" and "Quick Delete". I wonder if it has custom code, or re-uses the "Keep" and "Delete" codepath.

The results (and their custom check boxes / text boxes) are...

"Delete" and "Reidrect" currently have "Soft" options
The closing admin has to type the merge "To" target. It isn't pre-populated.

Looks like all our code changes will need to be in the "Add merge templates, tag talk pages" code path. The "No automated actions" looks like a code path selected when the admin wants to do all steps manually except for publishing the closing message in the AFD. Probably useful for complex closes, such as consensus for multiple merge targets, or a multi-AFD (affecting multiple source pages).

We will surely need to add a bunch of steps to this final page. This final page seems quite similar to Twinkle's Morebits Status class. Not sure if the XFDcloser one is async or linear.

Current behavior is to close the AFD, add {{Afd-merge-from}} to the target article, replace the AFD template with {{Afd-merge to}} in the source article, and update {{Old AfD multi}} on the source article's talk page.

Let's start with the "soft" and "selectively" checkboxes. Those look easiest since they barely change the algorithm. They just change the wording of the close.

XFDcloser pre-fills the reason for soft deletes with https://en.wikipedia.org/wiki/Wikipedia:XFDcloser/Soft_deletion_rationale, which contains complicated code that can handle multiple pages specified via template parameters. Seems like a complicated way to do it, but to continue following the pattern, I'll probably need to create https://en.wikipedia.org/wiki/Wikipedia:XFDcloser/Soft_merge_rationale

I'm assuming it uses a template so that the reason can be edited by other users without having to update the script. I've created Wikipedia:XFDcloser/Soft merge rationale.

I also added another item to the checklist: "For merge and redirect closures, add the name of the Target page in the result in all the closures / template parameters / edit summaries / etc", to make it easier for editors to jump to the target articles directly from their watchlists and similar pages. For posterity, including it in the {{Old afd multi}} template also helps future readers of the talk page see the consensus without having to open the discussion page. This is also consistent with the rest of the PAM templates used in talk pages.

I'm guessing this wasn't done previously because all nominations were for deletion, so the fact that the outcome was different was relevant enough. But now that articles can be nominated for merging or redirection, it's helpful to show the target everywhere.

Update: Work on this is going to stop for awhile. I got distracted by some other stuff. Maybe I'll take another stab at this in the coming weeks or at Wikimania (end of July).

@FaviFake

@FaviFake Related to point "Cleanup merge templates in non-target pages that link to the AFD": Why are we looking for merge templates on talk pages? Shouldn't they only be used on articles? Trying to include this behaviour is causing annoying to fix race conditions from trying to edit the talk page twice for something that seems useless.

@Trialpearswiki

@Trialpearswiki Yeah, I added the instructions to check talk pages to make XFDcloser remove any eventual incorrectly-placed merge tags on the talk pages, but now that I think about it I don't think that's necessary! You can just avoid checking talk pages and only check the article and draft namespace. I think a better solution would be to make the template display an error when used on the talk page and add it to a maintenance category, so we can actually check what is going on and eventually move the merge proposal to AFD. But XFDcloser doesn't need to worry about that! (Thanks so much for your work on this issue; the diff of XFDcloser handling the most complex case is impressive!)

I just thought of this, but even in the new patch the script should keep also removing the <! -- comments around -- > the {{Article for deletion/dated}} template, such as in this example. The AfD/dated template is the only template that has the quirk of always being surrounded by hidden comments; if this is already handled well, ignore this! Just wanted to note this somewhere in case it wasn't obvious.

I just thought of this, but even in the new patch the script should keep also removing the <! -- comments around -- > the {{Article for deletion/dated}} template, such as in this example. The AfD/dated template is the only template that has the quirk of always being surrounded by hidden comments; if this is already handled well, ignore this! Just wanted to note this somewhere in case it wasn't obvious.

Thanks. Did this new requirement get edited into the top post? Did this get incorporated into Trialpear's patch?

@Trialpearswiki

Yes, and I don't know. @Trialpearswiki?

Thanks. Did this new requirement get edited into the top post? Did this get incorporated into Trialpear's patch?

The original patch did not remove the comments properly and I didn't notice since I was adding {{afd/dated}} myself when testing (not substing {{afd}}). I have a new version locally which does handle it but also handles some of the other remove merge templates bullets. Problem is that there's way too much duplication of code and I probably have to refactor a lot before being ready to bring it to a pull request.

@FaviFake

@FaviFake 151b and 151c mention removing comments around "{{Article for deletion/dated}}" but don't actually call for removing "{{Article for deletion/dated}}". Can you please edit the post to clarify this?

Thanks for working on this! I must've accidentally added the "hidden comment" caveat to b and c last week. I've removed them and now it seems to make sense after re-reading it. Please do let me know if you have any other questions!

@NovemLinguae

@NovemLinguae I've been thinking about how XFDcloser detects nominated pages for AfD, and I think there's a gap worth flagging, using Wikipedia:Articles for deletion/Ishbak as a concrete example. The nomination is a merge proposal, originally opened on the talk page and moved, but a similar thing could happen even if the editor uses Twinkle but doesn't follow the instructions at WP:BUNDLE correctly. In short, the rationale proposes merging six articles (Zimran, Jokshan, Medan, Midian, Ishbak, and Shuah) into one, but only Ishbak is wrapped in its own {{la|...}} template. The other five are mentioned only as ordinary wikilinks within the nominator's paragraph.

If I understand XFDcloser's flow correctly, anything not given its own {{la}}-style line would never be recognised as nominated, no matter how clearly it's named in the rationale, right? In a case like this, does the script detect just Ishbak? After the "Cleanup merge templates in non-target pages that link to the AFD" checklist item will be implemented, the script would remove the AfD tag removed from all of them except Ishbak, which would be tagged with {{Afd-merge to}}

Given that proposed merges are now routed through AfD rather than informal talk pages, this pattern (one formally tagged page plus several more named only in prose) may come up more often than it used to, and closers using the tool might not realise those extra pages were skipped by the script. So:

Would it be worth adding some way for XFDcloser to recognise the other named articles too, at least when a discussion is explicitly framed as "merge these N articles"?
Or, better, should Twinkle be updated to allow editors to nominate more than two articles when creating the merge discussion? The current procedure is to first nominate the first article using Twinkle, and then follow WP:BUNDLE which says to copy and paste the {{AfD/dated}} tag to the additional pages and then list them at the discussion using {{la|...}} for each. But I think the risk of user error would be much lower if we allowed editors to click a button or make a list when creating the nomination using Twinkle's XFD module, for example "Nominate another article for merging into the target", so that these can all be automatically tagged and wrapped with {{la|...}} at the newly-created AfD discussion.

This implementation nightmare never ends! I think tomorrow I'll create another proposal on Twinkle's GitHub, since this doesn't really concern XFDcloser.

This edge case is pretty rare, right? Let's tackle it later. We can file a separate bug ticket for it after we get this ticket written, merged, and deployed.

Yes, yes. First we finish the XFDcloser updates, then we can worry about this Twinkle addition. I just like to write these tickets in advance so that when someone sees them, they're already tied up in a bow and they can start to work on it immediately.

However, it is not extremely rare to see a nominator incorrectly propose a merge of two articles into a third article. But again, this is a Twinkle issue, I'll file the ticket there. Keep up the amazing work Novem!

In 151c, the spec wants us to find an existing template, inspect its parameters, and see if they are correct or not. This is complicated to code. Any objections to simplifying the algorithm to the following?

3. If there's at least 1 of these 5 templates (after having removed any earlier ones):
    * Delete the existing template
    * Replace it with `{{Being merged from|Source article|afd=NominationName|date=Date of the closure}}`, at the exact same location as the old template

As you can probably see, I am taking my perfectionist hat off and putting my industrious hat on. Goal is to get you something that might not be perfect but helps a lot. We can tackle any edge cases in follow up tickets and patches, if they are worth dev time. (As you can tell, dev time is kind of valuable and hard to come by.)

@NovemLinguae

@NovemLinguae I looked into this and you were right, the spec is too complicated, but for a different reason! I found a real bug: part of the check for whether a tag belonged to a discussion relied on the tag naming the target page. But the target is one of the values that could be shared across unrelated discussions, because several articles can each be separately proposed to merge into the same page at once. That check could delete or overwrite a different discussion's legitimate tag that should've stayed there. Plus, sometimes my spec straight-up removed the {{Merge to}}–esque templates without even checking if they were related to the discussion. (Counterintuitively, the target page can also be nominated for merging into another article, and this happens more frequently than one would think.) My four slightly different versions were actually terrible!

I've spent the last 2 hours trying to come up with a perfect and simple solution, and I think I finally did it. The matching now relies only on the source page or the nomination name, both unique to a single discussion, and all 8 templates are checked in at the same time in the same way. All four checklist items (target cleanup, non-target cleanup, and their two non-merge equivalents) were merged into one, which is now under "Changes to ALL outcomes". The only substantial outcome-specific behaviour left is a single extra step that adds {{Being merged from}} to the target only when the closure is a merge. This should be less to build, not more. Please let me know if this is also easier to code!

I already coded up most of the old algorithm in #153. No biggie though. I'll figure it out.

Oh I'm so sorry! It seems you mostly coded the part about removing all templates except the bottom one; I guess you could keep that behaviour (if removing two or more of the 8 templates, place {{being merged ... in the same spot as the last one you removed), but now the spec is more complex and trying to savage it probably isn't worth it, it's just a really small QoL change. It's unfortunate that our time zones are so different, you always start working while I'm getting ready to sleep! But I guarantee you the new changes are rock solid, I must've re-read them countless times today.

Wikimania is this week. This ticket is on my list of things to work on there.

In addition, add to the list every page in the (Article) or Draft namespaces in the "What links here" of the AfD discussion subpage, excluding the Source page and the Target page themselves. (These two are already covered by the rules above or deliberately skipped, as XFDcloser already updates the Source page correctly for merge and redirect closures, with edge cases handled separately by the checklist item #150 above "Gracefully handle the placement of ...")

Is this for AFD only?

Hi Novem, thanks again for working on this ticket! I'm not exactly sure what you mean, but in general every change, including this one, is limited to closures of AFD discussions unless otherwise stated. (For example, the point "Tweak wording of closure" exceptionally applies to all XFD venues).

If you're specifically wondering why we also check pages in the draft namespace, it's because articles can be nominated for merging into a draft but drafts currently cannot be nominated for merging anywhere. If there is consensus at enwiki to allow merge nominations at MFD, then we would have to add a similar step to the MFD closure process. But this step only applies to AFD as of right now.

Navigation Menu

Update the closing steps following the merge of PAM into AfD #135

Introduction

Algorithm

AFD - Changes to "Merge" outcome

AFD - Changes to "Merge" and "Redirect" outcomes

AFD - Changes to ALL outcomes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Update the closing steps following the merge of PAM into AfD #135

Description

Introduction

Algorithm

AFD - Changes to "Merge" outcome

AFD - Changes to "Merge" and "Redirect" outcomes

AFD - Changes to ALL outcomes

Activity

NovemLinguae commented on Apr 12, 2026

FaviFake commented on Apr 12, 2026

FaviFake commented on May 7, 2026

NovemLinguae commented on May 7, 2026

FaviFake commented on May 8, 2026

NovemLinguae commented on May 14, 2026

NovemLinguae commented on May 14, 2026

NovemLinguae commented on May 16, 2026

FaviFake commented on May 16, 2026

NovemLinguae commented on May 30, 2026

Trialpearswiki commented on Jun 18, 2026

FaviFake commented on Jun 19, 2026

FaviFake commented on Jun 19, 2026

NovemLinguae commented on Jun 21, 2026

FaviFake commented on Jun 21, 2026

Trialpearswiki commented on Jun 21, 2026

NovemLinguae commented on Jul 2, 2026

FaviFake commented on Jul 2, 2026

FaviFake commented on Jul 2, 2026

NovemLinguae commented on Jul 2, 2026

FaviFake commented on Jul 2, 2026

NovemLinguae commented on Jul 2, 2026

FaviFake commented on Jul 3, 2026

NovemLinguae commented on Jul 3, 2026

FaviFake commented on Jul 3, 2026

NovemLinguae commented on Jul 19, 2026

NovemLinguae commented on Jul 23, 2026

FaviFake commented on Jul 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions