Yes. Proposed merge discussions often end up languishing, I think in part because there's no good system for sorting proposed mergers by topic area and very few editors watch the process compared to AfD. Additionally, it seems that most merge discussions involve notability issues. voorts (talk/contributions) 18:24, 19 January 2026 (UTC)[reply]
Some more comments based on the discussion so far: You're fixing up a house that has mold in the basement and improper insulation in the living quarters. Choosing to ameliorate the mold problem first is not akin to choosing never to put in new insulation. Both are problems and both can and should be fixed. Analogously, there are a few apparent problems with the way we handle merge discussions: the lack of participation in merge discussions, discussions remaining open for months, and a lack of editors willing to implement merges. I've not seen anyone opposed to this proposal seriously deny that the first two are actually problems or propose any solutions for them, while various editors have pointed out how the proposal would obviously solve it. As for the third problem, my educated guess is that when editors know their discussion will be closed in a reasonable timeframe, rather than left to die on the vine, they will be more likely to effectuate the merges they propose. Even if that's not the case, nothing in this proposal is preventing anyone from starting to clear the backlog or finding a more sustainable way to ensure that merges actually happen. As one step towards that, I've proposed a merge-a-thon at PAM that we can hopefully get going. Other suggestions to fix that problem are welcome, but we don't need to solve that problem before we solve the others. voorts (talk/contributions) 01:55, 21 January 2026 (UTC)[reply]
Yes. Merge discussions lack a strong, centralized administrative task force and can tend to languish. Also, many AfDs close with consensus to merge, which is a confusing distinction to new editors. AfD should also be correspondingly renamed "Articles for Discussion" to match with other XfDs. Cremastra (talk·contribs) 18:28, 19 January 2026 (UTC)[reply]
No. Combining merge discussions with AfD will not solve the problem with merge discussions, because even when a merge discussion is the consensus at an AfD, they still languish and take weeks or even months to enact. Merge discussions languish not because of the centralized discusssion but because they require large amounts of content work which are harder to do than simply voting, and require people who are familiar with the source material. Merge discussions are often not a notability/sourcing issue and combining it with AfD will make many mergers that would make sense as a content decision instead be voted against based on notability, or vice versa. What would happen is we would have these merge AfDs, then no one would enact them for the same exact reason no one enacts them now when the conclusion of an AfD is merge. PARAKANYAA (talk) 18:40, 19 January 2026 (UTC)[reply]
Yes I have seen many mergers get only one or two replies and then last for months before finally being closed. AfD would encourage higher participation and give a quick binding result. Traumnovelle (talk) 18:59, 19 January 2026 (UTC)[reply]
The problem imo isn't that merge closures aren't binding (they are, as are AfD closures) or that they aren't closed quickly. It's mostly that there are not enough editors are willing to actually perform the merger. How would this change fix this problem? FaviFake (talk) 19:42, 19 January 2026 (UTC)[reply]
There are discussions at WP:PAM going back to June 2025 that haven't been closed. This would fix the problem by getting discussions closed quicker so that editors can proceed with the merge and not forget about it for several months. voorts (talk/contributions) 19:44, 19 January 2026 (UTC)[reply]
To you both: that doesn't solve the issue! If there are tot number of people willing to do tot number of merges a week, closing discussions quicker wouldn't increase the number of these editors, or their willingness to merge pages. Anyone can already close most merge discussions, it's just that they don't want to perform the merge and so they don't even close it. FaviFake (talk) 19:50, 19 January 2026 (UTC)[reply]
it's just that they don't want to perform the merge and so they don't even close it. The closer of a discussion is not required to implement the close. That's not the rule for any other sort of content discussion. voorts (talk/contributions) 19:52, 19 January 2026 (UTC)[reply]
Sure, but that's not the point. There will still be the same number of editors willing to carry out merges even if discussions are closed incredibly quickly. FaviFake (talk) 19:55, 19 January 2026 (UTC)[reply]
Yes per voorts, torn between the proposal and merging merges and splits into a WP:RMC-style process, merges barely function atm (if that) thanks to a couple dedicated editors, and they usually get little participation and last for many months if not years. Would also support renaming AfD "Articles for Discussion", but I guess that can be discussed later. Agree w those in Discussion that WP:PAGEDECIDE should be central to how we decide on standalone articles. Informal merge discussions should still be allowed though, but that would only make a local consensus Kowal2701 (talk) 19:10, 19 January 2026 (UTC)[reply]
No Largely, per Parakanyaa. It's true that there is a problem that needs solving, but merging PAM into AfD is not going to solve it. What PAM needs is more structure, greater visibility and more timely closures. I suspect that a much better course of action would be model it after WP:RM and either merging article splitting discussions into the same new structure or doing the same for that independently. Thryduulf (talk) 19:11, 19 January 2026 (UTC)[reply]
Yes Merge discussions can die out and attract limited participation, so this could absolutely help. However, be cautious that TAs can’t make merge nominations if this comes to pass, so I think we need to make a daily log and let nominations go from there. ~2026-41476-9 (talk) 19:12, 19 January 2026 (UTC)[reply]
Right but that process is complicated and leads to some AFDs never being made. If merges and AFD are to be in one venue, a more efficient solution ought to be established. One possible one I can think of is drafting a deletion discussion and pushing it through WP:AFC. ~2026-41476-9 (talk) 19:26, 19 January 2026 (UTC)[reply]
It would immediately make the nomination process much harder to do without scripts. That's a relevant argument regarding the question presented here, but changing the process of how TAs create AfDs is not within the scope of this RfC, which is why I suggested that this TA raise the issue at WT:AFD. In any event, it seems the process of TAs requesting AFDs be created at WT:AFD works fairly well, so I'm not sure any change is necessary. voorts (talk/contributions) 20:02, 19 January 2026 (UTC)[reply]
Aren't you advocating for a change though? Or do you think we should allow TAs to create new AfD, only when they involve mergers? I've seen many IPs and TAs propose useful mergers. FaviFake (talk) 20:06, 19 January 2026 (UTC)[reply]
The proposed change of this RfC is to merge PAM with AfD. How TAs create merge discussions is one of many things that implementation of this proposal would effect. I am not opining on whether TAs should or should not be allowed to create AfD subpages because that question is not within the scope of the question presented by this RfC.TAs may already request that new AfDs be created by requesting assistance at WT:AFD. If this proposal is implemented, TAs could request an AfD with a proposed outcome of merge at WT:AFD just as they do for deletion now. If editors don't like that process, anyone should feel free to propose a change right now at WT:AFD. voorts (talk/contributions) 20:14, 19 January 2026 (UTC)[reply]
Yes: Merge discussions do not have a refined system to monitor or manage them, and are often overlooked with no formal process to keep track of them. Many tend to notify selective WikiProjects that are either inactive of do not elicit responses, so providing direct access and attention to the wider community would work wonders in the long run. I also agree that AfD should be renamed "Articles for Discussion", because merging ends up usually being a sufficient alternative to deletion. There should also probably be a requirement on the proposer to enact the merge, based on the consensus, should there be one, to ensure it is actually fulfilled. — Trailblazer101🔥 (discuss · contribs)19:18, 19 January 2026 (UTC)[reply]
Yes as its officially already been established in 2021that if an article is blanked and redirected (WP:BLAR), then AfD is the permitted venue alongside the articles talk page. Merge discussions often take months to resolve itself, but AfDs generally get closed/relisted after 7 days and generally do not last longer than a month. Its also because someone will notify the relevant Wikiprojects when an AFD is started, but not a page merge. JuniperChill (talk) 19:33, 19 January 2026 (UTC)[reply]
No/Oppose - I have long thought that AFD should be decentralized out of project space and should take place on an article's talk page. This better alerts those who might be interested in the discussion, and makes updating/editing/adding references all the more easier. And those watching the discussion will also automatically will be watching the page as well. This all would provide more opportunities for engagement, and more opportunities for encyclopedia development, while reducing the optics of AFD being an example of "Wikipedia the game", or "Wikipedia the battleground". While having central project-space pages for discussing project features like templates, redirects, and categories makes sense, article talk pages tend to be quite different places. Thanks to the various infrastructure supported by bots, this should be a fairly simple change. It's done for WP:RM, and WP:RFC, there's no reason AFD should not be done the same way. All of this - and more - is why I oppose adding more to AFD. - jc3719:36, 19 January 2026 (UTC)[reply]
What? No! How's that going to improve anything? The only thing that can come out of merging WP:PAM and WP:AFD is that AfDs will remain open (or closed and left in the backlog) for months because nobody will commit to merging the pages.The status quo for merge proposals is ridiculously bad, inefficient, complicated, and not visible enough, but this seems like a terrible way to try to fix it. FaviFake (talk) 19:36, 19 January 2026 (UTC)[reply]
Yes because some admins close AfD discussions as merge when it's an ATD that's presented, even when other editors specifically object that there's nothing in the article to merge. Those cases are easiest to remove from the backlog because they can just be redirected without further action. The merge outcome doesn't prevent editorial judgment from being used to merge appropriately. voorts (talk/contributions) 21:35, 20 January 2026 (UTC)[reply]
Yes One process, one place makes it easier for all users, especially new users. I argued for this in the past and still believe it should happen. As a lot if AFDs end up as merges anyway, it makes sense.Davidstewartharvey (talk) 20:26, 19 January 2026 (UTC)[reply]
Yes, and change it to "Articles for discussion" in line with "redirects for discussion" and "categories for discussion" etc. This emphasizes that there are multiple potential outcomes aside from delete/not delete. BOZ (talk) 20:37, 19 January 2026 (UTC)[reply]
No In practice, editors seeking a merge can still attempt to achieve it via AfD, but they need to take the risk, which is absent in merge discussions, that the content may be deleted altogether. The proposal, if implemented, will just limit their options. It is also unclear how it should be implemented, because so far it looks like the proposal is to get rid of merge discussions without substantively changing AfD ones. In this case, I would say that it is better to attempt a reform of WP:PM instead of its outright abolition. Even further, in my opinion, a merge outcome is inappropriate for AfD, as the discussion usually doesn't involve editors watching the proposed merge target, who may oppose dumping additional content into the respective article. Kelob2678 (talk) 20:42, 19 January 2026 (UTC)[reply]
Regarding your last point, it would be easy enough to require notification to the talk page of the merge target and update the AfD scripts to automatically do that. voorts (talk/contributions) 20:52, 19 January 2026 (UTC)[reply]
Absolutely and it's about time We've long gone past boolean keep/delete, where now a sizeable number of discussions end up with a merge or redirect outcome. Putting all this thinking together in one place is really moving beyond the inclusionism/deletionism wars of the 2010s, and really asking one complex question in one place: Should this content be on Wikipedia, and, if so, how best to present it? Some deletion decisions are classic yes/no, but the ones that attract the most discussion are where there is a disconnect between how things are now, and how they ought to be. Jclemens (talk) 21:25, 19 January 2026 (UTC)[reply]
Yes, and I agree with BOZ's suggestion of changing the name of the process to "Articles for Discussion," as there are many times the nominator proposes something other than deletion, and many more times that the result is something other than the deletion that was originally requested. — Jkudlick ⚓ (talk)21:39, 19 January 2026 (UTC)[reply]
My default position is no/oppose. But: What would that look like? The system in question for merges is:
Start a merge discussion on the article's talk page (a couple of clicks in WP:TW, plus type the name of the other article and a rationale).
The discussion proceeds on the Talk: page, exactly as if Step #2 didn't exist.
What I don't understand from this proposal is whether it means what it links – Should the Wikipedia:Proposed article mergers [which it calls "the article merge process"] be merged into Wikipedia:Articles for deletion? – or if it means "Should the [actual] article merge process [which is WP:MERGE, not WP:PAM ] be merged into Wikipedia:Articles for deletion?" If the first, and nothing else changes, then I'd suggest chatting up the WP:PAM regulars and see what they want. If the second, then I oppose it because I don't think that mashing the merge system into AFD is as good as what we do now, in terms of producing the correct result.
I don't think that merge proposals should be run on a default seven-day timer, or even seven days plus a relisting or two. A merge proposal is not an emergency. It's okay if it takes a few months (just like any other discussion about an article is okay if it takes a few months). Speed is not important for merge proposals.
I also don't think that AFD, with its focus on sourcing and notability, is the right mental approach to merge proposals. Merging sometimes depends on sourcing, but it often depends on how editors want to write about the subject(s): Do we want to fold the author and the book together in one article, or write about them separately? Do we want to write about the original company and its successor together or separately? Will the article on widgets become too long if we merge in a few stubs about widget manufacturers? This is not the kind of thinking that happens at AFD (which is: First article in list: Search for sources, found some, vote keep. Second article in list: Search for sources, didn't find any, vote delete. Third article in list: Search for sources...). Merging is a different type of thinking, so it should be a separate process. WhatamIdoing (talk) 21:40, 19 January 2026 (UTC)[reply]
It's okay if it takes a few months (just like any other discussion about an article is okay if it takes a few months). Merge proposals only take a few months because very few editors comment in merge discussions. voorts (talk/contributions) 21:45, 19 January 2026 (UTC)[reply]
Merge proposals only take a few months because very few editors comment in merge discussions Tbh, that's not what I'm seeing at all. When I land on an open merge discussion, 90% or 95% of the time there's obvious consensus to merge, even if from a few editors, which is more than enough. The problem, which I keep repeating but which you haven't really addressed here, is that we need more editors carrying out mergers, not discussing them. Sometimes most of the discussion is about who's gonna do it rather than if it should be done. FaviFake (talk) 22:14, 19 January 2026 (UTC)[reply]
I think GLL's data shows that, given the volume of merge outcomes at AfD, the fact that the backlog isn't bigger than it is is an indication that merges regularly get done. voorts (talk/contributions) 23:44, 19 January 2026 (UTC)[reply]
The proposal is to make merging discussions occur at AfD, to answer your question. I thought that was pretty clear from the context of this discussion, notwithstanding the page linked in the RfC question. voorts (talk/contributions) 21:59, 19 January 2026 (UTC)[reply]
You're not supposed to open an AfD discussion if your proposal is to merge. Merging is an outcome that can occur at AfD right now, not the purpose of AfD. I think this proposal is fairly clear: it would mean that merge discussions happen at AfD instead of via proposed merge discussions. voorts (talk/contributions) 21:52, 19 January 2026 (UTC)[reply]
I don't think this is that proposal, as requested moves is an entirely different beast that will remain untouched. You do have a point that we might have to figure out a new name though. Aaron Liu (talk) 00:28, 20 January 2026 (UTC)[reply]
AfD should have fewer merges, rather than more. There are certain editors that believe that administrators should avoid closing AfD discussions as merge as much as possible (and I tend to agree). Katzrockso (talk) 22:08, 19 January 2026 (UTC)[reply]
Yes, absolutely. It is one of these things I have agreed with for a long time but would not propose myself. Merge discussions almost never get traction and therefore almost never get closed, and while this is for a variety of reasons, this is an issue for anything that does not require a bold merge (arguably most obvious mergers do anyways). While I agree that the speed of execution of a merger is not necessarily going to be improved, a merge outcome would not need to be speedily implemented once established and the article clearly marked as such. Aligning the name of AfD with the other XfDs into Articles for Discussion would also be an improvement both in terms of accuracy regarding what the process actually is, and taking some of the negative charge away from it. Putting complex merge discussions within it would help cementing the idea that the goal is not to either get rid of vs save an article, but to determine what is the best course of action for the current and potential contents of the article. Choucas0 🐦⬛22:03, 19 January 2026 (UTC)[reply]
As a comment, I am a bit surprised by how many opposes come down to how this proposal is not going to magically fix all problems related to mergers, deletion, and participation all at once, or even just that relatively minor procedural changes that are really not out of reach would need to be implemented. That, and a quite visible divergence between what people perceive or want the merging process to be, and what it actually is like in practice at the moment. Dissatisfaction with the current AfD process should not preclude improving it, especially when not directly related to mergers, because it is clear that there is much more to gain than to lose when considering improvements that we can build on further. A no consensus outcome and consequently not enacting any change, even minor, would be a shame. Choucas0 🐦⬛15:40, 21 January 2026 (UTC)[reply]
There are problems with the article merge process as it stands, and there are problems with AfD as it stands. However, for the reasons that have been explained much better by others than I can, merging the two is not going to fix the problems with either. The way to fix mergers is to merge them with splits and change the process to work similarly to how RM does. I don't know how to fix AfD, but I do know that merging a broken process into it isn't the answer. Thryduulf (talk) 15:43, 21 January 2026 (UTC)[reply]
Yes, as somebody who believes that, when in doubt, our PAGs should be descriptivist rather than prescriptivist. As any AfD regular knows, this is where merges already happen, for a variety of reasons - these are some very rough estimates, but as of writing, there are about 240 articles in Category:Articles proposed for merging from January 2026. Given that both the proposed merge target and the article being debated should be listed in said category, that's about 120 articles being diccussed this month. (Merge discussions move slowly, so I'm assuming a few have already been closed, but not that many). Conversely, about 100 AfDs have already ended in a merge result from January alone.[1] Over 300 have ended in redirect, which is an AfD option that explicitly designed to allow for selective merges, should somebody find anything they're particularly fond of in the article history, and implies that the editors discussed the merge at the AfD[2]. (I can't think of a clean way to get the numbers, as my brain is currently being wimpy and tired from some fun medication side effect interactions), but we all know that, despite my undercount in number of January PAM discussions, there's also going to be a lot of AfDs that ended in delete or keep where a merge was discussed and decided against/no consensused. But putting both those aside for a minute, 120 merge discussions at PAM versus. over 400 merge/de facto merge discussions at AfD. At a certain point, it doesn't matter whether or not you or I think AfD is the best place for these discussions, or you even want merge discussions to take place there - they already and overwhelmingly take place there. (You just can't say that's what you'd like to happen, as a nom, because if you say in your nom that you think the best outcome would be a merge or draftification, then anybody can technically come along and speedily close the nom under WP:SK1. I also think we should remove all stupid insider baseball rules, and this is very obviously one) GreenLipstickLesbian💌🧸23:02, 19 January 2026 (UTC)[reply]
What if we enforced SK1 on all unambiguous merge proposals that are made at AFD?
I don't care if they're intended by the nom or not; when even one participant suggests a merge, it becomes an intended merge discussion.
I can see why enforcing SK1 at AfD for unambiguous merge discussions seems an attractive way of redirecting merge discussions back to PAM - however, the actual humans involved already have a solution to this: make their noms ambiguous. I mean, I'm not the most skilled at writing, but even I could (if I wanted to) make a AfD merge nom that couldn't be closed as SK1. GreenLipstickLesbian💌🧸00:06, 20 January 2026 (UTC)[reply]
I don't think we can hold the nom responsible for participants who !vote to merge, when the nom is advocating for deletion. The nom has to make a choice of venue, and the choice of venue should be determined by the nom's goal (i.e., noms shouldn't use AFD to propose a merge, and they equally shouldn't use {{merge}} to propose deletion). But just because people (including me) respond to that deletion attempt by saying something other than "delete" doesn't mean that the deletion attempt becomes "an intended merge discussion" or "an intended keep discussion" or whatever. WhatamIdoing (talk) 02:56, 20 January 2026 (UTC)[reply]
I'm not arguing that I should hold the nom responsible; I'm arguing that when people show up to an AFD and suggest a merge, they would, typically, like the other participants to consider and debate (or, more likely) agree with said merge. hence they have intended it to become a merge discussion.
Think of my comment above this way: you, WAID, are our wonderful Wiki campus planner. You've put hours and hours into designing the buildings, how they connect to each other, and the oaths people should follow to get from building to building. Everything is optimized, you did surveys, you consulted landscapers, and the resulting paths are beautiful, efficient, and really quite wonderful!
Then you come back five years later and discover a desire path cutting right across one of the lawns.
What do you do?
For starters, you could put up large signs telling people to use the correct path (that's our AfD instructions). That doesn't work.
The next option is to tell the campus security guards to make people walk on the correct path; that cuts off a certain amount of the trespassers (especially the new and rule following), but most of the people just learn to cut across the lawn when the security guard isn't around, or is too far away to stop them.
You could even try making the intended path nicer, and send out surveys: but then everybody responds that no, they use their own path because it's shorter, more convinient, all their friends use this path too so they need to if they want to talk with them, and you can't do much about that!
You could continue that cycle: putting up higher fences to stop people from cutting (fine until they knock them down or climb over, or it snows and the fences get obscured), impose harsher fines, tell the guards to detain people who look as though they're so much as going to think about cutting across the lawn.
Or you could give in, give the new path a better surface to prevent ground erosion, give it some lighting so it's safer, and accept that, when somewhere between 50 and 80% of your people are already going down this unauthorized path, that this is their preferred route. And, for better or worse, AfD appears to be the preferred route for people wishing to merge articles. GreenLipstickLesbian💌🧸03:32, 20 January 2026 (UTC)[reply]
797 keeps where a merge was discussed + 72 speedy keeps (incl. bc on the first page, there are several which included merge discussions before getting SK1-ed or withdrawn)
891 deletes where a merge was discussed (going to be pretty disproportionately somebody mentioning "merge" in their before, but there's a few on the front page of results, at least, where somebody suggested a merge but other participants disagreed
That's about 6,500 merge discussions at AfD - which, since this has been a point of contention, I'm defining a "merge discussion" to be one where some people sit down in a formal venue, debate the merits of a merge, and decide for or against it.
Let's say, using WAID (high?) estimation below,[3] that there's 220 merge discussions a month - I'm not entirely sure that there are 2,640 PAM discussions a year, but let's just take it - and now compare 2,640 to 6,500.
Yes, approximately 2,640 of our annual 9,140 formal/de facto merge discussions took place, in large part, at AfD. Maybe that's because AfD is superior, maybe that's because AfD has better infrastructure, maybe it's because AfD/VFD hit critical mass when I was in kindergarten while PAM never did. GreenLipstickLesbian💌🧸02:07, 24 January 2026 (UTC)[reply]
Yes - Trailblazer makes a salient point that even if you notify a WikiProject of a merge discussion, a lot of topics just don't have a high level engagement versus the AfD listing process which seems to pull in a lot of editors outside of the regulars of a topic area. I also like "Articles for Discussion" because merge and/or draftify is often an AfD result, it feels less negative and we wouldn't have to change the acronym. It should probably be a suggested best practice rather than a requirement for the proposer to do the merge. Sariel Xilo (talk) 23:05, 19 January 2026 (UTC)[reply]
support merging. Both of these processes are asking editors the same question: "should this topic have a standalone article?" Thus it makes sense that they be addressed in the same forum. CapitalSasha ~ talk23:06, 19 January 2026 (UTC)[reply]
@CapitalSasha, I don't think I can agree. I think AFD is answering the question "Is this topic allowed to have a standalone article?" and MERGE is answering the question of "Even though this topic is allowed to have a standalone article, is that really how we want to handle it?" WhatamIdoing (talk) 23:40, 19 January 2026 (UTC)[reply]
Yes, and combining the processes would mean that in addition to asking the question "Is this topic allowed to have a standalone article?", editors would be allowed to ask the question "Even though this topic is allowed to have a standalone article, is that really how we want to handle it?" As other editors have noted above, merge is a common outcome at AfD. This idea that AfD editors don't know how to suggest merges when it's warranted is incorrect. voorts (talk/contributions) 23:43, 19 January 2026 (UTC)[reply]
I guess I don't see the distinction between "being allowed to have a standalone article" and "having a standalone article." I think of these processes as editorial processes, not governance processes, so to me ultimately it's about whether the topic ultimately ends up with its own article. CapitalSasha ~ talk00:24, 20 January 2026 (UTC)[reply]
Yes: This is supposed to solve the problem of the merge discussions themselves not receiving their due attention. The applicable rationales are similar enough (I'd say one-to-one, even) that these should be merged.Merges that have consensus staying in holding cells is a separate problem that this proposal would not exacerbate (or, at least, the merges that would be closed within 7 days under this process is preferable to just remaining under unclear consensus statuses) , and being in a holding cell does not stop the discussion from being closed (cc @FaviFake), which again is the only problem this tries to solve. Aaron Liu (talk) 00:21, 20 January 2026 (UTC)[reply]
Question: is the problem 1) that too many merge proposals are not being closed … or is the problem 2) that (once closed) the actual merging is not being implemented? Blueboar (talk) 00:24, 20 January 2026 (UTC)[reply]
I agree with Aaron, based on past experience with AFDs that closed as merge. Typically, the nom won't do the merge because that's not the outcome they wanted, and the other participants were just drive-by voters who wanted to give advice but not do the work. WhatamIdoing (talk) 02:59, 20 January 2026 (UTC)[reply]
This change in process would mean the nom gets to propose a merge at AfD, have editors actually participate in the discussion (contra the status quo), and have the discussion closed in a reasonable time frame (also contra the status quo). voorts (talk/contributions) 18:17, 20 January 2026 (UTC)[reply]
And you're ignoring that getting discussions closed more quickly and with more participants will increase the likelihood of the merge occuring, compared to the current system where people propose a merge in June 2025, move on to other things, and find the discussion still open in January 2026. voorts (talk/contributions) 20:04, 20 January 2026 (UTC)[reply]
But the other big problem of gaining consensus for these merges in the first place is resolved. We don't have to and often can't solve everything at once. Aaron Liu (talk) 00:09, 21 January 2026 (UTC)[reply]
Yes, the perceived binary nature of old AfD has always been overly artificial. It should go more forthrightly to, 'do we think in our editorial judgement, there should be separate page on this', same with merge. Consensus also works better with more options for agreement. The more eyes on 'what to do with this information' can only help the pedia be better. Alanscottwalker (talk) 01:04, 20 January 2026 (UTC)[reply]
No, because the resulting changes would not benefit the project as they place unnecessary barriers on merging articles. In the old system/status quo: You think an article should be merged. You post on the talk page. Two people agree with you that it's a good idea. You perform the merge within a couple of hours of requesting it. In the new system: You think an article should be merged. You must open an AfD to propose merging and said AfD discussion must stay open at least seven days or until consensus has been reached, whichever comes first. The reason this is a problem is that this will enact barriers to merging (opening a AfD) that are not justified. The barriers surrounding deletion (strict speedy deletion criteria, seven-day time periods, etc.) make sense, because deletion can only be performed by and reversed by admins, but placing similar barriers around merging is inappropriate, because anyone, even TAs, can merge a page into another as long as they can edit the pages involved, and a merge can easily be reversed by restoring old page histories. Merging is unlike deletion, which has somewhat strictly defined criteria (such as lack of notability), because the reasoning for a merge is scarcely more complicated than "I think these pages cover similar topics, so we should merge them." There is no such thing as Wikipedia:Speedy merging because anyone can merge if they feel it is appropriate. SuperPianoMan9167 (talk) 01:36, 20 January 2026 (UTC)[reply]
You think an article should be merged. You must open an AfD to propose merging and said AfD discussion must stay open at least seven days or until consensus has been reached, whichever comes first. This is incorrect. You don't even need to open a merge discussion in the status quo. You can just be bold and do the merge yourself. voorts (talk/contributions) 02:07, 20 January 2026 (UTC)[reply]
Also, none of this would preclude starting a talk page discussion with other editors or asking a Wikiproject if they think a merge is a good idea before you open an AfD. voorts (talk/contributions) 02:09, 20 January 2026 (UTC)[reply]
Making a bold merge does not preclude you from asking other editors to weigh in. There's no requirement to ask those questions using the proposed merge tags and WP:PAM, just like there would be no requirement to do so at AfD if the process changes. voorts (talk/contributions) 02:14, 20 January 2026 (UTC)[reply]
For example, you create an article, I review it at NPP, I think it ought to be merged, I drop you a note on your talk page, you respond and agree, and I merge it. No AfD involved. Another example: I find an article, think it's of marginal notability and intend to boldly merge it, ask someone at a relevant WikiProject for a sanity check, they agree, and I go ahead with the proposed merge. Again, no AfD involved. voorts (talk/contributions) 02:16, 20 January 2026 (UTC)[reply]
Under the current system, if someone disagreed with either of my bold merges, they'd have to revert and take it to PAM, where it might sit for months. Under this proposal, it would go to the combined AfD and hopefully be resolved much quicker (and with much more input from other editors). voorts (talk/contributions) 02:16, 20 January 2026 (UTC)[reply]
Nothing in the RfC question speaks to getting rid of bold merges. If I wanted to eliminate bold merging (which would be an odd thing to do), I would've asked that question. voorts (talk/contributions) 03:26, 20 January 2026 (UTC)[reply]
We have a discussion and reach a decision. This frequently happens in one week, though some stretch out longer.
Eventually, someone merges the articles (or at least removes the merge tags). This will still take many months.
Is your proposal to ban the current process and substitute the AFD route for 100% of discussed merges, or to keep the current process and only add AFD as a non-required, strictly optional supplement the current process? WhatamIdoing (talk) 19:37, 20 January 2026 (UTC)[reply]
The proposal is to move formal merge discussions into AfD. I'm not sure how else to say that and everybody else !voting in this discussion seems to understand that that's the proposal. voorts (talk/contributions) 19:56, 20 January 2026 (UTC)[reply]
Wait, now I'm confused. Will PAM continue to be an option or will editors be forbidden from reaching a consensus to merge unless they do it at AfD? Honestly idk which is worse.A merge proposal only becomes formal once the tags have been added to both pages, even if the discussion was started a long time prior, which starts the usual 7-day countdown. Will discussions not started at AfD be eligible to be moved to AfD during the discussion? FaviFake (talk) 20:35, 20 January 2026 (UTC)[reply]
Disputed BLARs go through AfD (despite being much more similar to merge requests than hitting the delete button), but I've never seen any ban, or anybody be sanctioned, for discussing the merits of a BLAR on an article or user talkpage. GreenLipstickLesbian💌🧸20:49, 20 January 2026 (UTC)[reply]
Some hypotheticals:
Editor Alice creates article Foo. Article Foo is about a topic that is not notable on its own, but the topic is covered in article Bar. Bob boldly merges the article. Alice objects.
Status quo: After Alice objects and reverses the merge, Bob does what the instructions at Wikipedia:Merging says and opens a proposted merger discussion, which is listed at PAM. Alice responds and objects, but nobody else participates in the discussion. The discussion remains open for several months until someone patrolling PAM closes it as no consensus. Bob has no other mechanism for gaining consensus for a merge, and gives up on trying.
After this proposal: After Alice objects and reverses the merge, Bob goes to AfD, which is the new forum for formal merge discussions. Alice objects, there's a discussion at AfD, and consensus one way or the other is established after a week, or at most after three relists.
Article Foo has existed for a long time. Charlie thinks the article should be merged. Charlie isn't sure what to do. Charlie goes to a WikiProject and asks for advice. The editors at the WikiProject agree, Charlie completes the merge, and nobody objects.
Status quo: This can happen.
After this proposal: This can happen.
Same as number 2, but Charlie asks another editor for advice on the article talk page without opening a proposed merge discussion.
Status quo: This can happen.
After this proposal: This can happen.
Same as number 2/3, but at the WikiProject/talk page, Devin objects before the merge can happen.
Status quo: See the answer to question 1.
After this proposal: See the answer to question 1.
So, to answer your question, no, editors will not be forbidden from reaching an informal consensus to merge outside of AfD, just like they can do now with draftifications (in some circumstnaces) or BLARs. All this proposal would do is merge formal merge discussions into AfD. So, yes, that would mean that the proposed merger tags probably would be eliminated since they would be unnecessary. voorts (talk/contributions) 21:52, 20 January 2026 (UTC)[reply]
(Note that I've been in the position of editor Bob before and found the whole thing so frustrating – particularly when editor Alice has no grounding in PAGs – that I rarely even bother to propose merges anymore.) voorts (talk/contributions) 21:54, 20 January 2026 (UTC)[reply]
The assumption is that the AfD will have more participation, which is reasonable.
But in some ways, by enacting your proposal, you would have actually made it harder for Bob to get the article merged because Bob now has to create a separate page for an AfD discussion instead of just creating a new talk page section.
Also, what would the AfD tag even say? It can't say "this article has been nominated for deletion" because it hasn't been nominated for deletion. Either you must add some mechanism (e.g. a different template) to specify an AfD is proposing a merge, or you awkwardly say "this article has been proposed for merging or deletion".
You would have actually made it harder for Bob to get the article merged because Bob now has to create a separate page for an AfD discussion instead of just creating a new talk page section Bob could just use Twinkle. If Bob doesn't want to use Twinkle, then respectfully, that's a skill issue on Bob's part. Under the current system, if Bob isn't using Twinkle (which supports proposed merges), he needs to start a talk page discussion, copy the wikilink to that discussion, open up several articles, place the merge-to/from tags on them pointing to that discussion, add an edit summary, and submit.What would the AfD tag even say "This article has been proposed for merging." Other XfDs have options to change the text to something else (for example, a CfD tag can say "deletion" or "merging"). This is also implemented through Twinkle. You just check a different box. (Or, if you want to do it manually, change a parameter in the template when adding it to an article).This problem could alternatively be solved by making proposed merges have a similar notification system to requested moves. Or it could be solved by folding PAM into a system with robust notification and sorting mechanisms. voorts (talk/contributions) 22:12, 20 January 2026 (UTC)[reply]
he needs to start a talk page discussion
That's ridiculously easy in comparison, especially for new editors.
copy the wikilink to that discussion
No, he doesn't have to do that. Most people don't do that, in my experience. Even I often don't.
open up several articles
99% of the time the number of articles is just two, but even just 1 tag is enough to log it. An editor will add the second tag later, it's not an issue.
add an edit summary
No, he doesn't need to use any edit summary. It it not recommended by WP:MERGE.@Voorts How familiar are you to the merge process? Maybe the reason you think the process can be improved is that you may have misunderstood the steps a user needs to take? All someone really has to do is open a discussion asking someone to merge, and other editors can add the tag. This allows literally everyone, even people who don't regularly use WP or don’t have an account, to propose a merge. Adding so many steps will just result in a lot of articles remaining unmerged and not receiving the attention they need.The fact that the backlog is so great is a good thing. it means the process is accessible to everyone. FaviFake (talk) 16:33, 21 January 2026 (UTC)[reply]
I agree with @FaviFake. I am said new user, I proposed a merge based on advice I got from the teahouse and if I'd had to have gone through anything close to AfD I would have been turned off from starting that discussion. Also learning to place the templates manually and linking to the discussion is good for learning how Wikipedia works. Also imo merging articles in the backlog is a good task for newcomers, I've been learning a bunch about how consensus is formed, how the talk pages work, and how the MOS works by merging a few articles. ScrubbedFalcon (talk) 17:09, 21 January 2026 (UTC)[reply]
Same! When I joined, I loved how simple and straightforward the merge process was compared to AfD. There are no strict rules, no deadlines, no worries of being an involved closer(see below), no official start dates, no enforced backlog or relisting, no new pages created, no scripts to install, no buttons to click or people to notify. And I still do love it, for all its obvious flaws. FaviFake (talk) 17:17, 21 January 2026 (UTC)[reply]
I get where you're both coming from, but part of being involved in the backend of Wikipedia is learning to use tools like Twinkle, which makes a lot of things much easier. Twinkle is not that complicated to use. voorts (talk/contributions) 17:26, 21 January 2026 (UTC)[reply]
Any amount of friction is still friction. Asking users to go into their settings and enable a tool which creates and populates a page for them is more scary and complicated in comparison. besides, even if the level of friction were the same, TAs wouldn't be able to propose mergers! that's a huge accessibility problem FaviFake (talk) 17:30, 21 January 2026 (UTC)[reply]
How many TAs are regulalry proposing mergers? Also, as discussed above, they can just ask someone at WT:AFD to start an AfD discussion, which means they don't have to do any of the heavy lifting other than providing a rationale. voorts (talk/contributions) 17:41, 21 January 2026 (UTC)[reply]
they can just ask someone Friction, friction, friction.ask someone at WT:AFD Even more friction, they need to know what it is, how to get there, and wait for someone. Compared to just clicking "Talk" and "Add topic".I'd say about 5% of merge discussion I've seen were started by TAs. FaviFake (talk) 17:47, 21 January 2026 (UTC)[reply]
There's the same friction with proposed merging. The editor needs to know (1) articles can be merged together; (2) there's a process for doing so; and (3) that process requires tagging both articles. I don't see why one is anymore complicated or insider knowledge based than the other. voorts (talk/contributions) 20:32, 22 January 2026 (UTC)[reply]
I don't see what using twinkle has to do with it. Most of the merger process is about actually starting a discussion (having the discussion if people want to, and if not great, you learning something about WP:Silence) and then doing the work of merging the articles. Placing the templates and things is kind of just incidental to that. ScrubbedFalcon (talk) 17:35, 21 January 2026 (UTC)[reply]
I don't see what using twinkle has to do with it. If voorts' proposal is approved, you'd be virtually required to use it in order to start a merge discussion. Or you could take 10-15 minutes doing everything manually yourself without Twinkle. FaviFake (talk) 17:50, 21 January 2026 (UTC)[reply]
- that's an interesting argument - but you do have to worry about being an uninvolved closure. While, due to the the complete absence of interest in the PAM process, nobody has called you on it, but the policy is clear and laid out at Wikipedia:Non-admin closure:
Closing editors must abide by the standard of being uninvolved as described at Wikipedia:Administrators § Involved admins. Closing editors should be aware of any actual, potential or apparent conflicts of interest they may have that could affect their decision making, or give the appearance of impropriety, potentially compromising a consensus reached by the community by casting doubts on a closure. For the avoidance of doubt, editors should never close any discussion where they have !voted, or XfD discussions where they created or non-trivially contributed to the object under discussion.
If you don't know that, you shouldn't be closing discussions. The fact that one of your main arguments in support of the current merge process is "you don't need to worry about a rule that you absolutely do need to be worried about" I think, speaks to the problems in this area. GreenLipstickLesbian💌🧸21:06, 21 January 2026 (UTC)[reply]
I do know that, and I wasn't referring to that. I meant to say that there are less strict restrictions on who can close merge proposals, per WP:MERGECLOSE: (emphasis in original)
Any user, including the user who first proposed the merge, may close the discussion and move forward with the merge if enough time (normally one week or more) has elapsed and the consensus is clear or there has been no discussion.
I don't partecipate in merge proposals too often, and I almost never create new ones, but I don't think I've even broken this rule in the few involved merge closures I've performed. A good example would be Talk:Class president, which considered a pretty large number of pages and different proposals. It remained unclosed for a few months with no comments despite the consensus being pretty clear.So yes, that's one thing that I like about merge proposals. An example of how it could go terribly wrong is Talk:The Princess Diaries § Merge proposal, stuck in a limbo of incompatible consensuses.The proposal doesn't need to remain stuck due to bureaucracy. FaviFake (talk) 21:22, 21 January 2026 (UTC)[reply]
Favi, you changed that page the other week to state that involved merges are allowed if there is almost unanimous consensus to merge (fine pretty much everywhere, even the odd AfD can get closed that way if there is WP:SNOW) to the consensus is clear[4] (a very different claim).
You made that edit on the very same day Amakuru called you out for your WP:INVOLVED closure of the Class president discussion, [5] only a few hours later, in fact, which is seen as a form of WP:GAMING (per WP:PGBOLD, Editing a policy to support your own argument in an active discussion may be seen as gaming the system, especially if you do not disclose it when making the edits. and I invite you to self-revert. GreenLipstickLesbian💌🧸21:32, 21 January 2026 (UTC)[reply]
Amakuru didn't "call me out" for anything. Rather, they thanked me for the close (thanks for your close on this above, and by-and-large this seems good - hopefully a decent rationalisation of the different topics), as did other participants. Their message was about a different discussion that I had totally forgot about, as I explained in detail.I didn't edit any policy or guideline pages, and I clearly didn't need to do it to "support my own argument in an active discussion" as I agreed with Amakuru. And besides, the consensus in the discussion I closed was indeed almost unanimous, if you actually go read it.You're mistaking forgetfulness for malice. FaviFake (talk) 21:44, 21 January 2026 (UTC)[reply]
No, strictly speaking, you edited an information page explaining the policies and guidelines, without mentioning that you had a potential COI due to an ongoing dispute. Which I would say, though you chose to quote the thanking part, the part I was focussed on was the part where they said: Given that you have been almost the only editor strongly pushing the merger of that page, I feel like you are too WP:INVOLVED to have enacted a controversial close on the discussion in favour of the merge. When you say forgetfullness, I can believe you, but when the result is the same: an editor took issue with a close, you changed the WP:MERGE page to be more in line with what you thought it would say, in a way that impacted the dispute.
Closing merge discussions has the same set of complex rules as AfD - the fact that these aren't as clearly written down has done you a disservice, because it's hiding the level of expertise actually expected. GreenLipstickLesbian💌🧸21:53, 21 January 2026 (UTC)[reply]
edited an information page Not a policy nor a guideline.ongoing dispute There was no dispute, I fully agreed with Amakuru.in a way that impacted the dispute It didn't impact anything because, again, literally everyone in that discussion agreed with each other and there was no dispute. You keep dodging this tidbit.an editor took issue with a close, you changed the WP:MERGE page to be more in line with what you thought it would say This is correct, though as far as I remember these events are a bit unrelated. I was probably double checking WP:MERGE and found the phrasing "almost unanimous" odd.Again, I very rarely close merge proposals I'm involved in, and if i recall correctly, none of the other ones I've done didn't have an "almost unanimous" consensus. (Including this one, technically; the consensus against merging was formed in a different discussion that ended months prior, which is why i missed it) FaviFake (talk) 22:18, 21 January 2026 (UTC)[reply]
Voorts is right that this is not the place to litigate this issue, but I think it is worth noting that explicit mitigation of concerns surrounding being involved have been in WP:M4 for almost 5 years, long before Favi edited the page: Special:Diff/1025824916; and even then, that edit was clarifying wording that has been on the page for 15 years: Special:Diff/396586604 ~ oklopfer (💬) 15:32, 22 January 2026 (UTC)[reply]
Yup. Now that you brought it up, I think I remember why I changed "almost unanimous" to "clear", I probably did it so that its meaning wouldn't differ from the paragraph directly below it: (emphasis supplied) In more unclear, controversial cases, the determination that a consensus to merge has or has not been achieved should be made by an editor who is neutral [...].FaviFake (talk) 16:21, 23 January 2026 (UTC)[reply]
This change wouldn't affect your work on the backlog (and thank you for working on it). The backlog would still exist and you'd still be able to help with clearing it. voorts (talk/contributions) 17:28, 21 January 2026 (UTC)[reply]
Alternatively, after Bob sits staring at a discussion for six months, Bob decides that he's not going to bother with PAM next time he believers a merge is needed, he's juts going to send the article to AfD, and wait for another participant to suggest a merge.
The problem is proposed merges never get two other responses within a few hours unless you ping them or it's affected by a current event. Aaron Liu (talk) 03:13, 20 January 2026 (UTC)[reply]
You perform the merge within a couple of hours of requesting it. No, the usual process is: you keep the discussion open for at least seven days, then the nom or another editor close it and perform it. Or you boldly do it without tags or talk page discussions FaviFake (talk) 16:49, 20 January 2026 (UTC)[reply]
Well… there is one way to make a merger instant: simply copy all the text from the merging article and paste it into the target… leaving it to editors to then clean things up afterwords. I agree that doing this would not be the best way to merge, but it would be instant. Blueboar (talk) 21:43, 20 January 2026 (UTC)[reply]
FaviFake did not argueg that it had to stay open for 7 days, exactly - they said that was the usual process. Which, if you look at WP:MERGECLOSE:
Any user, including the user who first proposed the merge, may close the discussion and move forward with the merge if enough time (normally one week or more) has elapsed and the consensus is clear or there has been no discussion
@SuperPianoMan9167 If it helps, there's often an unwritten expectation that discussions last a minimum of one week; if you close a discussion after just a few hours, you end up shutting out everybody who isn't online that day, or just lives in a different time zone as you. Even when consensus is looking obvious, unless there's WP:SNOW, it's rare to close a formal discussion after even 24 hours. GreenLipstickLesbian💌🧸19:56, 20 January 2026 (UTC)[reply]
Yes, with the understanding that for trivial merges, try WP:BOLD and only if there's pushback then revert and AFD away; and for minor merges, proposed text at the target article can potentially be implemented before the AFD is closed given that the information should nominally belong there. For larger merges, the (stated) expectation should be that the AFD is consensus/authorisation to go ahead, that there may need to be further discussion at the target article on how things are merged (perhaps with WP:3O input); and the nominator would perform a sizable proportion of the work. Repeated merge nominations without actually putting in the work to complete merges should be considered as disruptive. Merges are already discussed at AFD as WP:ATD (and something like 5% of my !votes have been for them). ~Hydronium~Hydroxide~(Talk)~01:57, 20 January 2026 (UTC)[reply]
Weak opposition - I think the PAM system is useful for quick (non-controversial) mergers, and since we can already !vote to “keep but merge” at AFD, I don’t think the proposal is needed. Note - we currently say that AFD isn’t for “article clean up”… and shifting it to “Articles for discussion” might change that. Not sure if that would be good or bad. Blueboar (talk) 03:17, 20 January 2026 (UTC)[reply]
Quick (non-controversial) mergers shouldn't be put through PAM in the first place per WP:NOTBURO. The first sentence of WP:MERGEPROP says: "If the need for a merge is obvious, editors are encouraged to be bold and simply do it themselves." I disagree that shifting it to “Articles for discussion” might change what AfD becomes. All it would do is add merging to the potential nomination outcomes along with delete, redirect, and draftification. voorts (talk/contributions) 03:30, 20 January 2026 (UTC)[reply]
Yes. Merge is the reasonable outcome for many AfD, and merge discussions are often buried away with no urgency to resolve quickly, unlike AfD. Joining them will speed up the process for the merge, allow for more participation from various editors, creating stronger consensus as it approached it broader audience of editors. ✠ SunDawn ✠Contact me!03:45, 20 January 2026 (UTC)[reply]
No. I share the same concerns about how moving merging to AfD would not address the backlog issue and add barriers to merging, but another reasons is that I see merging as being complimentary to splitting (something that I haven't seen brought up here in the !votes yet), which if this proposal goes through, then the process of splitting would remain unchanged while merging would now have to be done at AfD (assuming it is not done boldly). That doesn't sound like a natural approach to me for handling the question of whether to have a subject be broken up into multiple articles, or to have them all centralized in one article. As splitting would become cheaper, this could theoretically become the easier answer to said question, and it thus would be harder to undo a split if a merge has to be done behind AfD (assuming a bold merge was reverted). I could potentially see myself shifting to a yes if:
Both merges and splits were given to AfD,
AfD was renamed to Articles for Discussion to describe its new responsibility of handling merges and splits,
A grace period of say 3 days before !votes can be casted, in order to give participants time to discuss the article and form opinions on the best course of action, analagous to WP:GAR and WP:FAR. This is to prevent a knee-jerk reaction of keep/delete !votes that might not be the right fit for the article, and to get editors invested so that they might follow through on a merge or split if that was the result.
I admit that I don't participate in AfD (having only done so once I believe), so its possible that my proposals here might be flawed to regular participants. Gramix13 (talk) 04:34, 20 January 2026 (UTC)[reply]
No. The problematic part of a merge discussion is actually doing the merge. Getting the consensus done in a more rushed way with a shorter time limit is not going to help with that and is not going to result in better-reasoned outcomes. —David Eppstein (talk) 06:21, 20 January 2026 (UTC)[reply]
I don't actually agree that the problematic part is doing the merge - it's just a bit tedious. The problematic part is reaching a quorum.
Take Talk:Abbey Crunch#Merge Proposal, which I opened last April after a no consensus AfD leaning support for a merge. Two months of radio silence, a bold merge, the article creator undid me, refused to say why, until finally somebody else comes along and read a consensus to merge a month later... based only on the AfD discussion. 5 months, no new participants. Other merge discussions go similarly - take the oldest in the category, Talk:Parameterized post-Newtonian formalism#Merge proposal. A NAC close of a merge discussion that took 9 months, with no participants outside the nom. There's no quorum; that's not a good discussion. Picking another, Talk:Rambhadracharya#Merge proposal. Two editors voiced support for merging the article, one voiced opposition - 6 months, and the PAGs invoked were AFD specific. What well reasoned outcomes are happening here? GreenLipstickLesbian💌🧸16:25, 20 January 2026 (UTC)[reply]
But let's take merge discussions at AfD:
Wikipedia:Articles for deletion/Kamala (elephant) - the third participant suggested a merge, after which it become a merge discussion rather than an AfD. 1 week, 10 participants, solid consensus against a merge & the article is now a GA.
Wikipedia:Articles for deletion/Tula-Tu - 1 week, solid consensus for a merge, and solid consensus that the "to be merged to article" should exist, which was not, in fact, clear at the time of the nom.
Wikipedia:Articles for deletion/Sheppey Crossing crash - AfD, I, as first participant, turned it into a merge discussion (and voiced my opinion against a merge). 1 week, 4 participants, clear consensus that, despite technically meeting notability/page requirements, this works better as a subsection.
I don't think !voting "redirect" or "merge" in an AfD automatically transforms it into a merge discussion. The article could still be deleted after the discussion is over if there is consensus to do so. SuperPianoMan9167 (talk) 19:47, 20 January 2026 (UTC)[reply]
As a person who !votes at AFD to redirect and merge more often than average (about a third of AFDs in which I !vote, though half the time, I don't place a normal !vote), I agree that my !votes do not change AFD into merge discussions, and I can attest that the result is still frequently deletion. WhatamIdoing (talk) 20:13, 20 January 2026 (UTC)[reply]
Out of your last 200 comments in AfD, which stretch back to 2015, you've apparently placed about 22 merge votes. Of those, only 3 (a little under 14%) have ended in delete; the same number have ended in keep. Something I did notice is that, in those discussions, [6][7][8], all three has other editors specifically discussing the merits of the merge, before !voting for or against it. Did they turn into PAM discussions TM? No, but a group of editors sat down, and discussed the pros and cons of a merge, and whether or not they should do one... aka a merge discussion.... GreenLipstickLesbian💌🧸20:43, 20 January 2026 (UTC)[reply]
This, exactly. Anyone familiar with how average merge discussions on low traffic articles go know that it looks like this, all the time. Contrary to what other commenters say, I also do not think we lack editors willing to do the merge themselves; actually, most of these lonely proposals that never get traction have a motivated editor to carry them: the nominator. What usually happens though is that since there are no answers for months, the nominator does not go forward, even though most of these should be bold mergers that do not even warrant discussion, but there is no one to tell them that. And in the case where they do go forward after a few months of waiting and it wasn't actually an uncontroversial scenario, then it becomes a frustrating mess for everyone involved and an enormous waste of time. Choucas0 🐦⬛17:38, 20 January 2026 (UTC)[reply]
I've had the same experience with creating merge discussions. Article creator objects to a bold merge for reasons that have nothing to do with PAGs, I open a merge discussion, notify relevant wikiprojects, it sits for months with only my comment and article creator, and then gets closed as no consensus. voorts (talk/contributions) 18:14, 20 January 2026 (UTC)[reply]
The problem @Choucas0 describes can be solved with a simple rule, like "If nobody objects after a few weeks, then please Wikipedia:Be bold".
The problem Voorts describes is harder to solve, because it suggests a lack of editors to make a decision. (Thus, presumably this proposal: AFD's getting four editors on average, and I'm only getting two, so if I go over there, maybe I'll get a third opinion!) Based on the large number of merge notices that arrive at Wikipedia talk:WikiProject Medicine, I suspect that many editors tune out the notifications. That might be true for merge proposals at AFD, though. The AFD regulars might not feel the same sense of urgency about a merge proposal. WhatamIdoing (talk) 20:16, 20 January 2026 (UTC)[reply]
I can't find any merge notices on that page. Part of what should make this proposal work is AfD's delsort infrastructure and most importantly its supply of closers. I'm hesitant to accept that closers are far more likely to refuse closing merge nominations unless we see this proposal play out first. Aaron Liu (talk) 00:22, 21 January 2026 (UTC)[reply]
Many of these discussions that never go anywhere are actually about uncontroversial mergers, they just do not happen because it is often not clear to the nominator that a bold merge would be fine. Such discussions would be closed very fast, which is often a factor in how motivated the nominator still is to perform the merge. There is also a backlog of mergers that need to be performed without coming from an AfD discussion; shifting backlogs around does not increase or decrease them, but if it brings them together it might generate more attention and that could help reducing their size. Choucas0 🐦⬛17:55, 20 January 2026 (UTC)[reply]
If all we need is to "generate more attention", then what's the point of merging AfD and PAM? If we merged noticeboards just to get more attention, we'd only have a couple. FaviFake (talk) 18:29, 20 January 2026 (UTC)[reply]
The point as you mentioned is to capture more attention. Most noticeboards have sufficient attention, and historically are the product of merges of noticeboards that received less attention individually. Aaron Liu (talk) 19:08, 20 January 2026 (UTC)[reply]
No – Merge discussions are fundamentally different from AfDs. This proposal might reduce the number of overlapping processes, but I don't see how it will actually facilitate more efficient merging. I am also concerned that adoption of this proposal would raise the procedural hurdles for merges, which are quite different in character from deletion (i.e. unlike deletion, they don't render any content invisible to lay editors like myself). Yours, &c.RGloucester — ☎09:30, 20 January 2026 (UTC)[reply]
Yes - Frankly the number of mergers you see happening as a result of AFD discussions is way more than are handled through this system. FOARP (talk) 12:56, 20 January 2026 (UTC)[reply]
I make it 179 merge discussions handled by the merge process in 2025, versus roughly 4% of the ~20,000 articles nominated at AFD each year being closed as merge (i.e., ~800 mergers!) FOARP (talk) 21:07, 20 January 2026 (UTC)[reply]
But I'd assume these are much easier to perform? The ones I see are either very short or terribly sourced, so I usually only have to merge a few sentences at most. This is very different from merging full-length articles, which I like doing but don't always have the time to do. FaviFake (talk) 21:10, 20 January 2026 (UTC)[reply]
I think the question is what "handled by the merge process" means. On June 30th, Wikipedia:Proposed mergers/Log/June 2025 listed 220 open merge proposals (some having been open for mere hours, and others for 30 days; in the meantime, some were opened and closed).
Were those 220 discussions "handled by the merge process"? Or does @FOARP only count ~15 of them (which ones?) as "handled by the merge process", and all the others were handled through some other, unspecified process? There are only 11 articles from that month that still have merge tags on them, so something happened to the other 200+ merge proposals. WhatamIdoing (talk) 21:29, 20 January 2026 (UTC)[reply]
I'm counting the merges for which a close was archived here. Mergers that weren't closed aren't being "handled" are they?
AFD produced ~4 times the number of merges, than the merge discussions for which a closure of any sort at all was logged. FOARP (talk) 09:54, 21 January 2026 (UTC)[reply]
No These serve two completely different functions. Merging is not deletion. Even though an AfD can end in a merge result, a merge request should never end up in deletion. Deletion is a very serious matter and the two should not be conflated at all. SportingFlyerT·C15:55, 20 January 2026 (UTC)[reply]
Plus this won't solve the problem that it's trying to solve. I've just discovered Wikipedia:Proposed article mergers. It's a mess. A reform to the merger system would be good, but merging it with AfD will be even more of a mess. I agree we need more users to actually perform the mergers, and that needs to be better advertised... SportingFlyerT·C15:59, 20 January 2026 (UTC)[reply]
Part of the point here though is to solidify the idea that deletion does not have to be the default outcome at AfD, since after all the ATDs are already a point of focus of many of these discussions. This is why there is discussion here for renaming AfD, because this process would be more about bringing problematic articles for attention and then assessing what is the best way forward. In essence, that is already what AfD is currently, and why merging is already a common avenue of resolution for these discussions. We might as well formalize what already exists, especially if it can help solving other problems (like participation in discussion) on the way. Choucas0 🐦⬛17:48, 20 January 2026 (UTC)[reply]
For better or worse, AfD currently still has a very high deletion rate and bringing more reliably sourced material (as proposed mergers tend to have) to a forum that tends to delete a lot of stuff might end up deleting things that shouldn't be deleted. Katzrockso (talk) 18:08, 20 January 2026 (UTC)[reply]
I had to do this manually, but in January 2026 - I've found these 25 AfDs where the possibility of merge was explicitly mentioned by one or more participants:
Often, the "possibility of a merge" is merely that the nom or a !voter said they looked for a potential merge target and couldn't find one; it's frequently also just somebody suggesting a merge, and other AfD participants providing PAG-based arguments against said merge. Which is what we want to happen - have discussions as a community and come to a consensus, even if we, as individuals, do not agree with the result of every decision. GreenLipstickLesbian💌🧸19:15, 20 January 2026 (UTC)[reply]
I find 40 deleted articles so far this month in which someone mentioned the word 'merge' and the article was deleted. I find 23 for AFDs closing as keep, when someone mentioned the word 'merge', and 59 in which the result was merging. A spot check suggests that something on the order of 20% of the noms for these AFDs considered merge as a plausible outcome, and the other 80% didn't. Let's say this is 125 AFDs this month in which anyone mentioned a merge at all, and probably less than 25 in which merge was an intended/expected/hoped-for result.
When I'm advocating for a merge in an AfD discussion, it's about making sure usable sourced content shouldn't be deleted from the project from a page which should otherwise be deleted on notability grounds.
I haven't studied proposed merges as scientifically, just doing spot checks as that's all I have time for. Some merge discussions should actually be at AfD because they directly deal with notability. See Talk:Melissa Lawson. Others are basically trying to de-dupe the project. See Talk:Marriage in Myanmar. Others appear to be specific to content. See Talk:Indian 2 or Talk:Subgiant.
Not necessarily. For example, AFD regulars could decide to skip the merge proposals. (I would expect some, but not all, to do this.) Also, if AFD participation is a zero-sum game, then increasing participation in the merge proposals could reduce the participation in deletion discussions. Last I checked (a few years ago), AFD was averaging four participants, and I believe that four is enough, but any decline is potentially problematic for AFD. WhatamIdoing (talk) 20:44, 20 January 2026 (UTC)[reply]
Fair enough. But I believe the lack of closing the merger proposals (not necessarily implementing them) is also a problem that this solves. Aaron Liu (talk) 00:25, 21 January 2026 (UTC)[reply]
No per PARAKANYAA. This takes a relatively well-defined and narrow process with a specific purpose (AfD) and proposes to enlarge its scope and breadth with insufficient clarity about the final result. AfD already suffers from enough WP:WRONGFORUM nominations who seek to rename/move the article, change the inclusion criterion for a list, etc. The very first sentence of WP:AFD is Articles for deletion (AfD) is where Wikipedians discuss whether an article should be deleted. The fundamental purpose of AfD is to determine whether an article should be deleted. Sometimes through the course of discussion, editors propose alternatives to deletion because they preserve important edit history or reliably sourced information that might be useful in the future. That does not mean that the forum should be expanded to discuss how to edit an article (i.e. how/what to merge). Should we merge WP:RM into the newly named "Articles for discussion"? Articles already have a place for discussion: the talk page.The issues with PAM should be resolved in a separate manner; perhaps merging WP:PAM with WP:RM would be more fruitful given that RM has more activity.Katzrockso (talk) 18:31, 20 January 2026 (UTC)[reply]
Yes per GLL. I came into this pretty ambivalent, but the data is clear: AfD is already where merges are happening. Let's codify that. (If this doesn't pass, then I beg the technical wizards to convert PAM to the format of RM#C and ensure proper WikiProject talk page notifications are sent out for merge discussions.) Toadspike[Talk]21:31, 20 January 2026 (UTC)[reply]
No unfortunately AfD is populated by a minority of dodgy new accounts who are voting as quickly as possible to get autoconfirmed so they can publish dodgy articles into mainspace so merge discussions will not get proper attention in my view, Atlantic306 (talk) 22:28, 20 January 2026 (UTC)[reply]
I am sorry but I do not understand the logic here. Because you think AfD is broken in some way, we should not change it in any other way whether it is related or not? If these accounts vote "as quickly as possible" then the closers of these discussion probably has no difficulty seeing that and weighing these votes accordingly. Merge discussions currently get almost no attention at all whether from newbies or established editors, if we increase the participation of both we end up with better quality discussions and consensus by default. Choucas0 🐦⬛15:02, 21 January 2026 (UTC)[reply]
Yes – this is the most sensible option on both the pragmatic and the theoretical level. Pragmatically speaking, the current PAM process is just broken. It is scattershot, undertrafficked, and inconsistent with basically every other content review process. Discussions remain open for months with barely any participation. Barely any reference is made to controlling policy in the discussions. Integrating merges into the structure of AfD – which would take basically nothing, it's already the way most merges happen – means the merge discussion happens in a streamlined way and puts lots more eyeballs on each and every nomination. Theoretically speaking, some people have argued that deletion is so fundamentally different from merging that the two processes simply can't be joined. This argument is silly when you consider that AfD already does merges, but even more than that, the merging guidelines are literally a part of WP:N. There's no difference between merging and redirecting, the latter of which is solely AfD, other than what happens to some unrelated article. AfD should be like every other XfD venue: "articles for discussion", where each article can be considered holistically against the notability guidelines and the associated AfD criteria. If MfD was only "miscellany for deletion" and you had to go a middle-of-nowhere talk page that nobody looks at to try and get it merge, it'd be truly bizarre. We keep falling into the trap of saying no to change that is probably good because "probably" isn't "definitely" and we don't want things to change from the way it's always been. That inaction has a real, net negative impact on the project. Let's leave that behind and just fix what's broken here. theleekycauldron (talk • she/her) 01:03, 21 January 2026 (UTC)[reply]
This argument is silly when you consider that AfD already does merges, but even more than that, the merging guidelines are literally a part of WP:N. To the extent that AfD "does" merges, they are a byproduct of the discussion, not the intention from the start. The AfDs that start with an intent to merge from the get-go are malformed, WP:WRONGFORUM nominations and meet WP:CSK#1 given that they fail to provide any WP:DEL-REASON. Nevertheless, I still believe that AfD should be producing fewer merge results, rather than merge discussions, because the entire discussion of what to merge/not merge and how to merge is an issue with editing, not with notability. Several editors have convinced me that closers should close an AfD as a redirect, which always permits editors to selectively merge content that they believe is reliably sourced and encyclopedic. Mandating a merge of no specificity has caused merges to languish. Katzrockso (talk) 03:37, 21 January 2026 (UTC)[reply]
the entire discussion of what to merge/not merge and how to merge is an issue with editing, not with notability. You're correct, that's an editorial decision. However, our current process of PAM isn't designed for that either. It's designed for determining whether there's consensus to merge. If there is, then editors figure out what to merge after consensus is found. voorts (talk/contributions) 14:05, 21 January 2026 (UTC)[reply]
No per SportingFlyer. Yes, sometimes mergers are the outcome of AfD, but I agree there's too great of a risk that valid material will be outright deleted from the encyclopedia instead of being placed in a different article. Even if the below suggested name change occurs, the D in AfD will still be thought of as "deletion" by default, as it often is on the other XfD pages, even though they adopted "discussion" in their names ages ago. The idea positives above of making merger proposals more akin to RMs is a better path to take. oknazevad (talk) 01:59, 21 January 2026 (UTC)[reply]
No. It seems to me that AfD is primarily used to evaluate WP:Notability and if that results in merge instead of deletion then so be it. WP:Merge is more editorial, for example combining notable and related stub articles into longer and better articles, I think its a fundementally different process. An AfD discussion might serve as a starting point for a merger discussion, but the merger discussion and process is of a different nature. ScrubbedFalcon (talk) 12:30, 21 January 2026 (UTC)[reply]
Combining stubs almost always falls into bold merge territory where no discussion is warranted anyways. I also do not see how discussions at AfD are in any way less about "editorial" matters than merge proposals. Besides, if AfDs already routinely serve as starting points for merger discussions, then it shows well that there is no substantial difference on this point. Choucas0 🐦⬛14:56, 21 January 2026 (UTC)[reply]
I think being able to do a bold merge is something you have to learn by experiencing WP:Silence - its not something that's intuitive for new editors. The merge process as it is now is approachable. ScrubbedFalcon (talk) 17:13, 21 January 2026 (UTC)[reply]
I disagree. It is not a matter of silent consensus, it is a matter of no one telling editors that they can and should just go for it, because the very fact that most merges should be done boldly is not widely known, from personal experience but also simply by looking at this discussion. If the merge process was approachable enough we would not have such backlogs and so little participation. Choucas0 🐦⬛17:54, 21 January 2026 (UTC)[reply]
I think the merge process is more approachable for new editors than AfD. New editors/TAs are unsure whether its OK for them to edit at all, proposing a merge as it is now is already a tall ask, asking them to report to a centralized AfD process is an even higher ask. The unapproachable/not done part of merging is actually doing the merging but that wouldn't be fixed by this proposal. ScrubbedFalcon (talk) 15:16, 22 January 2026 (UTC)[reply]
The unapproachable/not done part of merging is actually doing the merging What about the concerns raised here that discussion itself and closing PM threads is also the "not done part of merging". voorts (talk/contributions) 15:27, 22 January 2026 (UTC)[reply]
I think its unfortunate that there isn't more participation in the discussions, I don't think that that's indicative of a fundamental flaw. I also think we can be creative about ways to increase participation in decentralized conversations without centralizing all of them to one place, for example:
We could make the "discuss merging a random article" button on CAT:MERGE more prominent (for example at the task center or maybe the top of the AfD page) with a reminder that people can close discussions themselves if the discussion is more than a week or two old.
Transcluding the discussion from the talk pages into a centralized page that's more easily monitored
Establishing a team that monitors for conversations started by TAs to add the necessary templates and such to make it easier to find all the conversations (conversations that are started and not tagged).
Your second proposal of transclusion would require editors to manually copy and paste the transclusion, just like AfD, so that would increase complexity in the same way. As for your second proposal, we already have a system that is closely watched and helps TAs start discussions. That system is AfD. voorts (talk/contributions) 16:05, 22 January 2026 (UTC)[reply]
I thought there might be a way to get a bot to do the transclusion based on the discussion link that's already required by the merge to or merge from template. But I'm definitely not a expert on that. ScrubbedFalcon (talk) 16:13, 22 January 2026 (UTC)[reply]
we already have a system that is closely watched and helps TAs start discussions. That system is AfD. But that system requires a centralized discussion which people need to find and understand on some level first. The lowest bar way to start the discussion is just on the talk page of one of the articles proposed for merging. ScrubbedFalcon (talk) 16:20, 22 January 2026 (UTC)[reply]
Editors also need to know that the merge-to/merge-from tags exist and that there's a process for proposing merges and advertising them. Even under the current system, starting a talk page discussion without using the tags means nobody will see it. voorts (talk/contributions) 16:32, 22 January 2026 (UTC)[reply]
Even under the current system, starting a talk page discussion without using the tags means nobody will see it. Right, hence my third idea for having a team that can watch for that. How many different ways are there to recommend a merge, I'm sure we could put together a dictionary that could automatically detect merge proposals on talk pages that aren't tagged. Then there's the matter of getting people to respond to the discussions (my first proposal). I agree with you that it could be easier to find the discussions and that that could help make people more engaged, I disagree that the solution is centralizing all of the discussions in one place. ScrubbedFalcon (talk) 16:47, 22 January 2026 (UTC)[reply]
I agree with you that it could be easier to find the discussions and that that could help make people more engaged. It already is easy to find the discussions at PAM. The issue is that very few editors use PAM because nobody uses PAM and nobody closes discussions. Just saying "we can get more people to participate" is not a solution. voorts (talk/contributions) 17:02, 22 January 2026 (UTC)[reply]
Yes in practice, nothing would change, because pretty much nobody uses the proposed merge process anyway—I'd wager that many times more articles are merged through AfD than PAM. ~~ AirshipJungleman29 (talk) 17:07, 21 January 2026 (UTC)[reply]
NO I'm worried this will just muck up the AfD process; from what I read above, it's not the merge discussions themselves, but the actual merges that need help. If we did merge AfD and merge discussions, I'm not sure how that would be made clear which "vote" is for what, and Twinkle likely has to be looked at to ensure it works with whatever new setup we create (is this a "merge" or a "Deletion" discussion). AfD works well enough now, I'm not sure changing what works is a great idea. Oaktree b (talk) 18:53, 21 January 2026 (UTC)[reply]
Changing Twinkle is not hard. It would be a matter of changing it to be similar to CfD, where you select from a drop-down menu which action you're proposing. RE which !vote is for what, I'm not sure I understand the concern. Editors already leave bold !votes in AfD discussions saying what they think should happen. voorts (talk/contributions) 19:00, 21 January 2026 (UTC)[reply]
No. AfD is vastly overburdened already and discussions there often don't get the attention they deserve. Adding mergers to that workload would be counterproductive of AfD's actual function. Jahaza (talk) 00:30, 22 January 2026 (UTC)[reply]
Yes. I've seen AfD topics that start out as merge discussions, indicating that some editors are using it for this already, likely because it will generate more discussion as a much more active space for such discussions. Even discussions that start out purely as suggestions for deletion often turn into discussions of merging. I agree with theleekycauldron's rationale that increasing the number of eyes on everything would be beneficial for the health of the encyclopedia, both from a content standpoint, and also for editors. If there are merge proposals that should have just been bold merges, the many very experienced editors at AfD will certainly tell that to nominators. I am also unmoved by the argument that content proposed to be merged will be deleted instead. While I don't agree with every closure at AfD, if there's content that there is consensus should be deleted from the platform that is simply remaining because editors haven't seen it to weigh in, then combining this processes into one seems absolutely necessary. Revolving Doormat (talk) 14:05, 22 January 2026 (UTC)[reply]
Comment to PARAKANYAA's argument AfD will make many mergers that would make sense as a content decision instead be voted against based on notability; this seems to be something that happens per WP:M3's example as opposition to a merger being based entirely on the idea that its subject matter is WP:NOTABLE. That speaks again to the idea that these processes are redundant, and may actually need notability discussion which is the central focus at AfD. Revolving Doormat (talk) 15:53, 22 January 2026 (UTC)[reply]
Yes, but without any expectation that this will solve all the problems with mergers. There's three problems with mergers right now, as I see it. Merge discussions lack sufficient participation, and often result in no consensus for lack of quorum. Reviewing merge discussions is a real pain, often getting bogged down in move reviews at noticeboards. And mergers are difficult to implement. The third of these is the largest problem by far, which this proposal would largely leave unaffected, or possibly even exacerbate as more merge discussions result in consensus. But the proposal would address the first two problems by funneling the greater effort pool of AfD into discussing mergers, which is something AfD is already doing a good bit of in practice. This will also have the desirable side effect of avoiding "this should be a merge proposal" procedural objections at AfD. Vanamonde93 (talk) 18:26, 22 January 2026 (UTC)[reply]
Yes - this is a sensible approach to an actual problem. This won't actually help with the backlog of articles needing to be merged, but at least having a formalized discussion establishing firm consensus that the merge should happen in the first place will avoid the discussions themselves going on forever. AFD has not been a rigid "delete or no delete" process for many years now. Ivanvector (Talk/Edits) 19:50, 22 January 2026 (UTC)[reply]
Yes There seems to be strong support for this and the reasons stated are huge issues. Requested moves has its own system. Merges deserve one, and given AFD allows merge as an option, this seems reasonable to merge it here. And then we can simply rename it Articles for Discussion. This is a colossal change that will be for the better. Also, Ive seen a lot of nominations that are basically intended to merge or redirect; people are already using it for this purpose. ← Metallurgist (talk) 05:14, 23 January 2026 (UTC)[reply]
No They are completely different domains, completly different animals. Afd is already dysfunctional and piling this on is just overburden it more. Why not create another board similar to Afd instead. Merge has nothing to do with deletion. All it will do is knacker it in extraneous detail that nobody is going ff for. scope_creepTalk05:27, 23 January 2026 (UTC)[reply]
Strong Yes, as I have long felt this would clarify process and make things easier and more streamlined. Already in an AfD merges often come up or are the result, why not just make it so that in an AfD a merge could be declared at the outset and made the suggestion by a nom? I once thought this is how it works anyway! Lets make it official. Agree strongly with user:Jclemens on this! Iljhgtn (they/them · talk) 15:49, 23 January 2026 (UTC)[reply]
They would be one and the same. AfD would include people !voting on articles for discussion (see rename discussion below), and that could include ultimately moving articles to be deleted, merged, redirected, draftified, and yes, merged (which is already kind of the case, but it makes it more clear and explicit). Iljhgtn (they/them · talk) 16:27, 23 January 2026 (UTC)[reply]
Yes, Merge discussions are often left languishing and going stale. However, if this does go ahead I think perhaps a rename of AFD is in order. I'd suggest renaming from Articles for Deletion to Articles for Discussion. TarnishedPathtalk02:45, 24 January 2026 (UTC)[reply]
No. Yes, but as a last resort only (see my update below). Deletion is fundamentally different from merging in that an uninvolved administrator is required to carry out a deletion, but any editor can carry out a merge. Already right now, editors are allowed and encouraged to be WP:BOLD and merge pages at their own discretion, without needing to propose it formally in a process. Only merges that are likely to be controversial need to be discussed on a talk page and/or listed at WP:PAM, but if no one participates in the merge discussion, then that's okay—that probably just means the idea to merge the article wasn't as controversial as you thought, and you should be free to be bold and carry out the merge yourself. If you find that the discussion is in a gridlock because you and a few other editors are disagreeing with each other, you can try to seek additional opinions through typical WP:APPNOTE routes like leaving {{subst:Please see}} on a WikiProject talk page or on the user talk pages of editors likely to be interested (while staying within the bounds of WP:APPNOTE). AfD is already backlogged enough as it is, and adding merges to AfD is only going to dilute that process and divert administrator attention (a limited resource) away from the issues where admin tools are actually needed.Mz7 (talk) 02:54, 24 January 2026 (UTC)[reply]
Update: Reading over some of the comments above more carefully, I think I do agree there is one legitimate problem: the case where in the merge discussion it is just you and one other editor (often the page creator) against each other, you've notified WikiProjects per WP:APPNOTE, and still there are no other editors interested. I think maybe I would be open to allowing this kind of situation to go to WP:AFD, but I think it should only be as a last resort, when starting with the talk page has failed to address the situation after some reasonable amount of time (that way we can filter out the uncontroversial cases that should have been done WP:BOLDly to start with). I will note that the status quo already allows you to advocate directly for a redirect at AfD, which is very similar to a merge, just without the content being carried over to the target article: see Wikipedia talk:Speedy keep/Archive 4#Should we permit deletion nominations advocating for a redirect?. Mz7 (talk) 03:33, 24 January 2026 (UTC)[reply]
@Mz7 Maybe this is a weird question, but a lot of your oppose !vote above seems reliant on the fact that you don't need uninvolved admins to carry out merges, but you do need them to carry out deletions. However, as you point out in your next comment, you're fine with contested/controversial BLARs or redirects going through AfD by default, as is the status quo- and, like you point out, these are "very similar to a merge", especially in terms of the fact that you don't need an uninvolved admin to carry them out. Could you expand on this? GreenLipstickLesbian💌🧸03:46, 24 January 2026 (UTC)[reply]
@GreenLipstickLesbian: When I wrote the first comment, my mind was against the proposal, but after thinking about it some more, especially in the context of contested BLARs, my stance softened a bit. Maybe I should strike my first comment. Sorry about my mercuriality on this. My main concern is with the AfD backlog and how we are utilizing community time—both that of the community members that participate at AfD and the administrators who volunteer to close them. I would like to see a process that continues to encourage editors to suggest merges outside of AfD (either through doing them boldly or by proposing on talk pages with {{merge to}}), and then going to AfD only if the proposal is contested in a no-quorum way. Maybe we could convert the {{merge to}} template to be something like a WP:PROD where if the template remains in place for 7 days without objection, then by rule you can proceed with merging, but if someone objects, then you have to go to AfD. What I want to avoid is editors going to AfD as a first resort for all of their merge proposals. Mz7 (talk) 07:15, 24 January 2026 (UTC)[reply]
What I want to avoid is editors going to AfD as a first resort for all of their merge proposals. Agreed. More people need to just boldly merge, and if they're reverted, then seek consensus. That would also likely solve a lot of the backlog problem. voorts (talk/contributions) 07:26, 24 January 2026 (UTC)[reply]
Experimenting by converting the merge system to something more prod-like would be interesting; I think, irrespective as to if this passes, trying to create a merge system like PROD would be a worthy experiment and I'm curious as to how it would play out.
To a certain extent, though, you learn by doing and getting feedback. If, under this proposed AfDiscussion, system, you see an editor sending an article to AfD that you think could have been boldly merged then you can just tell them to do that next time, the same way you might tell an editor now that they should have possibly tried bolding BLAR-ing or PROD-ing an article instead of AfD? Like, not to pick on you or anything, @Mz7 (same probably applies to voorts), but you've got a bunch of reviewed content, you've got a bunch of advanced permissions, and you're what I'd consider pretty in touch with the Wikipedia ecosystem. You probably have a much better feeling for what will be controversial than the average editor, who is going to be anywhere from recklessly bold/confident ("what do you mean one of *my* ideas isn't the next best thing since sliced bread?") to exceedingly timorous. ("Well, somebody wrote this as a separate article, so obviously they'd object to it being merged and therefore it's not a good candidate for bold merging..."). And then you've met with crickets for several months and then, just maybe, snippy message from the editor's work who you've just deleted, basically implying how you're the word's worst person for doing the merge unilaterally and how could you... and, like, yeah, unless a trusted Wiki-adult tells me "no, your original bold action was within one standard deviation of a normal editor's potential action", I'm gonna carry trying to get a second opinion. You're that trusted Wiki-adult though - again, if you're seeing people send articles they should have boldly BLAR-ed or PROD-ed through AfD, or (under current system) articles they should have boldly merged through PAM, please just tell them that? GreenLipstickLesbian💌🧸08:00, 24 January 2026 (UTC)[reply]
@GreenLipstickLesbian: I mean, I feel like I do also struggle constantly with trying to figure out whether an idea I have is gonna sail through without objections or whether other people might be all up in pitchforks about it. I'm not sure I agree it gets that much easier... That being said, I feel like the solution to that is exactly the kind of thing I described: having the process be designed in a way that reduces the guesswork, in this case by always beginning with either a bold merge or a {{merge to}} tag (maybe also add a talk page message to the page creator). Then, if someone reverts or objects, that'll be how you know it's controversial and requires a more thorough discussion at a higher visibility venue like AfD. Yes, getting reverted isn't fun, and oftentimes the person reverting you isn't happy with you and might leave you a snippy message. But I feel like that sort of conflict is kind of inevitable on a project like this. In some sense, this is the Wikipedia Way™: bold, revert, discuss. When in doubt, just go for it, and if someone reverts you, that's okay—that's your feedback to either seek more opinions or do things differently next time. Mz7 (talk) 09:11, 24 January 2026 (UTC)[reply]
@Mz7 That's true that some negative of pushback is expected and natural, but if that's the only feedback you ever get.... Especially taking into account, to a very large extent, we want editors who listen to that negative feedback and stop doing the action, that's how the vast majority of our systems work. Especially when dealing with people who have trouble picking up social cues already (We have a high percentage of autistic editors), you can't have both "pushback is normal, work through it" and "pushback is you fault and you are to be held responsible for it" systems operating simultaneously. Or, at least, you can't expect them to operate well.
I'd love to remove the guesswork - mandating editors try and boldly merge/propose merge non-CTOP articles (I'm not unilaterally merging the killing or abduction of an individual Israeli or Palestinian child into a larger scope article, and you can't make me) before opening a formal discussion could be interesting - however, given just how much dispute there can be over the choice of which content to merge, I would prefer to test it by mandating it before BLAR. Ideally, when dealing with BLARs, the content is less usable and they're easier to boldly undo (you only have to click undo on one article, after all, not sort through two dual histories... Undoing a bold merge after any length of time freaking sucks), so they should be less contentious. You also don't risk the article ending up in some "to be merged" category for weeks to months to years, should the proproser not get around to doing the merge in a timely manner. (Yes, that's going to happen no matter what - but I'm a lot happier indefinitely leaving an article on death row if there's community consensus that it should be there) GreenLipstickLesbian💌🧸21:12, 24 January 2026 (UTC)[reply]
It would be too easy to do driveby merges of articles that could otherwise be improved. At least with PROD, the admin then determines that the page isn't notable. With a hypothetical "PROM", the admin wouldn't even have to do that, leading to a focus on Mergism over helping build an encyclopedia. ᴢxᴄᴠʙɴᴍ (ᴛ) 20:35, 25 January 2026 (UTC)[reply]
driveby merges of articles that could otherwise be improved @Zxcvbnm That already happens every day, and doesn't happen often enough, which is why we have a 700-hundred-page backlog. This is supposed to be an addition option. Take the current AfD system:
Speedy deletion can be done at any time
PROD is less quick, but doesn't need a formal discussion
PAM is for controversial mergers, but is almost always used for uncontroversial mergers
If we added PROM as a second step, we'd likely have much fewer empty discussions to judge and close. Editors who don't want to carry out bold uncontroversial merges can propose them without creating a whole formal discussion in which everyone agrees with each other for months until someone actually does it.In the rare cases where the PROM is controversial, just undo it and discuss it at PAM, just like how expired PRODs are often brought to AfD. It would even be easier to undo than PROD, as anyone can restore merged articles. FaviFake (talk) 22:40, 25 January 2026 (UTC)[reply]
Yes The problem with merge discussions is that they do not attract a wide audience, only a small group of highly involved editors in that subject area usually respond to them, whose opinions may diverge from editors at large. Bringing merges to more peoples' attention and forcing them to be decided faster can only be beneficial to the encyclopedia. However, there needs to be a way to clearly delineate that it is a merge-only discussion and the article is otherwise considered notable. There is a risk of making it unclear whether or not the nom believes the page to be notable. ᴢxᴄᴠʙɴᴍ (ᴛ) 09:45, 24 January 2026 (UTC)[reply]
There could be some required box to fill out in the AfD nomination template like "Nominator believes article is: Notable (green)/Non-notable (red)". It would make it more obvious whether they are calling for a deletion with possible merge or just a straight-up merge. ᴢxᴄᴠʙɴᴍ (ᴛ) 09:02, 25 January 2026 (UTC)[reply]
I am not sure people should be AfDing or merging if they are unsure of notability. It puts the work on everyone else to determine whether it's notable or expandable as an article. In the former case, it may lead to wasted time, while in the latter case, it can promote reckless merging rather than trying to improve a page. ᴢxᴄᴠʙɴᴍ (ᴛ) 17:42, 25 January 2026 (UTC)[reply]
I think that's all the more reason they should be forced to clarify with a yes/no question. Wanting to delete or merge while being unaware if the article can stand on its own is just irresponsible, and gauging notability is a basic skill required to get involved in the deletion and merge processes. ᴢxᴄᴠʙɴᴍ (ᴛ) 20:27, 25 January 2026 (UTC)[reply]
This can be easily addressed by changing the AfD template to be similar to CfD, which already has options other than delete. It's also easily implemented via Twinkle.voorts (talk/contributions) 20:35, 25 January 2026 (UTC)[reply]
Yes (and rename AfD "Articles for Discussion" as suggested above). As a new page reviewer, I often come across a page that includes encyclopedic content but that does not meet the guidelines to be a standalone page. I've gotten more comfortable about doing bold merges over time, and that often works when a page creator is one-and-done and has not edited for many months. But if the page creator disagrees, it's a standoff of two. It takes months, most of the time, in my experience, for proposed merger discussions to reach quorum and some never have. AfD routinely reaches quorum and consensus because it's often frequented. This should address the execution problem too -- if a consensus can be reached within a week or two, the editor who proposed the merger is usually still active and engaged and watching the page, whereas if it lingers for many weeks or months, forgetfulness sets in. And when I've been part of AfDs that resulted in "merge", the merger is carried out relatively quickly, especially compared to the conclusion of a lengthy PAM discussion. There is much to be gained by integrating merger discussions at AfD and little to be lost. Dclemens1971 (talk) 15:27, 24 January 2026 (UTC)[reply]
(I really dislike "articles for discussion" as a name for the reasons I mentioned below. The word "discussion" is way too vague, and to a new editor "articles for discussion" sounds like a place I can bring any content dispute. The word "deletion" makes it clear that the discussion is about the suitability of the article as a standalone topic, and that the outcome of the discussion might be to make the standlone article go "poof" in some way, be it deletion, redirecting, or merging.) Mz7 (talk) 19:14, 24 January 2026 (UTC)[reply]
No/Oppose - A deletion nomination can become a merge, and that's good. I wouldn't want to see a merge nomination becoming a delete. It's poor process design. — The Transhumanist12:07, 25 January 2026 (UTC)[reply]
No - Article talk pages are the best place to discuss a merge proposal. Merge banners give good visibility to the editors that are best qualified to evaluate these proposals. The fact that merges take longer to resove than deletions is due to the extra consideration and work involved; it's a feature not a bug, WP:NODEADLINES. ~Kvng (talk) 15:22, 25 January 2026 (UTC)[reply]
Yes/Support. To expand on and refute some points that I've seen above:
Per voorts, this proposal doesn't have to solve all the issues with merging to be a step forward. We should remember that, per policy, "perfection is not required": any progress, however small, is still progress.
Some argue that AfD is a narrow process with a defined purpose: deletion. The latter case is obviously true, just read Articles for deletion, but is the former really true anymore and, in any case, should description bar us from improvement? I agree with Jclemens on this one. It does not make sense to make or follow policies or guidelines that are unfitting with reality: this is the reason we have the fifth pillar. To pick just one example, the now-finished Borlet debate is an example of how AfD has naturally evolved from only debating deletion to discussing more complex outcomes. This discussion in particular was closed procedurally due to becoming a de facto merge discussion, and is an example of how more progress might've been made if our policies were descriptive instead of prescriptive, per GLL.
Some editors object on the basis that merging has nothing to do with AfD, but merges already can and do happen at AfD, with nominators and participants alike often offering merging or redirection as an AtD. Also, per my second point, this is partially due to a disconect in the perception of what AfD is vs. what AfD actually does.
Merge discussions take a long time, and some see this as not fitting with the nature of AfD. One reason merge discussions take this long is the lack of participation in the first place (see this analysis from GLL). When merging is considered at AfD, the discussion is centralised, which we know provides an easier establishment of a quorum per GLL. While I believe there is no deadline overall, the complete lack of deadlines around merge discussions is a real problem that the timed format of AfD would solve. This is a not a bug, but a feature. There are already mechanisms to ensure important decisions are not rushed before consensus forms; this is why AfDs can be relisted several times. For the record, I fully agree with PARAKANYAA that this may not solve the issues with the implementation of closed discussions but, per my first point, I do not think this is a disqualifying issue.
This proposal will increase red tape, if the interpretation discussed below is correct. Mergers that could previously be carried out via normal talk page discussions may now be forced to go through the AfD process. Yours, &c.RGloucester — ☎09:28, 26 January 2026 (UTC)[reply]
It depends on the perspective. A common response to any administrative action here is, "This is not the right place for (x). It needs to be done (at y)." Deletion discussions often are met by merge scolds. The discussion goes nowhere, consensus is lost, editors get frustrated, and nothing improves.
Anything that can reduce the amount of confusion over process here will be an improvement, in my view. Right now, there are too many ways to skin the cat. Trumpetrep (talk) 16:21, 26 January 2026 (UTC)[reply]
On the other hand, in the current system you can just start a discussion and if people start talking about a merger you can add the tag and it will instantly become a merge discussion. You can't just move the discussion over to AfD if this proposal passes, which would greatly increase red tape in this case, as editors will have a first discussion at the talk page, then after they've decided to propose a merger they'll have the same discussion at AfD, and then once that's quickly closed they'll maybe have to get back to the talk page to organise carrying out the merger. FaviFake (talk) 16:25, 26 January 2026 (UTC)[reply]
Yes, subject to renaming AfD as "for discussion" or "for disposition" and adapting its description. Redirect and merge have become increasingly common outcomes at AfD, and I would argue that BLARs and merges are just a special kind of deletion that preserves page history and moves some of the content. Bold merges would remain possible, and we could always (no doubt via a follow-on RfC) envisage a PROM process, comparable to PROD, where the nom does not expect the merge to be controversial but still gives others a chance to contest. Rosbif73 (talk) 10:23, 26 January 2026 (UTC)[reply]
I don't think this will solve the problem of merge discussions languishing, but it does make some sense that AfD, merge, and split discussions all be the same thing. For instance, there was an AfD awhile back where in the discussion I proposed splitting the article, but AfD can't formally do that.--3family6 (Talk to me|See what I have done) — Preceding undated comment added 12:43, 26 January 2026 (UTC)[reply]
Yes I have personally seen merge discussions go on for literally months, whereas AfDs (generally) are handled very efficiently. Additionally, as a general rule, AfDs have much higher participation and community engagement than merges, despite merges taking more time to close. As a personal note, I hate the merge banner being on pages for months and there being no end in sight for when the banner is removed from the page. For all of these reasons and for reasons stated above, I am in favor of moving merges to be part of the AfD family. Gjb0zWxOb (talk) 18:50, 26 January 2026 (UTC)[reply]
No Per wbm1058, the number of articles proposed for merging has been trending downward. I already use AfD to pitch merges for non-notable sports team seasons into the team's article, so rather than doubting whether AfD attendees are capable of considering merge requests, my worry is that their limited time should not be used for content discussions on whether two articles satisfying notability should nonetheless be merged, have sections shortened with a hatnote to the other, etc. ViridianPenguin🐧 (💬) 19:04, 27 January 2026 (UTC)[reply]
Yes This would create a more seemless way for editors to review articles to be seen by more people for review. Some people use "Merge" as a way to delete articles and this can also help catch that behaviour. Guz13 (talk) 00:51, 28 January 2026 (UTC)[reply]
Yes. As I've mentioned before, it's crazy to have a system that allows merger requests at AfD as long as the nominator pretends to be asking for something else, and that's a good enough reason on its own to get rid of the legalistic rule at WP:CSK #1. I think it would have been better (strategically at least) if this proposal had just left it at that, but I can't really bring myself to oppose getting rid of PAM, a moribund process that hasn't adequately served its function for a very long time. Extraordinary Writ (talk) 19:19, 28 January 2026 (UTC)[reply]
Absolutely not. Merging is a valid AFD discussion but its as an ATD and I think this fundamentally too big a change for the development of the proposal. For example, DRV isnt the right location for appeals. SpartazHumbug!21:02, 28 January 2026 (UTC)[reply]
Yes per Ivanvector. The process is currently very broken, so we have little to lose by trying this. I disagree with the no !votes that claim the problem is only performing the merges — my experiences waiting months for discussions to happen shows otherwise. Sdkbtalk03:28, 29 January 2026 (UTC)[reply]
No. This would prevent me from participating in merge discussions just because I have an XfD topic ban. Merging is a less drastic and contentious option than deletion, and the XfD umbrella is already too broad as it is. Dronebogus (talk) 11:56, 29 January 2026 (UTC)[reply]
No. The backload is steadily falling (over the course of the last few years it's down by about 94% ... that is, from 16000 to 900 or so articles), and there are still active editors (including myself) who work on clearing the 'old' proposals. It's also fine for the discussions to be open for longer than an AfD would, in order to get the views of interested subject experts who more rarely visit. It's a low-stakes process than AfD, and that's very reasonable, because content is maintained through the AfD process. So, there isn't a problem worth fixing. Klbrain (talk) 19:48, 29 January 2026 (UTC)[reply]
Yes A golden opportunity to streamline processes, increase participation and improve consensus-building in complex discussions. As a new page reviewer one is sometimes met with articles that are borderline between delete and merge – this is a practical way to create a clear venue for this to be discussed by the community. Triptothecottage (talk) 01:07, 30 January 2026 (UTC)[reply]
Lean yes. Nobody uses the proposed merge function. When people does use it, discussions die and/or are open forever. I think making merges its own thing like RFD would be better, but the reality is merges already happen through AFD and that is far easier than convincing people to adopt a whole new page. Esolo5002 (talk) 22:44, 30 January 2026 (UTC)[reply]
Support merge. It makes sense to me that if contested or potentially controversial BLARs are discussed at AfD, contested or potentially controversial merges should be discussed there also. This already happens all the time and the process codified in policy should conform to the practical reality of our practices as editors where possible. silviaASH(inquire within)04:36, 3 February 2026 (UTC)[reply]
@PARAKANYAA: post-merge discussion languishing is a distinct issue from merge discussions themselves languishing. Merge discussions get very little participation compared to AfD discussions. Sometimes they sit for months with just the nominators' statement and nobody even closes it to show that the articles are ready for merging. At least with AfD the discussion would get closed and added to the proper "being merged" category, where editors can work on chipping away that backlog. voorts (talk/contributions) 18:43, 19 January 2026 (UTC)[reply]
This would get more eyes on articles and encourage faster closes so that the merge can proceed
Maybe a stupid question, but can't we just… have more eyes and hands on with WP:PAM? We do have an absurd backlog with both proposed and in progress mergers (1000+ pages combined), but will moving it around really relieve that weight? We need more willing participants as much as we need visibility. ~ oklopfer (💬) 07:16, 20 January 2026 (UTC)[reply]
Yeah, from reading the Yes !votes it seems most people think that if we move a backlog of a thousand pages into the formal AfD process, we'll magically have dozens of new editors who'll clear the backlog in no time.If anything, we'd be left with the same exact backlog, except with all thousand discussions closed and moved into a differently-named backlog. FaviFake (talk) 17:34, 20 January 2026 (UTC)[reply]
This would absolutely reduce the proposed merge backlog because discussions would actually get closed instead of remaining open for over half a year. The bulk of the backlog is from unclosed discussions. Less than a third of the backlog is merges that need to be completed. voorts (talk/contributions) 18:21, 20 January 2026 (UTC)[reply]
In my experience, almost all merge proposals are closed as merge. Even if just 90% were closed as merge, that's just a 10% reduction in the backlog of pages to merge.. FaviFake (talk) 18:26, 20 January 2026 (UTC)[reply]
instead of remaining open for over half a year – I remember when merge proposals were never "closed" in the sense of an uninvolved editor telling everyone else what the discussion's consensus was. Either you removed the tags or you did the merge. And they could stay "open" for years, if everyone agreed that the pages should be merged but nobody wanted to do the work. The fact that Category:Articles currently being merged from April 2023 is the oldest cat with articles we've agreed to merge but haven't yet done the work to merge is IMO a testament to the diligence and perseverance of the Wikipedia:Proposed article mergers editors.
This would absolutely reduce the proposed merge backlog because discussions would actually get closed instead of remaining open for over half a year.
@Voorts I'm not sure I understand the logic here. It is still unclear to me how this would resolve the problem any better than more editors simply interacting with WP:PAM; discussions would "actually get closed" if people just went in right now and started closing them. There are clearly a lot of interested folks in this discussion, and yet almost all of them are not participating whatsoever in clearing the backlog. If it is seen as such an issue, action can be taken immediately, rather than waiting for this discussion to play out; in many ways, I see this as a procrastination of fixing the underlying problem.
I fear that the proposed changes here would only turn the current process into a more unnecessarily bureaucratic one, locking it behind more administrative walls, and make people feel like it is an even less accessible process than it currently is. The bar for AfD is much higher than PAM. ~ oklopfer (💬) 15:48, 22 January 2026 (UTC)[reply]
I think it more likely that the merge nominator will complete a merge if the discussion ends in a reasonable time frame because the discussion will still be fresh. If I have to wait over a year for a closure, I will have forgotten about the proposed merge, probably forgotten what I intend to merge, and I would thus be less likely to enact the merge when it's closed (and that's assuming I actually know the discussion is closed at that point).
Regarding your point that more people should just participate at PAM: as I think is clear from this discussion, nobody wants to devote time to a process they view as basically moribund, particularly given the empirical data provided here by GLL and others that AfD is more than capable of handling merges and handles them at a higher rate than PAM. voorts (talk/contributions) 16:11, 22 January 2026 (UTC)[reply]
I think it more likely that the merge nominator will complete a merge if the discussion ends in a reasonable time frame because the discussion will still be fresh. What if we asked/suggested (maybe not required) that merge nominators draft the merged article or otherwise specify what sections can be deleted and what is worth saving and link to it in the nomination. That way the work is largely already done. I think that might also encourage more WP:Bold mergers. It won't impact what TAs do, but if we included it in the WP:Merge guidelines it could make actually completing mergers easier. ScrubbedFalcon (talk) 16:30, 22 January 2026 (UTC)[reply]
draft the merged article — Wouldn't a bold merge accomplish this just as well? If it is reverted, and discussion is in support of the merge, it can just be restored. Revolving Doormat (talk) 16:34, 22 January 2026 (UTC)[reply]
I think we're missing the point here. This proposal is designed to get more participation in merge discussions and to get closes to occur in a reasonable time. This proposal is not designed to address the backlog. I think the backlog is a red herring. But, even if the backlog is your concern, my point is that I believe this would help. voorts (talk/contributions) 16:36, 22 January 2026 (UTC)[reply]
Those are two sides to the same coin IMO. The backlog is a backlog of merge discussions which have not been closed and/or have little participation. Addressing the backlog is simply addressing the open discussions. ~ oklopfer (💬) 16:52, 22 January 2026 (UTC)[reply]
They're separate issues. One backlog can be prospectively fixed by switching to AfD. The other isn't affected by any of these proposals and there's nothing stopping anyone from suggesting a solution. The opposition to this proposal because it doesn't solve a separate issue is frankly bizarre IMO. We don't need to solve every problem at once. voorts (talk/contributions) 17:05, 22 January 2026 (UTC)[reply]
Maybe we are talking past each other, as it is still not clear to me what makes these separate issues.
My understanding is that:
We agree that there is a lack of engagement with participation in and closing of discussions
Your proposal is to move this process to AfD in order to solicit participation in and closing of discussions
But I do not understand fundamentally, what is the difference between soliciting engagement on AfD versus soliciting engagement on the current process? Why can it not simply be addressed right now, in its current state? ~ oklopfer (💬) 17:48, 22 January 2026 (UTC)[reply]
The fundamental difference is that there's no need to solicit participation at AfD because a ton of editors follow the AfD categories and sorting lists. How would you improve participation in a process that much of the community has already written off as frustratingly slow and ineffective? voorts (talk/contributions) 17:58, 22 January 2026 (UTC)[reply]
What makes moving the process to AfD any less frustratingly slow and ineffective? Is it not just the same process but on a different noticeboard, and possibly now requiring further admin involvement? ~ oklopfer (💬) 18:45, 22 January 2026 (UTC)[reply]
AfD discussions are closed within a month at the outer limit, and that's only after three relisting (which is rare). Most AfDs also get at least one or two comments from editors other than the nom, unlike discussions listed at PAM. voorts (talk/contributions) 18:51, 22 January 2026 (UTC)[reply]
So is the presumption that it won't be written off because there will be a more rigid time window for discussions to be open? And if so, why can we not just implement that into the current PAM process? ~ oklopfer (💬) 19:01, 22 January 2026 (UTC)[reply]
There's no deadline on AfD discussions. They generally get closed within a week because there are admins and other editors who staff AfD and make sure discussions are timely closed. What is your proposal to get people to participate in PAM other than hoping that they will? voorts (talk/contributions) 19:07, 22 January 2026 (UTC)[reply]
We can:
1. link more prominently to PAM in other noticeboards
2. move Mergers to a more appropriate section in {{Wikipedia community}}, where it is grouped with more similarly related topics (perhaps with a renaming of the Deletion discussions row)
3. ask those same frequently active admins/editors in AfD to lend a helping hand at PAM, since there is an apparent presumption that they would be willing to engage with merge discussions in the first place
Listing things on other noticeboards will not change anything. You can ask more people to staff PAM, but I think it's clear from this discussion that very few people want to do that when, as the empirical evidence pretty clearly shows, most people go to AfD for mergers in practice. voorts (talk/contributions) 19:40, 22 January 2026 (UTC)[reply]
most people go to AfD for mergers in practice again, where is this stat coming from? If this were true, why is the backlog for pending AfD merges multiple times smaller that that of PAM? FaviFake (talk) 16:44, 23 January 2026 (UTC)[reply]
Keep and merge voters in AfD are probably far more invested in ensuring content is not deleted from the encyclopedia than editors who simply attend to PAM. A concern that has been cited here multiple times is that combining this process is a bad idea because PAM isn't meant to determine that content should be deleted. So if a merge discussion in PAM is determined that it should be merged because it's not notable, a duplicate, or a bad fork (the same reasons merges are decided in AfD), what incentive is there to carry out the merge from those who voted against it?
In my opinion, putting deletion on the table for voters is exactly what is needed to address the issues described in PAM, including content that perhaps should be deleted anyway, even if that wasn't the intent of the nominator. Revolving Doormat (talk) 17:53, 23 January 2026 (UTC)[reply]
Yes, this is natural, because merges are for more tailored and related to the specific details of an article than a binary yes/no test of should we have an article, which is the typical fare with AfD. With a merge discussion you have to discuss the content, where it should be merged, which even now when voted on at AfD are often not thought through whatsoever (which is why they hoist it off on whoever has to perform it months later). AfD discussions you have a WEEK, which is often not enough to hash out merges. WP:PAGEDECIDE is completely independent of notability and I fear this would neglect it one way or the other, either preventing justified mergers because the topic is notable, or keeping non-notable topics because of it, by blending the AfD and merge processes.
I'm sure they have but there are plenty of ones I have worked with where there is substantial topic overlap and the topic is 100% notable but best covered somewhere else. Maybe if we turned it into a whole other kind of thing this would be acceptable, but expanding deletion discussions to have as part of its focus merges without a plan will be a nightmare. PARAKANYAA (talk) 18:51, 19 January 2026 (UTC)[reply]
It wouldn't be expanding deletion discussions; the merge would mean that the two processes are combined, so now you'd have both types of discussions at one venue. Maybe that would require extending the length of discussions where the proposal is merge. It may also require some tweaks to the wording at WP:AFD. I think if there's consensus for this change, those details could be worked out. But I don't think it makes sense to overhaul the process up front if there's no consensus for it. voorts (talk/contributions) 18:53, 19 January 2026 (UTC)[reply]
That would be expanding deletion discussions, it is expanding the content of what we cover at articles for deletion to non-notability mergers. But maybe that's quibbling.
The status quo is better than having an uncertain result where in theory it could be somewhat better, but just as easily could make merges far more annoying, forever. I believe most of the ways this could go are worse than the status quo. PARAKANYAA (talk) 18:58, 19 January 2026 (UTC)[reply]
Overall, this is something that I could support (apparently I even started that RFCBEFORE). But we would need a solid plan. My main concern is that WP:PAGEDECIDE is a big part of mergers. It's not given much weight at AfD where bare notability is considered not only enough to keep, but to necessitate a separate article, which kind of defeats the purpose of a merge discussion. Thebiguglyalien (talk) 🛸18:46, 19 January 2026 (UTC)[reply]
If this change is approved, it would be easy to tweak the AfD guidelines. I've also noticed that we're disentangling notability and PAGEDECIDE a bit as a community now, which is a good thing. See the recent change to WP:NSONG, for example. voorts (talk/contributions) 18:51, 19 January 2026 (UTC)[reply]
That's because many editors (in my opinion rightfully) see merge discussions as out of the scope of AfD and as a regular part of editing, rather than the correct outcome of an AfD discussion. Katzrockso (talk) 22:09, 19 January 2026 (UTC)[reply]
see merge discussions as out of the scope of AfD People are allowed to have their preferences, but that's just not true under our current deletion policy. See WP:ATD-M. Merging is and has been an option on the table at AfD for a very long time. voorts (talk/contributions) 22:12, 19 January 2026 (UTC)[reply]
Yes, but I think most editors believe that if the nom's goal is merging, then the nom shouldn't be using AFD. I also think that most editors believe that if the nom doesn't want to risk the article being deleted, then the nom shouldn't be using AFD. WhatamIdoing (talk) 20:54, 20 January 2026 (UTC)[reply]
Yes, precisely. This discussion is a good example of an uncomplicated merge discussion, albeit one with an incompetent close by a new editor. (Whoops, that was me.) The core issue there is WP:PAGEDECIDE, which can be looked at as either a "notability" issue or a "coverage/content" issue, when in fact notability issues aren't content issues. Cremastra (talk·contribs) 18:51, 19 January 2026 (UTC)[reply]
I honestly didn't think that far ahead. Perhaps if it is a simple merge, the closer or any participants can merge as usual. If it is more complicated, then there could be a timeframe or a reminder set for the proposer to complete the merge? Not sure how ghat could be set up, though. I know merging can be a daunting task for some, though it could be a collective effort if some participants are willing to. — Trailblazer101🔥 (discuss · contribs)19:31, 19 January 2026 (UTC)[reply]
We can predict that closers will refuse to do this. Some of them see it as a sort of 'conflict of interest' (they're summarizing the discussion, and someone independently enacting the result is confirmation that their summary is accepted/endorsed by at least one person). Most of them just don't want to do the extra work. WhatamIdoing (talk) 20:56, 20 January 2026 (UTC)[reply]
I have long thought that AFD should be decentralized out of project space and should take place on an article's talk page. This better alerts those who might be interested in the discussion .... @jc37: how does having it on the talk page alert editors better than a big old template on the top of the article that links directly to the AFD discussion? Also, having it on the article talk page would mean the entire discussion gets deleted if the article is deleted, leaving no record of why the article was deleted. voorts (talk/contributions) 19:41, 19 January 2026 (UTC)[reply]
I didn't say remove the template, nor any of the rest of the notification infrastructure. All that needs modifying is the target. Instead of targeting a subpage of AFD, we target the article talk page. qed.
And we'd just stop deleting talkpages of deleted pages. This is a place we're often shooting ourselves in the foot. Removing from view (all that "deletion" does) previously talked about issues with an article causes us to continually re-discuss/invent the wheel, and is a huge waste of volunteer time. There's no reason to arbitrarily delete article talk pages. If there's a good reason, like vandalism or outing, or whatever, sure, but even those can be handled without full deletion these days. - jc3719:54, 19 January 2026 (UTC)[reply]
If the idea is to keep all the infrastructure and move everything to the talk page, I don't think this proposal conflicts with yours. All it would do is combine the two processes of PAM and AfD so that the latter now has the same sorting, notification, and closure infrastructure as the latter. This would make PAM discussions more visible, get more editors involved in them, and ensure discussions are closed closer in time to their opening. voorts (talk/contributions) 20:19, 19 January 2026 (UTC)[reply]
My (strong) opposition is concerning merging to that venue. The process is immaterial if we don't get past that. Though, I think it's being shown that AFD doesn't handle well what merging it already handles. I don't think we should add more to that failing/failed process. I think there are ways to improve how we merge (and split) on Wikipedia. Feel free to ping me if someone starts a brainstorming discussion about this elsewhere. - jc3720:56, 19 January 2026 (UTC)[reply]
Perhaps I'm missing something (and I have no idea what the policies, or enforcements thereof, consist of on that wiki), but that looks like the typical nonsense one might see in a contentious RFC, and a heck of a lot more contributors than I see at the average AFD these days. I presume that the things that happened there can be addressed using our community norms. - jc3702:17, 21 January 2026 (UTC)[reply]
@FaviFake: RE the backlog issue, I don't think this would make the backlog any worse. It would just shift it from one holding area (WP:PAM / the various merge categories) to another one (the AFD closed as merge category, which could easily be divided into month subcats as well). If anything, it would make the backlog issue better by getting more eyes and more editors potentially interested in doing the merge.Also, given the large backlogs at PAM and AfDs needing merges, maybe we should organize a merge-a-thon to get the backlog down. voorts (talk/contributions) 20:21, 19 January 2026 (UTC)[reply]
I don't understand the "sky is falling" attitude I'm seeing here. The project has been making steady progress over the years, per Wikipedia:WikiProject Merge#Milestones:
16,000 to be merged: March 2, 2012
15,000 to be merged: May 7, 2012
14,000 to be merged: June 16, 2012
11,500 to be merged: January 9, 2014
12,400 to be merged: November 26, 2015
9,600 to be merged: December 12, 2016
5,861 to be merged: July 1, 2018
4,626 to be merged: October 7, 2018
3,000 to be merged: May 2, 2020
2,000 to be merged: December 1, 2022
900 to be merged: January 3, 2026
I'm hesitant to vote for a major reshuffling in an attempt to "fix" a process which is working better than ever. More incremental tweaks, sure. Every once in a while I enhance the bot's code. I've been busy with other things, so that hasn't been a high priority for me.
The backlog of proposed merges has been reduced more recently by shuffling open items off to "Articles currently being merged" categories, the oldest currently being Category:Articles currently being merged from April 2023. Hey! Sorry, no, those articles are definitely notcurrently being merged. If they were, I would be able to easily identify the specific editor who was currently working on that. I think we can solve that by just putting an expiration date on it. As with draft space, anything which has been currently being merged for over 6 months should simply be removed from the category. I'm certainly not going to attempt to merge Non-relativistic gravitational fields with Parameterized post-Newtonian formalism, as I don't have a physics degree. Compare this backlog with Articles needing cleanup, which has stuff that's over 15 years old! Why not discuss Articles needing cleanup at "Articles for discussion" too? – wbm1058 (talk) 04:14, 22 January 2026 (UTC)[reply]
The reshuffle is not intended to fix the backlog and it blinkers reality to say PAM is working better than ever. This proposal is intended to fix the problems that merge proposals rarely have participants beyond the nom and discussions remaining open for inordinate amounts of time. I apparently started one in September 2024 that still hasn't been closed and only just got a comment beyond myself and the article creator, and that's only because I posted a link to my log of PAM discussions in this discussion.
Why not discuss Articles needing cleanup at "Articles for discussion" too? Because this proposal is to merge one formal process (PAM) into another. Nothing about this proposal affects bold merges by individual editors or smaller groups. The only thing that would change is that if those merges are contested, instead of going to PAM for consensus, they'd go to AfD. voorts (talk/contributions) 14:09, 22 January 2026 (UTC)[reply]
PAM is not really a formal process. PAM is just a list of links to merge discussions that is automatically updated by a bot. So if AfD replaces PAM for contested merges, would any talk page discussion stating "I propose merging X into Y. My merge was contested." be speedily closed with the instruction "go to AfD"? SuperPianoMan9167 (talk) 14:54, 22 January 2026 (UTC)[reply]
Proposed mergers are formal discussions though. There's a tag that goes on both articles, instructions for how to open and close discussions, etc. Regarding the talk page scenario, no. See my hypotheticals in the discussion above. voorts (talk/contributions) 15:11, 22 January 2026 (UTC)[reply]
For most of this project's life, these were not formal, structured, 2-step procedures. The advent of closure without merging but rather moving to category "currently being merged" is recent. Imagine someone closing requested moves as "consenus to move" and then rather than actually moving the page, putting it in "category: pages currently moving". They'd get trouts for that, and if they persisted, would be subject to blocks and bans. But now at merges, it's somehow become normal, standard practice. We don't have a separate template equivalent to {{Proposed deletion}}. It's just one template for everything, because, until very recently, it was not such a formal process. I'm not sure making it a formal process was an improvement. – wbm1058 (talk) 20:00, 22 January 2026 (UTC)[reply]
just a list of links to [...] discussions that is automatically updated by a bot What you're describing is also how AfD works, to an extent ㅤ :) FaviFake (talk) 16:47, 23 January 2026 (UTC)[reply]
As with draft space, anything which has been currently being merged for over 6 months should simply be removed from the category. None of these are currently being merged, obviously. The name is ancient and no longer reflects what the tag is used for. That's the category for merge discussions which have been closed with consensus to merge. Removing them is virtually equivalent to bypassing the closure review process.Anyone up for creating a TfC? Category:Articles slated for merging? FaviFake (talk) 16:52, 23 January 2026 (UTC)[reply]
Transcluding the discussion from the talk pages into a centralized page that's more easily monitored – OK, OK. This wasn't really practical when there were ~14,000 open requests, but it might be now, as Wikipedia:Proposed article mergers seems to be a manageable size page. I'll look into it. Keep in mind, editors placing these templates are not even formally required to start a discussion, so, for some of these, there is no discussion to be transcluded. And, someone who disagrees with the proposal is free to simply revert the addition of the template, you know – bold, revert, discuss – starting a discussion is only required to avoid edit-warring over the placement of the merge template. – wbm1058 (talk) 20:00, 22 January 2026 (UTC)[reply]
Keep in mind, editors placing these templates are not even formally required to start a discussion, so, for some of these, there is no discussion to be transcluded. Yes I agree. A lot of merges should be uncontroversial. The issue is that some people start proposed merger discussions anyways instead of boldly merging. Under the current system, when that happens, the discussion remains unclosed for several months. Moving this over to AfD would ensure closes occur in a timely manner.
someone who disagrees with the proposal is free to simply revert the addition of the template, you know – bold, revert, discuss – starting a discussion is only required to avoid edit-warring over the placement of the merge template. Also correct in part. Anyone can revert a bold merge if they object. But discussion is not required to prevent edit-warring over the template; it's required if the merging editor wants to obtain consensus for the merge. voorts (talk/contributions) 20:23, 22 January 2026 (UTC)[reply]
Comment: Within just 4 days of the start of this RfC, the total number of articles proposed for merging went from the usual 920 to just over 680, and is continuing to decline. To me, this seems to indicate that the size of the PAM backlog is heavily reliant on editor interest. Besides proposing changes to PAM every couple of years for more than a decade, are there any other effective ways to "advertise" the process to consistently draw enough people into it? FaviFake (talk) 22:36, 23 January 2026 (UTC)[reply]
Perhaps what we need isn't to combine the processes, but to use similar infrastructure. I find myself wishing I could sort current merge discussions by date or by topic. Thebiguglyalien (talk) 🛸02:53, 25 January 2026 (UTC)[reply]
I have participated in and carried out many mergers over the years. Nearly all of these were the result of a talk page discussion or RfC. I have never used the 'proposed merger' process, which I agree has long been moribund. As mergers of the kind we are discussing here are fundamentally a matter of content, rather than notability, directing editors to conduct merger discussions through the RfC process seems like one solution to the problem of minimal participation. The RfC process allows for more deliberation than the AfD process, and triggers automatic notification of a wide breadth of editors. It also has the benefit of keeping discussion of content matters on the article talk page, where it belongs. Yours, &c.RGloucester — ☎03:57, 25 January 2026 (UTC)[reply]
I'd be happy to help with merging; as a long-time AfD person I've always felt sorry for whoever enacts a Merge outcome, but I had no idea normal mortals were allowed to do merge-work, or how to go about it. So yes, it needs advertising. Elemimele (talk) 17:20, 27 January 2026 (UTC)[reply]
Not at all. I get notifications for any comment from anyone on this page since I've commented on it... My question was in good faith and not meant as a troll.. Iljhgtn (they/them · talk) 17:01, 28 January 2026 (UTC)[reply]
I assume you mean "what if the nominator's preferred outcome would be a redirect without a merge", i.e. WP:BLAR, because there's no content worth merging but the redirect might be useful. Redirect is a common ATD, but currently AfD is supposed to be used only if the proposed outcome is delete. I'd say that if the RfC consensus is to move merge discussions to AfD, then a proposed outcome of redirect ought to be allowed too. Rosbif73 (talk) 10:49, 29 January 2026 (UTC)[reply]
When If this proposal passes, the question remains whether and how we rename WP:Articles for deletion. It might be useful to get a headstart on this matter now.
I say we could not move the ocean of nomination subpages and have WP:Articles for deletion redirect to the new page, to a section noting how AfD used to include only deletion but now includes mergers as well. (Under this, we could titleblacklist subpages under "WP:Articles for deletion/" if needed to prevent accidental creation by users and gadgets. Or just make another bot that automatically moves new creations?)
Of course, the prowess of our bots is not to be underestimated. We did recently remove all occurrences of {{pageviews}}. So whatever name we find we could also just rename all the subpages wholesale.
As for the actual name, I throw into the ring "Articles for disposition" to preserve our holy acronyms we just had an alphabet soup war over, and "Articles for deletion or merger" to keep it simple and understandable. Aaron Liu (talk) 00:47, 20 January 2026 (UTC)[reply]
I agree with "for Discusssion". I am neutral to against renaming past deletion discussions because they will have been deletion discussions even if the process was later changed. Jclemens (talk) 05:19, 20 January 2026 (UTC)[reply]
I think there are links to other discussions about the rename in WP:PERENNIAL. The only two options that were seriously considered were the current name and Articles for discussion. Thus i find it very unlikely that a different spelling will prevail. FaviFake (talk) 20:27, 20 January 2026 (UTC)[reply]
Could we consider "disposition"? I mentioned above that the perennial proposal is only about and would imply including requested moves as well, which we are not doing. Aaron Liu (talk) 00:10, 21 January 2026 (UTC)[reply]
This precisely highlights why AfD is not comparable to the other forums for discussion, as they exist to centralize discussion about a non-article part of Wikipedia (template, redirect, etc), when "discussion" about articles already has a centralized location: the talk page. RMs and PMs take place on the talk page for good reason. Katzrockso (talk) 21:23, 21 January 2026 (UTC)[reply]
Because merges are generally ordinary content issues since merges can be performed and reversed by any editor, unlike deletion, which can only be performed and reversed by admins. SuperPianoMan9167 (talk) 14:57, 22 January 2026 (UTC)[reply]
Rename to Articles for discussion, somewhat regardless of how the to and fro goes above, this is the neutral title for such a venue (with or without expansion to include merge discusssions or not). AfD is not Article for deletion, it's instead Articles for discussing deletion, with a shorthand that makes it inconsistent with other venues (as other have already pointed out). Given it'd be the same shortcut, if this discussion doesn't solve it, an RM might. CNC (talk) 23:45, 21 January 2026 (UTC)[reply]
Articles for discussion is the only AfD rename proposal with broad support in the first place, so might as well go with that, now that this rationale would change in its favour. Dege31 (talk) 16:31, 22 January 2026 (UTC)[reply]
Keep articles for deletion (regardless of whether the above proposal about merges passes). Wow, the times they are a changin'. This proposal is on Wikipedia:Perennial proposals#Rename AFD, which is the list of ideas that were once proposed so frequently that we needed a page to explain why we kept rejecting them. I personally don't like the name "articles for discussion" because of how ambiguous and overloaded the term "discussion" is. If I am a new editor seeing the term "articles for discussion", I feel like I would assume that's a place where maybe you could escalate a content dispute. The word "deletion" makes it clear that the discussion is about the suitability of the article as a standalone topic. Mz7 (talk) 20:42, 22 January 2026 (UTC)[reply]
True. However, the "mergers... should be discussed on the talk page or at the separate merge... forums" stipulation will not apply if the main proposal passes, so it's worth taking a fresh look. Dege31 (talk) 21:07, 22 January 2026 (UTC)[reply]
Already the status quo allows nominators to advocate directly for a redirect at AfD instead of pure deletion (see Wikipedia talk:Speedy keep/Archive 4#Should we permit deletion nominations advocating for a redirect?), and when we made the decision to allow that, we did not then change the name to "articles for discussion" or "articles for deletion or redirection" or anything like that. Similarly, if we allow merging at AfD, I feel like there's no need to change the name from "articles for deletion". The word "deletion" makes it clear to onlookers that the purpose of the discussion is to determine whether a standalone article should not exist for the given topic. The word "discussion" is too nebulous. Mz7 (talk) 23:19, 22 January 2026 (UTC)[reply]
My first thought was Articles for Discussion. As for past AFDs, just leave them. Absolutely no need to change those. It would be a massive waste of resources. ← Metallurgist (talk) 05:16, 23 January 2026 (UTC)[reply]
Rename to Articles for discussion or Articles for alternative destination (AfD or AfaD) if and when merge comes into play here. I think AfD changing to Articles for discussion is great though. No real hard push for my own suggestion of Articles for alternative destination. Iljhgtn (they/them · talk) 15:53, 23 January 2026 (UTC)[reply]
Oppose renaming – Unless AfD is going to serve as a venue for renaming as well, this is a ridiculous proposal. The correct venue for discussion of articles is the article talk page. AfD only exists as a separate venue because of the specific nature of deletion as a process. I really feel like editors here are confusing notability-based mergers, which AfD has handled up until now, with content-based mergers, which have been handled on article talk pages. Yours, &c.RGloucester — ☎00:39, 25 January 2026 (UTC)[reply]
... And which will be both discussed at AfD if voorts's proposal passes. Since they are two distinct types of mergers, why do you think it shouldn't be renamed? FaviFake (talk) 07:36, 25 January 2026 (UTC)[reply]
First of all, because renaming is not within the scope of the proposed 'Articles for Discussion'. My understanding of voorts proposal is that it would not preclude merging through existing alternative venues – if this proposal will mean that we will no longer be able to make basic content decisions on article talk pages, then it is all the more appalling, poorly conceived and contrary to the spirit of WP:NOTBURO. Yours, &c.RGloucester — ☎07:58, 25 January 2026 (UTC)[reply]
Oppose procedurally: a subsection of another RfC is not an appropriate place to make this major WP:PEREN proposal. At any rate, I'm not a fan of the change to begin with; while obviously there's no way to be perfectly precise about AfD's scope in three words, I think the title should give people fair notice that deletion is on the table—"articles for discussion" just sounds like a nice place to have a conversation about how the article can be improved. Extraordinary Writ (talk) 19:30, 28 January 2026 (UTC)[reply]
a subsection of another RfC is not an appropriate place to make this major WP:PEREN proposal The major perennial proposal is the RfC itself, not just this subsection. See WP:PEREN (emphasis supplied):
Change the name of WP:AFD from "Articles for deletion" to "Articles for discussion" in order to seem less confrontational and/or to match some other forums such as Redirects for discussion. This usually assumes that Wikipedia:Proposed mergers and Wikipedia:Requested moveswould be merged into AFD, as the equivalent processes are at the XFD "for discussion" pages.
Opppose Its a time honoured name and process, well understand by everybody who spends real time there. Folk who left and come back and will be hobbled and won't take it up. Seems to be rather trivial and absurd motion with no real benefit to any editor as far as I see. What will happen is it drive away the regulars which will truly break it. Long term constistency resulting well understood process that work is what made Wikipedia successful in the first place. That is why there is so much concern over changing the name, never mind the fact that your going try bolt on something that has nothing to with deletion discussion. The only concomitant linking mechanism is the "merge" keyword. There is no commanality between a deletion discussion and merge. One examine references, the other is an outcome. One is a process, the other is an outcome. I can't understand why this is even raised, for such well understood process that is almost a tradition. It will truly knacker it. scope_creepTalk16:16, 1 February 2026 (UTC)[reply]
AfD can also find consensus to split off a sub article (can't think of any examples), but, typically, AfC, despite going hand in hand with AfD, does not take place at AfD; splitting is more analagous to AfC from my POV. GreenLipstickLesbian💌🧸01:56, 21 January 2026 (UTC)[reply]
The split process is identical and has identical issues as the merge process. I thought it was obvious that this would include splits as well but apparently it wasn't mentioned by the nom! I support syncing the two processes, whatever the result. FaviFake (talk) 16:46, 21 January 2026 (UTC)[reply]
While true, this only works with the "split first ask questions later" approach, rather than opening a discussion. Opening a discussion means waiting 3-12 months, which is shooting yourself in the foot if you want to split in the near future. The issue with merging is that few appreciate blank and redirect as a tactic. That said I'm not a fan of the split process either, for the same reason as the neglect of merge discussions and never-ending timeframes. CNC (talk) 23:41, 21 January 2026 (UTC)[reply]
If we started Wikipedia today, from scratch, without knowledge of what has happened before, would we still think its a good idea to have more than one central place to discuss articles? In the real world, as a customer, you wouldn't want to have to try and find where to complain about my bill or the goods hadn't arrived in different locations. You would want one place to raise those issues, not having to go to different locations on a website. The problem we have is, like much of Wikipedia, is that bits have been added over time because, 1. They were not thought of at the time, 2. Because most can't agree on a way forward. If we had one location to discuss articles, be it for deletion, merge or split would that not be easier to manage and view, and at a chance more likely to have more community involvement?Davidstewartharvey (talk) 23:51, 22 January 2026 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Merges are slow to be done because sometimes they are one of the more pain-in-the-ass things to do because they often involve painstakingly removing duplicative content from both articles to be merged and finding the right spot in the target article for every line or item to be merged from the article to be merged. I think this is exactly the kind of task that would be the best use case for an AI on Wikipedia. Since it is just integrating two existing sets of information, the AI would not be writing any new material itself, and no hallucinations should be introduced (or, at least, anything new introduced should be very easy to spot). Perhaps we could set things up so that an AI creates a proposed merge subpage, and an admin can review and accept that or improve it from there. BD2412T01:07, 20 January 2026 (UTC)[reply]
Honestly I'd rather just have a more functional "articles to be merged" list on my Wikiproject Article alerts - or at least some way to sort to be merged articles by topic area. GreenLipstickLesbian💌🧸01:21, 20 January 2026 (UTC)[reply]
Hell no. LLMs cannot be trusted to edit Wikipedia. They hallucinate. They invent imaginary sources. They invent imaginary Wikipedia policies. And they write like crap. Frankly, given all this, it would be bizarre to even contemplate using them in this context. If a merger needs doing, it needs doing properly. By someone with the competence to do so. AndyTheGrump (talk) 01:45, 20 January 2026 (UTC)[reply]
Editors (including admins) can already do this on their own, ask an AI and review it themselves.I don't think we should be pushing it further than that. Aaron Liu (talk) 04:08, 20 January 2026 (UTC)[reply]
I'd take a tool that dumped the code of one article into the bottom of the second one, enclosing it in hidden html tags. If this is done then the same tool could automatically do the very annoying merge tagging, using the diff it creates when dumping the code. That handles attribution and puts everything together, then the editor can focus purely on the actual merging of content. CMD (talk) 07:14, 20 January 2026 (UTC)[reply]
If the AI could do this without adding any new text or sources, and the result was still validated by an editor before it was published then maybe it could be useful. However I fear any current LLM isn't able to do this and would just create something new using the two articles as a basis, which wouldn't be acceptable due to all the known failings of LLMs. -- LCU ActivelyDisinterested«@» °∆t°18:56, 20 January 2026 (UTC)[reply]
Strong Oppose. AI as it stands right now has some serious flaws and so carrying out a complex task like merging in my view would inevitably lead to issues. GothicGolem29(Talk)00:05, 21 January 2026 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
After looking few several active merge discussions it does look to me like there's a big difference between the "this article is not notable, but it should be merged into another article" with "these two articles seem to be on the same thing, should we merge them?" In short, notability merges versus content merges. I also admit this is not a perfect distinction. I don't believe AfD is the correct place for the content mergers and I believe strongly about that, but I believe it could absolutely handle the notability mergers. So why not keep the processes separate, but allow someone to bring a merge to AfD with the understanding that at AfD, consensus could decide the page could still be deleted without a merge taking place? I also think this would be the easiest update to our policies - at Wikipedia:Merging we could separate the insufficient notability part, and at Wikipedia:Articles for deletion we could just say that it's the appropriate place to discuss merging articles with notability concerns, with the caveat that the discussion could end in delete instead of merge. SportingFlyerT·C14:29, 21 January 2026 (UTC)[reply]
So why are people proposing uncontroversial merges? Seems like the backlog would go way down if the instructions said don't do that and only open a discussion if someone contests your merge. That would also solve the problem of needing to figure out what should be merged since there'd be a diff showing what was merged. voorts (talk/contributions) 17:18, 21 January 2026 (UTC)[reply]
They're new.
They're not sure it's uncontroversial.
They don't have the time.
They don't think it's good practice.
They don’t wanna perform it, they want it to be done. Requiring people to perform a merge if they want to suggest will just result in some people not doing it at all, which will leave more article unchecked and lead to worse articles.
Proposals happen because people are afraid to be bold and campers get uptight about things. I like to say it never hurts to get consensus. I proposed merging Shimon Dzigan and Israel Schumacher into Dzigan and Schumacher a few months ago, no one replied, so I ended up just doing it. The two are technically notable enough to be separate, but pretty much every source mentioned them together, so it was silly to have separate articles. ← Metallurgist (talk) 05:22, 23 January 2026 (UTC)[reply]
I don't think it's advisable or implementable to judge whether to procedurally close a nomination based on whether it is a notability merge or a content merge (or as I prefer to call them, an WP:AltToDel merge or a WP:PageDecide merge). Barring that, this is similar to a proposal I've made (and thus supported) above, which I've now moved to this subsection: (see text below) Aaron Liu (talk) 23:59, 21 January 2026 (UTC)[reply]
Also per Choucas: PropArtMerg has initiative to merge and lacks community participation, and AfD discussions that end in merging have community participation (a sufficient amount, anyways) and lack initiative to merge. By allowing PropArtMerges into AfD, we give the nominations that do have the willing-implementers the attention that they need and deserve. This does not solve nor affect the problem of lack of initiative to implement merging articles that were nominated to delete, but that is not an issue with the proposal whose main goal is to solve the other problem.To address the concern of one of these problem areas affecting three other if the proposal is implemented, what would we think about a counterproposal to simply allow nominations for merger within AfD, instead of forcing all PAMs to merge into this process? This would continue to support the idea of quick merger proposals many opposers brought up, while allowing those who do want to enjoy AfD's 7-day-attention to make their choice of venue. Aaron Liu (talk) 19:30, 20 January 2026 (UTC)[reply]
I'm not sure I understand what you mean by PropArtMerge, but my proposal is essentially exactly what you suggest - explicitly allow someone to bring an article to AfD and suggest a merge in the nomination. However, it would still be AfD, the main issue would be the notability of the article that is suggested to be merged into another article, and the discussion could close as delete instead of merge. I'm not suggesting anything needs to be procedurally closed as a result of this. SportingFlyerT·C21:12, 22 January 2026 (UTC)[reply]
Done – see the new Wikipedia:Proposed article mergers – wbm1058 (talk) 20:13, 27 January 2026 (UTC)
Comment: Within just 4 days of the start of this RfC, the total number of articles proposed for merging went from the usual 920 to just over 680, and is continuing to decline. To me, this seems to indicate that the size of the PAM backlog is heavily reliant on editor interest. Besides proposing changes to PAM every couple of years for more than a decade, are there any other effective ways to "advertise" the process to consistently draw enough people into it? FaviFake (talk) 22:36, 23 January 2026 (UTC)