Wikipedia talk:Merging
| This is the talk page for discussing improvements to the Merging page. |
|
| This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
| ||||||||||||||||||
| To help centralize discussions and keep related topics together, [[:|{{{1}}}]] redirects here. |
Note on copying content
edit@FaviFake, I saw you reverted my note on copying content. Its mostly an issue I've run into a few times with named references where the text when copied from the article or from the visual editor of the source article gets the named reference tag but not the reference itself and then produced errors in the references section saying that there's no known reference with that name. See also this discussion on my talk page from another editor who asked for some help. I checked their edit history and they had done the edits with the visual editor and when I pasted the wikicode from the source into the visual editor it remediated the issue.
I've reworded my note a little and re-added it because I think it provides a good trouble shooting step if editors run into the issue before they need help or give up on performing the merge. Let me know what you think? ScrubbedFalcon (talk) 10:28, 1 March 2026 (UTC)
- Thanks for your message! I just don't understand what difference it makes if one copies a named reference using the ve instead of the source editor. Won't the source editor also copy the same call without the reference itself? FaviFake (talk) 13:39, 1 March 2026 (UTC)
- I'm not sure exactly what causes it, I know its happened to me before and this is how I solved it. I'm trying to recreate the error from the most recent example in my sandbox. I know that this is the error diff in namespace. I copied the wikitext from that diff to this sandbox page. The errors appear differently in the sandbox it seems, in the article namespace version they appear in the reference list as: "Cite error: The named reference XYZ was invoked but never defined (see the help page)." in the sandbox version they are simply blank references. Meanwhile on a separate sandbox article I've pasted the wikitext from the source article where the references are defined. I'll keep messing with it tomorrow, but feel free to take a look and see if you can pinpoint the source of the error if you want? ScrubbedFalcon (talk) 18:47, 1 March 2026 (UTC)
Including WP:PAGEDECIDE in MERGEREASON
edit@Klbrain, I think it would be good to link to PAGEDECIDE somewhere in mergereason because it comes up so often in merge discussions and there seems to be a misunderstanding among some editors that merging is only for non-notable content so I thought clarifying the role of editorial judgment would be important. I can see where you're coming from on including it in the Context anchor and not wanting it to be to long. Would you be open to a revised wording of Context? For example:
| − | '''Context''': | + | '''Context''': Some topics that are independently notable are best covered in the same article in order to better serve reader understanding. For example, if a short article requires the background material or context from a broader article in order for readers to understand it. This is more extensively discussed by [[WP:PAGEDECIDE]].
|
ScrubbedFalcon (talk) 15:50, 23 March 2026 (UTC)
- Sure! Personally this looks fine either way to me (i'd just avoid the WP:WTF). FaviFake (talk) 16:19, 23 March 2026 (UTC)
- Could also do a piped link to pagedecide in the first sentence of the proposal and leave off the third sentence. ScrubbedFalcon (talk) 16:44, 23 March 2026 (UTC)
- Yes; agree that that's a good suggested change. Klbrain (talk) 21:58, 23 March 2026 (UTC)
- Could also do a piped link to pagedecide in the first sentence of the proposal and leave off the third sentence. ScrubbedFalcon (talk) 16:44, 23 March 2026 (UTC)
RfC on merging AfD and PAM
editMisinterpretation of the RfC
editThe 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.
The RfC outcome was There is consensus to merge proposed article merge process with Articles for deletion
(Wikipedia:Requests for comment/Merging merge discussions with AfD), not that the broader merging process should be tagged. My reading of the outcome is hence that only the proposed article merge (linking the page before major changes were implement in what I view was against consensus) rather than merging as a whole. Klbrain (talk) 10:16, 3 April 2026 (UTC)
- @Barkeep49 and FaviFake: notifying you of this discussion, as proposal closer, and of the editor whose interpretation I disagree with. Klbrain (talk) 10:21, 3 April 2026 (UTC)
- Unfortunately the consensus, which I am fully against, was to merge the PAM process (which here refers to creating, categorising, and closing a merge proposal), not just PAM the noticeboard. See the first line of the closing statement.The AFD template is currently being reworked to allow editors to nominate articles for merging. The backlog of open merge proposals will eventually come down to zero, as they will all be handled at AfD, and the {{merge}} templates will be depreacated. The will no longer be a formal merge process outside of AfD.This is how almost every participant understood it, and how Voorts, the nominator, intended it to work. You can discuss the implementation at WT:AFD § Follow up from RfC. FaviFake (talk) 10:31, 3 April 2026 (UTC)
- The proposal was specifically to close the Proposed_article_mergers process, whereby discussion was made at that site. I have no problem with the that. The RfC did not affect local consensus-making, as the close makes clear. So, we should be implementing only changes agree in the RfC, not those that go beyond it. Klbrain (talk) 10:56, 3 April 2026 (UTC)
- We wouldn't have needed an RfC to close a dead noticeboard. Voorts's proposal and the community's understanding of the proposal was the one I described. The entire point of the proposal was to deprecate the {{PAM templates}} (that's {{merge to}} and the rest) and require that formal merge discussions happen at AfD, for a variety of reasons.Would you mind if I moved this discussion to WT:AFD § Follow up from RfC, since the interpretation and implementation are being discussed there? FaviFake (talk) 11:07, 3 April 2026 (UTC)
- And again: I fully disagree with this outcome and think the previous merging process was superior. But this was the community's consensus and the sooner we implement it, the less worse the transition will be. FaviFake (talk) 11:10, 3 April 2026 (UTC)
- We wouldn't have needed an RfC to close a dead noticeboard. Voorts's proposal and the community's understanding of the proposal was the one I described. The entire point of the proposal was to deprecate the {{PAM templates}} (that's {{merge to}} and the rest) and require that formal merge discussions happen at AfD, for a variety of reasons.Would you mind if I moved this discussion to WT:AFD § Follow up from RfC, since the interpretation and implementation are being discussed there? FaviFake (talk) 11:07, 3 April 2026 (UTC)
- The proposal was specifically to close the Proposed_article_mergers process, whereby discussion was made at that site. I have no problem with the that. The RfC did not affect local consensus-making, as the close makes clear. So, we should be implementing only changes agree in the RfC, not those that go beyond it. Klbrain (talk) 10:56, 3 April 2026 (UTC)
- No need to move the discussion here; I'll comment over there. Klbrain (talk) 11:16, 3 April 2026 (UTC)
Grammar
editFor thirteen years, the lede of this page began, "A merger is...". Then, in 2022, it became "A merger, or merge is...". Fine, whatever. Two days ago, User:FaviFake has now removed "merger" and is stubbornly insisting that there is a consensus that we do not use proper grammatical English on this page. This is too much.
I understand that there are some people who use "a merge" or "the merge" colloquially on talk pages. But merge is a verb, not a noun. The noun is "merger" and the gerund is "merging".
Even though we use shorthand and abbreviations on talk pages, my understanding is that we write information pages in grammatical English, so we don't look stupid. Thus, as just one example of many, on Wikipedia:Speedy deletion, it says, "If a page has survived its most recent deletion discussion, it should not be speedily deleted..." not "it should not be speedy deleted..." even though users on talk pages sometimes say "speedy deleted" as its own verb.
So, when writing a page with instructions for users who are probably here learning about Wikipedia, is there no solution that exists that cannot accomplish both the desire to use the plain, common language we use typically, but also have it grammatically correct? Bsherr (talk) 16:40, 4 April 2026 (UTC)
- Sure, whatever, I restored the lede from 4 years ago. You could've asked. But yes, if Wikipedia consistently does not use "proper grammar", as you say, then you need consensus to do whatever this is. A few examples:
Any editor can perform a merging.
An editor who thinks merging could be a good idea but is not confident about performing it themselves
(Now, this is definitely not proper grammar. What does "it" refer to?)The standard process for proposing a merging
a comment on the merging proposal
Any editor [...] is permitted to perform a merging
- FaviFake (talk) 16:51, 4 April 2026 (UTC)
- Cool story. OED notes that merge has been used as a noun since at least 1806:
- "Merge". Oxford English Dictionary (Online ed.). Oxford University Press. (Subscription or participating institution membership required.)
- Arguing that either merger or merge is the "correct" noun form is pointless, because anyone who argues either side is wrong. They're both accepted. Fighting prescriptivism with prescriptivism in general is pointless. ~ oklopfer (💬) 16:54, 4 April 2026 (UTC)
- I would suggest looking at the entry in detail. Oxford, which always aims to be more comprehensive, is an outlier, to account for specific instances, for example a traffic merge. Cambridge, Webster, and Collins don't include the noun form, and it is uncommon in regular writing.
- In most of these instances, the word "merger" would be better. Since that word seemed to be a sticking point for you, I tried to use the word "merging" instead, since it is the name of the page. "Merging" is a gerund, a nonfinite verb that functions as a noun. Gerunds can be correctly preceded by a definite (the running of the race) or indefinite (a reading of the book) article. I would be happy to use merger instead. --Bsherr (talk) 17:06, 4 April 2026 (UTC)
Listing for discussion of Template:Merge
edit
Template:Merge has been listed for discussion, which may result in the template being merged or deleted by consensus. You are invited to comment on the proposed action at the entry on the Templates for discussion page. voorts (talk/contributions) 19:56, 4 April 2026 (UTC)
Informal merge discussions at the wrong talk page or forum
edit@FaviFake The only constructive place to start a consultative discussion about merging, or a discussion how to execute a non-controversial merge in specifics is the destination page’s talk page. Merging is about improving the destination page, so the relevant place to discuss is its talk page. Starting a discussion at the talk page of a page that would, following the merge, become a redirect is just bad. This is why for years, this advice had been included in the form of “ This is usually done on the proposed destination page's talk page.” and this is not tied to PAM as PAM, it is a wider logic. —Alalch E. 13:40, 5 April 2026 (UTC)
- I hadn't seen your ping, but the edit summary I left directly answers your comment: Your version was stable before the entire PAM process that this page covered was deprecated and became historical! This is literally the text of the closure:
Nothing in this close should be taken to mean [...] that editors cannot establish consensus for merging through other means of consensus forming other than AFD.
The closer links to WP:CONBUILD for this, which has a list of available options. Some of the options at that link: talk pages, Noticeboards, Third opinion, Village pump. It's literally in the closure of the RfC. FaviFake (talk) 13:46, 5 April 2026 (UTC)- I disagree. The advice to use the destination page’s talk page is the only advice worth giving on an information page, that is the advice that was given for a long time, and it does not attach to the formal aspects of PAM and only attaches to a wider editorial logic. The RfC does not affect this. —Alalch E. 13:49, 5 April 2026 (UTC)
The advice to use the destination page’s talk page is the only advice worth giving on an information page
What? Why?!
that is the advice that was given for a long time
Before the process was shut down following consensus.
it does not attach to the formal aspects of PAM and only attaches to a wider editorial logic
Editorial logic has nothing to do with this. And why would it be detached from PAM, if the PAM process and templates were literally based on the talk page discussions happening at the destination? FaviFake (talk) 13:53, 5 April 2026 (UTC)- Your version discourages, for example, a newbie from asking at the TEA if it's ok to try a bold merge on page X. And you can't tell me that's not allowed. FaviFake (talk) 13:54, 5 April 2026 (UTC)
- Only mentioning the recommended forum does not say that anything else is disallowed. By saying “You can X” we are not saying “You cannot !X”. The idea that a new editor should ask at the Teahouse is a general concept that applies to anything. At the Teahouse that new editor would be told to ask at the talk page of their identified destination page to get responses from editors interested in that article who will know much better what that article needs to become better. That is also the answer to your “Why”, alongside what I said above:
Merging is about improving the destination page, so the relevant place to discuss is its talk page. Starting a discussion at the talk page of a page that would, following the merge, become a redirect is just bad.
—Alalch E. 14:01, 5 April 2026 (UTC)- Then why did you say that
it needs to he the destination page’s talk page, this is very important
?The reason I wan to add some more options is so that especially new editors aren't stuck if their talk page post is ignored or receives no replies. Would it be ok with you if asking at Wikipedia talk:Merging were recommended as well, just like AFD recommends asking at WT:AFD if you're not sure about nominaing an article for deletion? They wouldn't be told to go to the talk page if they asked here. FaviFake (talk) 14:08, 5 April 2026 (UTC)- We agree on the substance now, is that fair for me to say? I have explained to you why it is important to recommend the destination page’s talk page for an informal discussion about merging. Since multiple pages are involved in a merge, whenever starting a discussion about merging on a talk page is considered, the inescapable question arises: on which talk page of the multiple involved pages' talk pages should I start the discussion on. Decades of experience have shown that the superior option is the destination page's talk page. That is why the description of PAM process referred to this item of received wisdom—said item does bot depend on PAM. It is a standalone item of broad editorial logic. If we agree, and if you think there is a better way to put it, I would ask you the following:
- Please work with me to simply wordsmith that part of the text so that the page says what we both want it to say in the best way. —Alalch E. 14:16, 5 April 2026 (UTC)
- I mean... I'm less of a worshipper of this mythical destination's talk page, especially in the case where it doesn't exists (merge X and Y into new article Z) or when it's not watched by enough people (which was often the case with PAM), so I'd like to give the readers more options and let them choose. What about this?
(that's a wikilink) FaviFake (talk) 14:28, 5 April 2026 (UTC)If you want to check if there is opposition to a potential merge or want to hear other editors' opinions, you can seek input through standard consensus-building venues, most commonly the destination article's talk page or the Merging talk page.
- I’m fine with that, thanks. —Alalch E. 14:32, 5 April 2026 (UTC)
- I mean... I'm less of a worshipper of this mythical destination's talk page, especially in the case where it doesn't exists (merge X and Y into new article Z) or when it's not watched by enough people (which was often the case with PAM), so I'd like to give the readers more options and let them choose. What about this?
- Then why did you say that
- Only mentioning the recommended forum does not say that anything else is disallowed. By saying “You can X” we are not saying “You cannot !X”. The idea that a new editor should ask at the Teahouse is a general concept that applies to anything. At the Teahouse that new editor would be told to ask at the talk page of their identified destination page to get responses from editors interested in that article who will know much better what that article needs to become better. That is also the answer to your “Why”, alongside what I said above:
- Your version discourages, for example, a newbie from asking at the TEA if it's ok to try a bold merge on page X. And you can't tell me that's not allowed. FaviFake (talk) 13:54, 5 April 2026 (UTC)
- I disagree. The advice to use the destination page’s talk page is the only advice worth giving on an information page, that is the advice that was given for a long time, and it does not attach to the formal aspects of PAM and only attaches to a wider editorial logic. The RfC does not affect this. —Alalch E. 13:49, 5 April 2026 (UTC)
Potentially controversial
edit@FaviFake: We should say “controversial” or something equivalent. “Potentially controversial” is extra language for less clarity. Saying “potentially controversial” there means “always nominate at AfD”, because every edit is potentially controversial, so this just constitutes a negation of merging boldly, creating an internal contradiction. How to know that the proposal is controversial is a practical matter and there is always a reason to believe that someone might oppose any bold action; having an informed opinion on how likely that is is a matter of judgement and experience. Ping @RGloucester who has edited the same sentence recently. —Alalch E. 12:03, 6 April 2026 (UTC)
- IMO, "controversial" means that there are definitely people who disagree, not that there might be a number of people who disagree. of course technically every merge is controversial, but that's not what we mean when we say that. For example, "uncontroversial" merges are undone and debated all the time. This phrasing doesn't leave any room for merges that are neither obviously uncontroversial neither definitely controversial. FaviFake (talk) 12:07, 6 April 2026 (UTC)
- That’s right, it means there are definitely people who disagree. The question is epistemological: Determining whether there are or aren’t is your responsibility. You have a duty to be bold, and have the permission not to be bold only if there is a good reason not to. “Be bold” is a command. It means: “Don’t waste other people’s time with unnecessay process; put in the work and deliver the goods to the project”. —Alalch E. 12:14, 6 April 2026 (UTC)
- That's not true. Uncontroversial merges have to be taken to AfD if the nominator doesn't want to perform it but thinks it should be done. PAM worked the same way. FaviFake (talk) 12:19, 6 April 2026 (UTC)
- Absolutely not, that is contrary to policy (WP:BURO). —Alalch E. 12:23, 6 April 2026 (UTC)
- It's not written anywhere that if someone thinks a merge is obvious (two long and almost identical lists, for example), they MUST do it themselves. They could not have the time or the technical knowledge to do it. Should those lists remain standalone, or should they be inserted into the backlog and merged a few months later by a passing editor? FaviFake (talk) 12:26, 6 April 2026 (UTC)
- The only way to to the latter is to nominate them at AfD. FaviFake (talk) 12:26, 6 April 2026 (UTC)
- It isn’t. Please give me the examples of how someone might try outside of AfD and what would go wrong. —Alalch E. 12:32, 6 April 2026 (UTC)
- What? You can't insert an article into the backlog without going to AfD. FaviFake (talk) 12:33, 6 April 2026 (UTC)
- I didn’t understand your example, please just re-explain using some other words so I might get it. —Alalch E. 12:35, 6 April 2026 (UTC)
- The only way to add any article to Category:Articles with consensus to merge is to use the templates, and placing them requires a discussion. FaviFake (talk) 12:39, 6 April 2026 (UTC)
- I didn’t understand your example, please just re-explain using some other words so I might get it. —Alalch E. 12:35, 6 April 2026 (UTC)
- What? You can't insert an article into the backlog without going to AfD. FaviFake (talk) 12:33, 6 April 2026 (UTC)
- It isn’t. Please give me the examples of how someone might try outside of AfD and what would go wrong. —Alalch E. 12:32, 6 April 2026 (UTC)
- They must if they are willing as volunteers to spend resources on this project and are able to do it. If they are willing and able but instead of doing it they are talking — if they are talking instead of doing — they are in breach of their obligation to be bold. That is why “Be bold” is “Be bold” and not “Feel free to be bold” or “you can be bold”. —Alalch E. 12:30, 6 April 2026 (UTC)
- That's not an obligation. Read H:M.
If merging is obviously needed and is not controversial, editors are encouraged to be bold and simply do it themselves
(emphasis supplied) FaviFake (talk) 12:32, 6 April 2026 (UTC)- It’t a pillar and a commandment. Being bold as a duty is the core of what it means to he a Wikipedian. —Alalch E. 12:33, 6 April 2026 (UTC)
- Sure. Whatever. FaviFake (talk) 12:34, 6 April 2026 (UTC)
- That’s how Wikipedia is made, by an army of people each being bold to the limits of their capacity to deliver useful work without asking for constant tenders, minders, bosses, feedback-givers, committees, etc. That is the whole secret of Wikipedia. Those who make mistakes in the process are treated cruelly. That is something a private company cannot do, but a volunteer project can, and this is why Wikipedia is such a big accomplishment. —Alalch E. 12:38, 6 April 2026 (UTC)
the limits of their capacity
That's my point. If a 13yo user sees two obviously identical article and has never used wikipedia before, why should they not go to AfD. should we delete maintenance tags because everyone can add the sources themselves, or cleanup tags because everyone can be bold? FaviFake (talk) 12:41, 6 April 2026 (UTC)- I’d like to hold back on further argumentation and, if possible, conclude our work on that one sentence by both of us agreeing that “If you have reason to believe that merging an article is controversial, nominate it for merging at AfD” says well what it needs to say. Are you good with that for the time being? —Alalch E. 15:28, 6 April 2026 (UTC)
- That’s how Wikipedia is made, by an army of people each being bold to the limits of their capacity to deliver useful work without asking for constant tenders, minders, bosses, feedback-givers, committees, etc. That is the whole secret of Wikipedia. Those who make mistakes in the process are treated cruelly. That is something a private company cannot do, but a volunteer project can, and this is why Wikipedia is such a big accomplishment. —Alalch E. 12:38, 6 April 2026 (UTC)
- Sure. Whatever. FaviFake (talk) 12:34, 6 April 2026 (UTC)
- It’t a pillar and a commandment. Being bold as a duty is the core of what it means to he a Wikipedian. —Alalch E. 12:33, 6 April 2026 (UTC)
- That's not an obligation. Read H:M.
- The only way to to the latter is to nominate them at AfD. FaviFake (talk) 12:26, 6 April 2026 (UTC)
- It's not written anywhere that if someone thinks a merge is obvious (two long and almost identical lists, for example), they MUST do it themselves. They could not have the time or the technical knowledge to do it. Should those lists remain standalone, or should they be inserted into the backlog and merged a few months later by a passing editor? FaviFake (talk) 12:26, 6 April 2026 (UTC)
- Absolutely not, that is contrary to policy (WP:BURO). —Alalch E. 12:23, 6 April 2026 (UTC)
- That's not true. Uncontroversial merges have to be taken to AfD if the nominator doesn't want to perform it but thinks it should be done. PAM worked the same way. FaviFake (talk) 12:19, 6 April 2026 (UTC)
- Sure, yeah. I just disagreed with your opinions above, not the current text of the page :) FaviFake (talk) 15:30, 6 April 2026 (UTC)
- I just saw that you had added the last thing we discussed here to the body (the "or if you don't intend on carrying out a bold merge yourself", which I missed earlier), and I do not agree with this interpretation of policy, purpose of AfD, and the RfC’s outcome, and do not think it is helpful, so I reverted that. Can we pick up on that a little later if you’d like to keep discussing that specifically? Btw, I will also harmonize the text in the body with the incrementally improved version from the lead. —Alalch E. 15:41, 6 April 2026 (UTC)
- I wouldn't really like discussing it in the first place lol. Could you maybe bring it up at WT:AFD, where we're, among other things, interpreting the RfC consensus? Just so we get more input. FaviFake (talk) 15:48, 6 April 2026 (UTC)
- I’ll try to. I am both time- and technically-challenged; I am on the phone these several days which I’m not comfortable with. —Alalch E. 15:53, 6 April 2026 (UTC)
- Oh, God! Mobile wikipedia is hard to work with for sure. Last time I tried I messed up my edit summary thrice and had to post it on the talk page. FaviFake (talk) 15:58, 6 April 2026 (UTC)
- I’ll try to. I am both time- and technically-challenged; I am on the phone these several days which I’m not comfortable with. —Alalch E. 15:53, 6 April 2026 (UTC)
- I wouldn't really like discussing it in the first place lol. Could you maybe bring it up at WT:AFD, where we're, among other things, interpreting the RfC consensus? Just so we get more input. FaviFake (talk) 15:48, 6 April 2026 (UTC)
- I just saw that you had added the last thing we discussed here to the body (the "or if you don't intend on carrying out a bold merge yourself", which I missed earlier), and I do not agree with this interpretation of policy, purpose of AfD, and the RfC’s outcome, and do not think it is helpful, so I reverted that. Can we pick up on that a little later if you’d like to keep discussing that specifically? Btw, I will also harmonize the text in the body with the incrementally improved version from the lead. —Alalch E. 15:41, 6 April 2026 (UTC)
- That’s right, it means there are definitely people who disagree. The question is epistemological: Determining whether there are or aren’t is your responsibility. You have a duty to be bold, and have the permission not to be bold only if there is a good reason not to. “Be bold” is a command. It means: “Don’t waste other people’s time with unnecessay process; put in the work and deliver the goods to the project”. —Alalch E. 12:14, 6 April 2026 (UTC)
Creating nominations
edit@FaviFake (Just to preface: This is not about including shortcuts, links, or ritual words.) We are saying to include a rationale, so it is fairly helpful to point back to the stock reasons which are on this same page.
Merge is done via AfD now, and in a deletion-minded AfD that we’re used to, the nomination needs to contain “intelligible grounds for deletion” (wp:Speedy keep), which is interpreted to mean that it needs to tie back to the deletion policy, specifically the WP:DELREASONs (which are not presented as exhaustive … but in practice they are; and they incorporate by reference WP:RDELETE, WP:TFD#REASONS, etc.). If it does not contain these intelligible grounds, the outcome can be a speedy keep (i.e., the nomination is discarded).
And, for merge nominations, we have the MERGEREASONs. Pretty similar. It’s reasonable and natural to recommend that the nomination ties to one of them, after we have already advertised them on this page. It’s just natural. About “concrete terms”, that meant: The reasons are abstract. You can make a handwave reference to them while not understanding and/or not enabling others understand how and why they apply in the concrete. So this is basically just the answer to your question “what’s a concrete term”. It’s about not just making a mechanical reference to the listed reasons. Since merging is more complex than deleting, it’s even more important to explain things tangibly, concretely. —Alalch E. 21:34, 6 April 2026 (UTC)
“and are unable to attain consensus on the article talk page”
edit@RGloucester I’m sympathetic to this addition, but in reality we can easily imagine good reasons to believe that an idea is controversial, such as: other editors are already talking about it and do not agree; there has been an unresolved dispute in the past on the issue; the idea falls on one side of a well-known fracture among editors; etc. There are many others. You really do not have to try to attain consensus on article talk. It could actually be quite unproductive. —Alalch E. 21:51, 6 April 2026 (UTC)
- As was mentioned in the RfC, merging is not like deletion. Deletion requires administrative tools to enact. Merging is closer to moving/renaming. It is always better to try to attempt to attain local consensus before going through the laboured process that is AfD – and this is what the RfC closure specifically allowed for. If my addition is clumsy, I am open to other wordings – one way or the other, this fact should be mentioned here. Yours, &c. RGloucester — ☎ 22:16, 6 April 2026 (UTC)
- The addition is on the clumsy side because it suggests an escalation sequence: first try to discuss on a talk page, then start an AfD. Prescribing this escalatory sequence is a bit WP:BURO, which is ironic, because you want to avoid an excess of process. But you are doing so by seemingly adding a whole extra step. It does not have to be the way you’ve imagined it. There will be times when talk-page talking first seems like a good idea, and events follow your sequence without issue; there will be times when it seems like a good idea at the moment, but retrospectively, it turns out to have been a bad idea; there will be times when it seems like a bad idea, so it is avoided (does that mean that a rule was broken?); and there will be times when it seems like a bad idea, but someone does it anyway because they think that is the only proper way, because those are the instructions they received. We should be cautious and conservative when creating instructions. —Alalch E. 08:05, 7 April 2026 (UTC)
- Precisely. And it's also against the consensus as it was interpreted, per WT:AFD#Interpreting the RfC conseusus. This discussion should continue there (if it should even continue...), but in short, when PAM was active we didn't tell editors "try without the templates, then if no one replies add the templates". We just told them to use the PAM process for all formal proposals. This is the same except it's at AfD now. FaviFake (talk) 08:17, 7 April 2026 (UTC)
- I'm sympathetic to the position that the old PAM process was less bureaucratic and better suited to handling merges (I opposed the RfC), but I agree with Favi that given the outcome of the RfC adding the step of asking editors to try establishing local consensus (on largely unmonitored talk pages) before pursuing a formal discussion adds hurdles and goes against what the RfC was trying to achieve. ScrubbedFalcon (talk) 09:07, 7 April 2026 (UTC)
- Yeah. It's better to implement it fully instead of making a mess by trying to savage what's possible from PAM against consensus. It seems a similar thing is happening at WP:Templates for discussion/Log/2026 April 4 § Merge templates? It seems some editors are !voting to preserve current usage, as if that wasn't shut down by consensus? FaviFake (talk) 09:19, 7 April 2026 (UTC)
- The addition is on the clumsy side because it suggests an escalation sequence: first try to discuss on a talk page, then start an AfD. Prescribing this escalatory sequence is a bit WP:BURO, which is ironic, because you want to avoid an excess of process. But you are doing so by seemingly adding a whole extra step. It does not have to be the way you’ve imagined it. There will be times when talk-page talking first seems like a good idea, and events follow your sequence without issue; there will be times when it seems like a good idea at the moment, but retrospectively, it turns out to have been a bad idea; there will be times when it seems like a bad idea, so it is avoided (does that mean that a rule was broken?); and there will be times when it seems like a bad idea, but someone does it anyway because they think that is the only proper way, because those are the instructions they received. We should be cautious and conservative when creating instructions. —Alalch E. 08:05, 7 April 2026 (UTC)
- As was mentioned in the RfC, merging is not like deletion. Deletion requires administrative tools to enact. Merging is closer to moving/renaming. It is always better to try to attempt to attain local consensus before going through the laboured process that is AfD – and this is what the RfC closure specifically allowed for. If my addition is clumsy, I am open to other wordings – one way or the other, this fact should be mentioned here. Yours, &c. RGloucester — ☎ 22:16, 6 April 2026 (UTC)
Promerge edit summary instructions
edit@FaviFake I'll add it to the PAM-AfD merge to-do list, we can get to it eventually. ScrubbedFalcon (talk) 18:24, 24 April 2026 (UTC)
Incorrect usage of Template:Rcat
editUnder #Procedure, it says to use the following to convert the article into a redirect:
#REDIRECT [[DESTINATIONPAGE]] {{Rcat|{{R from merge}}}}
This seems incorrect, since it doesn't actually categorize the article, doesn't display anything other than "This is a redirect", and the docs for Template:Rcat say "A metatemplate for redirect category templates. Don't transclude this template directly." Is it supposed to be Template:Rcat shell instead? RainbowtheDragonCat (talk) 17:44, 9 May 2026 (UTC)
- Yes, it is supposed to be {{Rcat shell}}. Fixed. Warudo (talk) 18:05, 9 May 2026 (UTC)
Judging by Special:WhatLinksHere/Template:Rcat, a bunch of people have already followed the bad instructions. The RFC redirects are false positives because {{R from RFC}} uses {{Rcat}} but the rest are editors using rcat instead of {{Rcat shell}} and need fixing.Warudo (talk) 18:18, 9 May 2026 (UTC)- Nevermind that, I took it to RfD instead. Warudo (talk) 18:34, 9 May 2026 (UTC)
Question about undoing mergers that were completed
editI've come across an interesting talk page where someone is advocating for undoing a page merger. As a new contributor, I am interested in how that process is supposed to play out. It appears there is no formal mechanism or procedure, unless I'm missing something? Sometimes these guides can be difficult to find, apologies if this is a stupid question. BrokenLegBay28 (talk) 01:35, 14 May 2026 (UTC)
- That depends a little, do you know if the merger was performed BOLDLY or was there a discussion about the merge somewhere where consensus was found? You might need to go through WP:SPLIT. ScrubbedFalcon (talk) 09:24, 14 May 2026 (UTC)