Wikipedia talk:Merging

When to use {{Merging}}

Seeing as many approved page mergers don't get completed, explicitly incorporating the {{Merging}} tag into the process would signal to other users that they can help merge the articles. Where in the process should this step be added? In my opinion, editors should immediately slap {{Merging}} onto a page in step 4 unless they plan to finish the merger themselves. Qzekrom (talk) 16:14, 17 February 2019 (UTC)

The problem with adding the merging template is that it suggests that someone else is dealing with the completition of the merge, so it might actually dissuade engagement. My view is that it is better to keep the proposal templates in place until the merge is completed, and that this is just as likely to engage interested participants. The other issues is that it lists the page in Category:Items to be merged, which at present seems to contain non-article space pages. So, perhaps it is better to keep that template for such non-article space pages. Klbrain (talk) 17:02, 17 February 2019 (UTC)

What if we added "You can help" to the {{Merging}} template? Qzekrom (talk) 23:05, 17 February 2019 (UTC)

Yes; that might work. Would be fine with me (also, retracted one of points above - must have been drinking some simple organic compound). Klbrain (talk) 20:12, 18 February 2019 (UTC)

In my opinion, maybe I'm in the minority here, but people shouldn't close merger discussions unless they also plan to actually complete the merger. Otherwise, there is no need to determine consensus yet and the discussion should remain open until someone else decides there is consensus and they're prepared to complete the merge. And, use of the {{Merging}} template should be used to signal to other editors that someone is in the process of completing a complicated merger and that it would be helpful to not have competing edits, and content edits should wait until the merger is completed (signaled by removal of the {{Merging}} template). I just don't see how it would be possible to beneficially have multiple editors completing a merger - too many cooks in the kitchen. Ideally a merge itself is two edits, blanking/redirecting of the source page and content added to the target page, followed by inevitable cleanup of the target page after the merge itself, in which all editors can participate. Mdewman6 (talk) 23:58, 11 September 2020 (UTC)

Proposed merger of two article to a not-yet-existent page

It's been a while since I've done this, so looking for advice on how to tag articles that are subject to a merge discussion where the proposed destination is a page that does not yet exist. (In this case, a possible merger of Michael Spavor and Michael Kovrig into Detention of Michael Spavor and Michael Kovrig or similar. Any help is appreciated. TheBlueCanoe 23:27, 4 July 2020 (UTC)

Use {{merge|Michael Spavor|target=Detention of Michael Spavor and Michael Kovrig|discuss=Talk:Michael Kovrig}} on the Michael Kovrig page and {{merge|Michael Kovrig|target=Detention of Michael Spavor and Michael Kovrig|discuss=Talk:Michael Kovrig}} or similar on the Michael Spavor page. You could use either of the talk pages for the discussion, as long as the merge templates both point to it. Klbrain (talk) 12:54, 5 July 2020 (UTC)

Thank you!TheBlueCanoe 14:15, 27 July 2020 (UTC)

The directions described above indeed work, whereas the ones actually described here at the project page did not. I updated and expanded the directions based on Klbrain's guidance here. I think I did it right. Mdewman6 (talk) 01:29, 1 December 2020 (UTC)

Those changes to the page look fine to me; thanks. Klbrain (talk) 08:48, 2 December 2020 (UTC)

Request for comment: Proposed blank and redirects - closed

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Should there be procedures for proposing potentially controversial blank and redirects that are analogous to those for proposing page merges? Mdewman6 (talk) 18:24, 12 September 2020 (UTC)

The merging policy outlined here offers a thoroughly described and logical procedure for proposing to merge a page's content into another page, allowing editors to tag the pages to notify others involved with the affected pages (via templates) of their intentions and ensure consensus before the discussion is closed and the pages are merged, often by the same editor. However, in many cases, little content is actually merged into the target page, usually because the content of the source page is either already present in the target page (content fork) or does not fit into the target page; thus in these cases the merge is really a blank and redirect. Nevertheless, there are no analogous procedures for proposing to blank and redirect a page to ensure consensus to do so; the only choices are to be bold, attempt an informal discussion on the talk page without the benefit of tagging the page via an appropriate template to notify other editors, or propose the article for deletion. Given this, many merger proposal discussions are conducted under the merge policy even though the ultimate intention is a blank and redirect, and such edits and resulting redirects are tagged as being the result of a merge, according to the procedures described here, even though little to no content was actually merged.

Therefore, I propose that procedures for proposals to blank and redirect pages be developed analogous to those for merging, including the development of templates for tagging the affected pages (analogous to Template:merge to) and a new redirect template for redirect pages that used to have article content and no content was merged into the redirect target (to use in contrast to Template:R from merge; it's possible that the existing Template:R with history would be appropriate for this purpose). These procedures could be described both here and in an expanded section at WP:BLAR with appropriate links between the two. Of course, the consensus of a blank and redirect discussion might be that some content should actually be merged, and likewise, the outcome of a merger proposal might be to blank and redirect the page. But analogous procedures for blanking and redirecting would better allow editors to describe their proposal, reach consensus, and document what was actually done in the edit history. Mdewman6 (talk) 22:40, 11 September 2020 (UTC)

@Mdewman6: what is your brief and neutral statement? At over 2,600 bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia policies and guidelines. The RfC may also not be publicised through WP:FRS until a shorter statement is provided. --Redrose64 🌹 (talk) 13:32, 12 September 2020 (UTC)

Thanks! I think I have fixed it. Mdewman6 (talk) 18:24, 12 September 2020 (UTC)

Thank you --Redrose64 🌹 (talk) 19:15, 12 September 2020 (UTC)

@Mdewman6: Are you still interested in holding this RfC? If so, I suggest that you close this one (it's clearly not going to get more comments), create a new section below with the properly-formatted RfC, and add it to CENT if necessary. Best, KevinL (aka L235 · t · c) 09:34, 2 December 2020 (UTC)

I am closing this discussion as recommended above and starting a new discussion below. Mdewman6 (talk) 22:37, 13 December 2020 (UTC)

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.

Template for project notification

I've found that when I've proposed articles to be merged, there's not a flurry of people wanting to join in on the discussion. I'm not super happy saying "well there's no discussion so that's consensus by default". So instead I've started promoting the discussion on related project pages. I've started work on a short template for this: {{merge being discussed}}. Do you think that promoting the merge discussion (not just to project pages, but to creator's user pages etc) should be a recommended part of the merge process? — Preceding unsigned comment added by Paul Carpenter (talk • contribs) 13:14, 1 October 2020 (UTC)

Some projects already automatically list merger proposals (and RMs/AFDs) on the project pages, though I don't think all do. I think it would be helpful for more projects to do so, though I have no idea how this is done. If a page is deeply related to a WikiProject and it's not automatically listed I try to post on the Talk Page linking to the discussion, which perhaps your template could assist with, though I haven't found this to be too productive in generating discussion. Personally, in general I think anyone with great interest in a page will be Watchlisting it and will voice opposition to the page being merged, and if this doesn't happen it can be taken as consensus. I don't generally support doing Bold merges without discussion, but on the other hand, I don't think we need a process akin to AFD or RM that unnecessarily involves other editors who are not involved with the particular page. What's crazy is that there is no discussion process for blank and redirects, which is what my Request for Comment is about above (and I can't even get anyone to comment on that!). Please comment! Mdewman6 (talk) 03:22, 2 October 2020 (UTC)

I can see the motivation for the proposal, but there is a bot for that! Organized projects, like Wikiproject Medicine, use AAlertBot to construct lists of proposal relevant to the project. For Wikiproject Medicine, for example, this creates a listed at Wikipedia:WikiProject Medicine/Article alerts, linked from elsewhere on the project pages, that can be used by project member to see relevant proposals. Projects that haven't set up such a system also aren't usually organized enough to have anyone respond. I've tried manually going to project talk pages to stimulate merge discussion, and my hit rate is about 1/5 for the promotion of any discussion at all (although 100% success at WikiProject Australia). I also wouldn't make merge proposals more complicated, so wouldn't add the requirement for additional notifications. We have enough problems with people only tagging one page, or not starting a discussion. Prompting those who started pages to engage in merge discussion is also not helpful, as it tends to promote unhelpful defensiveness (WP:OWNERSHIP); in this sense, page creators could be argued to have a conflict of interest in the discussion, and hence the voices independent of them are more helpful. Overall, my view is that we need more action (merging) rather than more talk (gesta non verba). In many cases, there is no discussion because the case is obvious, and if is not obvious then its probably not worth doing. So, where a merge is well-justified, obvious, with consensus, or uncontested (over a month or so), then I suggest being WP:BOLD yet ready for WP:BRD. If there is no case made, and the case isn't obvious, close without merging. Klbrain (talk) 08:49, 3 October 2020 (UTC)

More info at WP:AALERTS, you can see which WikiProjects subscribe at WP:AALERTS/LIST. --Redrose64 🌹 (talk) 18:59, 3 October 2020 (UTC)

Checking for non-free images

The instructions say this should be done but is there not a bot to do it? If not is there an easy way to check which could be explained in the instructions? Chidgk1 (talk) 18:20, 18 October 2020 (UTC)

I agree that this check of non-free images is a routine maintenance task that shouldn't be included in the merge implementation; it is a separate process than can/should take place independently before/after merges by any editor. Any objections to deleting that action? It's currently point 6 at Wikipedia:Merging#How to merge. Klbrain (talk) 11:57, 16 November 2020 (UTC)

Support removing this step from instructions. This is not something specific to merging and not necessarily the merger's responsibility, as non-free images are an issue both pre- and post-merge. Users conducting merges should focus efforts on the merge itself. Mdewman6 (talk) 23:16, 16 November 2020 (UTC)

Wait, how is this supposed to work if not part of the merge process? If the merged content contains a non-free file, this file's description will need to be updated to point to the merge target. Other the file won't have a valid rationale and may get deleted. – Uanfala (talk) 18:04, 19 November 2020 (UTC)

I see Uanfala's point. However, the non-free-content designation is primarily a matter for the image page rather than the article. A concern for the use of non-free-content might be WP:NFCCP point 8, contextual significance, but it would be a strange case where contextual significance was valid for the initial page but not for the merged page. Regarding enforcement, concerned readers can trace image history back through the merged from templates, so there is a traceable path to historic justifications should that be necessary. Furthermore, challenges to images from time to time is probably a healthy process, as it forces us to reassess whether the justification remains valid; for example, contextual significance isn't a permanent attribute and it would be reasonable to challenge it from time to time. Klbrain (talk) 21:05, 19 November 2020 (UTC)

Well, it was my impression that when a file lacks a fair-use rationale, it's more likely to get automatically deleted than see people carefully assessing its ongoing contextual significance. I'm not offering any positions here because I don't have experience – I really only have to deal with fair-use images about once a year, but one case I remember was when I performed some simple topic restructuring while omitting to update the file page, with the result that the file got deleted by one of JJMC89's bots. If that's what normally happens, then the performer of the merge is the only person who can be expected to deal with the fair-use rationale. This may seem too niche, but isn't – it's part of the statutory cleanup after page moves, and it's one of the very few things that you'll see mentioned in the little message you get after moving a page. – Uanfala (talk) 21:28, 19 November 2020 (UTC)
Also clarifying – what's at stake in the instructions is not some overall big-picture evaluation of fair use, it's the very simple act of updating the title of the article mentioned in a file's fair use rationale, and that is expected to happen whenever that article title changes – say, when the article is moved, or when it's merged. – Uanfala (talk) 21:34, 19 November 2020 (UTC)

If a merge is carried out properly, a redirect from each of the older names should be left behind. If the FUR on the file description page has a link to the article for which fair use is claimed (and it should have one, per WP:NFCCP#10c), the link can be the abovementioned redirect, which means that the FUR still links to the page where the image is used, albeit indirectly (which is allowed by WP:NOTBROKEN). --Redrose64 🌹 (talk) 09:35, 20 November 2020 (UTC)

Merging talk pages

What if the talk pages of two pages need to be merged, for example to centralize discussion, but not the subject pages? What if one or both talk pages have archives? JsfasdF252 (talk) 00:12, 16 November 2020 (UTC)

You've given several reasons why talk pages shouldn't be merged. Centralizing discussion is therefore best done by adding, onto on of the pages, "Please discuss at <link to other talk page>. Klbrain (talk) 11:53, 16 November 2020 (UTC)

I have found two examples of talk pages for biography articles which need to be merged (two talk pages for one article). In both cases, it looks like the articles had different titles between the time they were created and now.

1) Talk:Diana Pullein-Thompson and Talk:Diana Pullein-Thompson (writer); if you click on the article link attached to the talk page for the one with the writer qualifier, it redirects to the article title without the qualifier; yet there are still two talk pages.

2) Talk:Augustus Lord Soule and Talk:Augustus Soule; similar situation, though in this case, one talk page uses a fuller form of the person's name.

Also, I have a list of talk pages which redirect to different people (usually two different people) and likely need separate talk pages. If anyone can help me with those, I can send that list separately.

Any help to solve these would be appreciated. Is there a documented procedure on how to fix these talk pages? Thank you.--FeanorStar7 (talk) 08:55, 2 January 2021 (UTC)

Request for comment: Proposed blank and redirects

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is a consensus not to create a new process for this. Most users believe that AfD should be used to settle controversial or contested cases of blanking and redirecting. A minority of users argue that it's a good practice to use AfD regardless of whether the action is expected to be controversial, however a majority state that bold redirection is acceptable in such cases. (non-admin closure) (t · c) buidhe 05:24, 5 January 2021 (UTC)

---

Should there be procedures for proposing potentially controversial blank and redirects that are analogous to those for proposing page merges? Mdewman6 (talk) 23:17, 13 December 2020 (UTC)

The merging policy outlined here offers a thoroughly described and logical procedure for proposing to merge a page's content into another page, allowing editors to tag the pages to notify others involved with the affected pages (via templates) of their intentions and ensure consensus before the discussion is closed and the pages are merged, often by the same editor. However, in many cases, little content is actually merged into the target page, usually because the content of the source page is either already present in the target page (content fork) or does not neatly fit into the target page without substantial editing; thus in these cases the merge is really a blank and redirect. Nevertheless, there are no analogous procedures for proposing to blank and redirect a page to ensure consensus to do so; the only choices are to be bold, attempt an informal discussion on the talk page without the benefit of tagging the page via an appropriate template to notify other editors, propose the article for deletion, or follow the procedures here as if it were a true merge. Given this, many merger proposal discussions are conducted under the merge policy even though the ultimate intention is a blank and redirect, and such edits and resulting redirects are tagged as being the result of a merge, according to the procedures described here, even though little to no content was actually merged. While a blank and redirect is in one respect less substantial of an action than a merge because only one page is affected, in another respect, it is more substantial of an action because the result is that some content will no longer exist anywhere in the encyclopedia.

Therefore, I propose that procedures for proposals to blank and redirect pages be developed analogous to those for merging, including the development of templates for tagging the affected pages (analogous to Template:merge to and Template:merge from) and a new redirect template for redirect pages that used to have article content and no content was merged into the redirect target (to use in contrast to Template:R from merge; it's probable that the existing Template:R with history would be appropriate for this purpose). Tagging the proposed redirect target should occur because that article likely contains internal links and other content about the page to be blanked that would require editing (e.g., to remove self-redirects) and the editors of the target page are likely to have an interest in the discussion. Like a merge discussion, the outcome does not prejudice against further discussion in other appropriate venues, such as WP:AFD or WP:RFD, and the blanked page is not to be considered deleted for the purposes of any policy. (However, it should be clarified where appropriate that a combination of a blank and redirect followed by a RfD discussion is not an appropriate substitute to a discussion at AfD.) Again as with merges, blank and redirects could still occur on a bold basis, subject to reversion on a usual bold-revert-discuss cycle. These procedures could be described both here and in an expanded section at WP:BLAR with appropriate links between the two. Of course, the consensus of a blank and redirect discussion might be that some content should actually be merged, and likewise, the outcome of a merger proposal might be to blank and redirect the page. But analogous procedures for blanking and redirecting would better allow editors to describe their proposal, reach consensus, and document what was actually done in the edit history. Mdewman6 (talk) 23:20, 13 December 2020 (UTC)

Discussion

• Blank and redirect is one of the normal, common outcomes listed at Wikipedia:Articles for deletion. Why is a new process needed for something that is already handled by AFD? Are you maybe asking for the post-AFD-consensus-to-redirect instructions to be clarified? – Jonesey95 (talk) 23:53, 13 December 2020 (UTC)

  I recognize a blank and redirect is a common AfD outcome, and this proposal would not affect that. This would just provide an alternative to AfD analogous to proposed mergers for an editor that sees a page as problematic or a content fork, has a redirect in mind, and wishes to check for consensus, without needlessly involving editors not involved or interested in the page as an AfD discussion would. Besides, such an editor would not wish for the page to be deleted, as they want to redirect it, so would not nominate it for deletion at Afd. To my knowledge, nominations for a blank and redirect are not usually made at AfD, but instead a blank and redirect is suggested by those participating in the discussion as an alternative to deletion. Mdewman6 (talk) 00:31, 14 December 2020 (UTC)

• Just use AfD, which already handles this frequently and does so well enough. The instructions can be clarified to match de facto practice if needed. {{u|Sdkb}} ^talk 00:13, 14 December 2020 (UTC)
• Support reporting a BLAR unfortunately. BLAR is sometimes abused by editors to avoid AfD - they may unilaterally "delete" the page without discussion or notification. It is a known loophole in the deletion processes and people have literally bragged about it (names withheld). At a minimum a BLAR should be required to be reported somewhere so the community can see that it was done. I don't think there should be a separate process, like AfD, too much administrative overhead. -- GreenC 03:53, 14 December 2020 (UTC)
• Use AfD. If a WP:BLAR is controversial, revert it and take the matter to AfD (as a procedural nomination; you don't have to agree with the BLAR decision, you just want the community to discuss it). If someone has a habit of doing clearly controversial BLAR actions, that is a behavioral problem. If they do not respond to gentle user-talk pressure and a pointer to WP:AFD and WP:PAM processes, and they continue doing it after being asked to stop, then you have cause to open a behavior examination at WP:ANI. In short, we have no need for an additional layer of bureaucracy here.  — SMcCandlish ☏ ¢ 😼  07:33, 14 December 2020 (UTC)
• Just use AfD. Back in 2015, we had a request for comment about whether editors are allowed to start discussions at WP:AFD that explicitly advocate for redirection and not deletion, and the answer was yes. Deletion and redirection have a lot in common in terms of the reasons why we might decide to do either, so I don't really see anything wrong with the current practice of simply starting an AfD, but in the AfD nomination say that you are asking for a redirect and not deletion. Creating a brand new process for this would be unnecessarily complicated. Mz7 (talk) 07:35, 14 December 2020 (UTC)
• Support I do think it's weird that you need AfD to delete one article, but a single editor can blank and redirect 1,700 articles without a discussion. Blanking and redirecting over 1,700 Knight's Cross of the Iron Cross biographies was one of the background issues in the "German war effort" arbitration case. In my opinion, the problem was that some articles deserved merging while some did not – due to the sheer volume and the lack of specific discussion, the baby was thrown out with the bathwater. This is a loophole. --Pudeo (talk) 09:36, 14 December 2020 (UTC)

Deletion is treated differently because it's semi-permanent; only admins can see the deleted revisions, and only admins can undelete things. Anyone can see and contest a blank-and-redirects, so in that sense they're more like merges, moves, etc. – all of which you can do WP:BOLDly if you don't expect any objections. Of course, any of these processes can be abused, but hopefully that's rare. – Joe (talk) 16:38, 18 December 2020 (UTC)

• Comment I would note that a merge is also a common result of AfD discussions, and nevertheless there is still also an effective process for discussing proposed mergers at a talk page without escalating to AfD and involving admins and non-involved editors. The goal is not to make things more complicated; all I am proposing here is to clarify the distinctions and similarities between a merge and a blank/redirect on the information page, WP:MERGE, and to create a few new templates for more accurately tagging pages. This would simply strengthen existing policy, which certainly allows for and encourages discussions on talk pages before conducting a change as drastic as page blanking, even if policy allows for it to be done BOLDly. The only true policy change would be amending WP:BLAR, a section at WP:REDIRECT, to point out a discussion can be conducted like it were a merge proposal even if no content is proposed to be merged. After all, the outcomes of both are quite similar: a page with an article becomes a redirect. It's a disparately binary choice to either BOLDly blank a page or bring it to AfD. In a lot of cases, an intermediate approach would be most appropriate, generating a discussion among those interested in a page, perhaps involving users affiliated with the relevant WikiProject, rather than unnecessarily escalating to the bureaucracy of AfD when deletion is not being proposed. Nevertheless, users can certainly choose to propose a blank and redirect at AfD if they think that's most appropriate, such as when they are not sure whether there is a suitable redirect target, or seek input whether deletion would be the better alternative. Mdewman6 (talk) 22:34, 14 December 2020 (UTC)

  This merge process is anything but functional. I wouldn't model anything after it. --Izno (talk) 14:45, 15 December 2020 (UTC)

• Using merge/AfD procedures should both be fine. I've always felt like our policies on blanking and redirecting are a bit weird and only covered as an afterthought to merging/deleting discussions, so I think we should spell out more clearly what avenues are available. I think nominating for AfD makes sense in a lot of cases when it's a WP:GNG fail or similar, but it's a plausible redirect target. I think boldly blanking and redirecting makes sense in cases where you might CSD the article if it didn't have a redirect target. I also feel like using the merge process could be a good intermediate-level "checks and balances" mechanism where you don't really need a full-blown AfD discussion but you would like to give people a chance to register opposition or provide new information (PROD parallel?). No objections within a week would allow you to go ahead and blank and redirect. — Bilorv (talk) 02:11, 15 December 2020 (UTC)
• Just use AFD per SMcCandlish and Mz7. If you think a page is better as a redirect, WP:JUSTDOIT. If it gets reverted, take it to AFD and state in the nom that you think it should be a redirect. If you see a BLAR followed by a revert, you can take it to AFD yourself as a procedural nomination. We need fewer processed, not more, and contested BLARs at AFD is one that works fine and certainly better than the merge process (which is also not mandatory). — Wug·a·po·des​ 01:30, 16 December 2020 (UTC)
• AfD if controversial otherwise one person boldly doing it on their own is fine. TonyBallioni (talk) 04:13, 16 December 2020 (UTC)
• Use AfD. I see merger proposals as a flawed system on Wikipedia, with very low participation on less-viewed pages leading to these templates languishing for months if not years. AfD is efficient and gets the job done. feminist (talk) 06:52, 17 December 2020 (UTC)
• Use AfD or RfD — Assuming that a redirect has some value, and is properly tagged. For example, {{R with possibilities}}. If the same or similar content already exists at the target, this preserves the history at both places. For controversial redirects, such as something that reflects poorly on a person or organization, there is always RfD. We don't really need yet another process.
  William Allen Simpson (talk) 22:17, 17 December 2020 (UTC)
• Oppose (ec) per WP:CREEP. It seems clear that we already have too many processes as most everyone seems to have forgotten WP:RFD which specifically for discussing redirects. AFD is not appropriate as that is specifically for use of the deletion function and I don't see people !voting "blank and redirect" or BLAR there. Most of the time, blanking is just a lazy way of ducking merger and so WP:MERGE is what should be used. Andrew🐉(talk) 00:09, 18 December 2020 (UTC)

  "Redirect" is often proposed as an outcome in AfD nominations. I'm sure you are aware of that. feminist (talk) 12:08, 18 December 2020 (UTC)

• Use AFD if controversial, be bold if not. Another process here would just be instruction creep. If there's any doubt, I see no problem with sending it on to AFD. Don't use RFD for this process, as RFD is to judge existing redirects and not to determine notability of an article. Redirects are not judged by notability, so keep notability questions outside of RFD. Hog Farm _Bacon 00:04, 20 December 2020 (UTC)
• AFD We already have a venue for this. Another process would be adding to the bureaucracy, and we already have too many processes and too few editors. Or, just be BOLD. Most blank and redirects can be done that way. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:20, 24 December 2020 (UTC)
• AfD should be required when substantial content is being removed. A merge which moves most of the content of a mini-stub to a more inclusive article is a true merge; a merge of two very closely related articles including most of the content from both is a true merge. A merge that removes the entire content is a deletion not a merge, and should not be done outside of AfD. But there are intermediate cases which are not that easy to classify. I'm not sure how much to word it exactly. I will note that there are many cases which are currently being handled as uncontroversial merges, like merging a non-notable book to a list on the author page, where this would require afd. I anticipate there might be another 10 or 20 afds a day. DGG ( talk ) 07:14, 26 December 2020 (UTC)
• Use AfD if controversial-- It's one of the things AFD is meant to be used for , contrary to what some users may think (AFD C4 clearly states If a redirection is controversial, however, AfD may be an appropriate venue for discussing the change in addition to the article's talk page.) -- Eddie891 ^Talk _Work 15:45, 27 December 2020 (UTC)
• If it is a large page (more than a WP:STUB), use AfD. Unless it is a recently created content fork.

If a bold redirect was reverted, use AfD.

If the target does not mention the title, the redirect is not justified; use AfD to delete. —SmokeyJoe (talk) 22:33, 28 December 2020 (UTC)

• Use AFD if controversial/contested per above. Regards  Spy-cicle💥  ^Talk? 22:57, 28 December 2020 (UTC)
• If it is controversial or potentially controversial use AfD or RM. If you think it more likely than not that there is content which should be merged then use RM, if you think it more likely than not that there is no content to be merged then AfD is most appropriate. If you are not sure either way then just use your judgement and state your uncertainty in your nomination statement. Redirection followed by RfD is never appropriate. Thryduulf (talk) 14:15, 29 December 2020 (UTC)
  • Thryduulf, by “RM”, do you mean “Wikipedia:Proposed article mergers”? —SmokeyJoe (talk) 22:52, 29 December 2020 (UTC)
    • Yes, WP:PM not WP:RM. Sorry. Thryduulf (talk) 09:34, 30 December 2020 (UTC)
• Use AfD if controversial; just do it if not. The uncontroversial case is very much like a PROD; in both cases anyone can challenge the tag for any reason with no time limit (articles deleted through PROD can always be restored on request), and contentious cases can then go to AfD. -- King of ♥ ♦ ♣ ♠ 22:37, 1 January 2021 (UTC)
• Prefer WP:BOLD regardless. It's the easiest way to identify whether a redirect will be controversial. Subsequently, prefer WP:AFD to any sort of new process. Which is basically how it works today. --Izno (talk) 03:05, 3 January 2021 (UTC)

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.