Wikipedia talk:WikiProject Merge/Archive 2

From Wikipedia, the free encyclopedia
Jump to: navigation, search

New essay on merging

Hi all, I'm not sure if I'm the only one who feels this way, but when I work on our AfD backlog, I'm often irritated at cases where merging doesn't seem to make sense. Often it's because the subject is already covered at the proposed destination, so it should really just redirect; sometimes keeping or deletion seems like it would have worked better. I'm of the opinion that merging from AfD is broken somewhat, and I'm trying to make the case to a wider audience. The main reason, I think, is that unlike keep, delete, or redirect outcomes, closing administrators aren't expected to actually carry out these merges. If you're like me, you've probably seen some that have sat dormant for years after their AfD closes; it's always someone else's problem. I wouldn't go so far as to say these closing administrators are lazy, but I will say the merge option, as currently exercised, is lazy. If you feel at all similar, I'd much appreciate your help with my budding essay on the subject, located at User:BDD/Merge what? I'm plenty open to revisions or even a name change (two alternates are presented on the talk page). I'd like to eventually move this into W space, but I'd feel much better doing so if it was more than just my opinion. Thanks, BDD (talk) 01:11, 19 October 2012 (UTC)

Wikipedia "Merge" like WP:RM or WP:AFD

I would have posed here sooner if I had known this project existed!

See the discussion at Wikipedia:Village pump (proposals)#Wikipedia "Merge" like WP:RM or WP:AFD -- PBS (talk) 16:29, 11 January 2013 (UTC)

Project Merge Guidelines

These guideline seem to directly contradict what is being said at the WP:VPPR#So if Merge is like PROD. There it has been suggested that someone putting a merge tag on an article is like proposing an article for deletion, so if there are no objections then it should be treated as an uncontested merge (i.e. the option defaults to merging not delisting). At the least I would question the following being automatic delistings:

  • Either the target or destination article is a redirect to a different topic. (This does not include redirects for capitalization, spelling or formatting)
Why would this matter. If a merge proposal was meant for A to go to B, but B was moved to C first then why would you not just merge A to C if a merge was appropriate?
  • The merge discussion doesn't name both articles to be merged. (Close the discussion as void due to confusion about what articles are involved)
Sometimes the tag may be removed from one article or sometimes the editor may have forgotten to label both tags. In general it is the target page that does not have the reciprocal merge tag so I don't see why this would cause confusion. Seems like an overly bureaucratic reason to remove a merge tag.
Most merges are from a narrow topic to a broader one. Very narrow or very wide is very subjective and there may be cases when such a merge is still desirable.
  • The tags propose merging a biography to another biography without justification. This almost never makes sense, and there is a strong burden of proof on the proposer.
Not sure why this gets a special mention. Besides saying almost never means that occasionally it does (I remember merging two Russian writers together that exclusively worked together following a tag) so it should not be under
  • The article qualifies for speedy delete. Redirect it to a logical target if there is one, otherwise nominate for speedy deletion.
Isn't this outside the projects scope.
  • The article faced an articles for deletion discussion while the merge tag was on the page and not a single user proposed the merge in the discussion. Be sure to check the article history to make sure the merge tag was there during the deletion discussion.
Seems like a rather narrow guideline.

All in all the guidelines seem quite complex with too many caveats. I would recommend simplifying them drastically.

Why not keep it simple. For example:

  1. Check both articles talk pages for a discussion regarding the proposed merge.
  2. If there is consensus at the talk page for the articles to be merged then you should merge the articles together in the way described by the consensus. Note that consensus can exist if there are no objections. If you disagree with the consensus you can always just add your opinion to the discussion.
  3. If there is no consensus or consensus is not to merge then remove the merge tags from the articles.
  4. If there is no discussion at either talk page you should use your best judgement as to the correct action regarding the merge.
    • If this action gets reverted you can either open a new discussion if you think your action was correct or accept the revert. Do not edit war.
  5. If you are unsure of the correct action to take regarding a merge feel free to ask any questions regarding it here.

The first thing to do is to check and follow consensus. After that I think we need to have faith in the people making the merging decisions, and to be honest if a tag has been on an article for over a year there is probably not going to be too many complaints no matter what decision is made. On top of that moving an article can be done boldly so if there is no discussion there really is no wrong decision. AIRcorn (talk) 04:38, 24 January 2013 (UTC)

Backlog drive random links not working

I don't know whether this is just temporary or not, but the links for a random article with merge discussion (or merge after AfD) aren't working. --BDD (talk) 00:47, 26 February 2013 (UTC)

  • Must've been temporary. They're working normally again (that is to say, slowly). --BDD (talk) 06:09, 28 February 2013 (UTC)

Articles to be redirected?

Were Category:Articles to be redirected and {{Articles to be redirected progress}} stillborn? Anyone have any memory of any discussions related to their creation? What process populates these categories? Wbm1058 (talk) 15:46, 4 March 2013 (UTC)

See Wikipedia:Bot requests/Archive 47#Bot to date a template and {{Stub redirect}}. Perhaps if editors used this tag instead of one of the merge tags, when what they really mean when they want to "merge" is that they want to delete by redirection, then the backlog might be a little smaller. This tag probably doesn't need a reciprocal tag on the target article, because the proposed action has no effect on the target. But if a new tag isn't documented, it's less likely to ever be used. – Wbm1058 (talk) 14:08, 5 March 2013 (UTC)
I lean towards deleting both category and template. It makes more sense to be bold in these cases. Ego White Tray (talk) 04:53, 6 March 2013 (UTC)

Merge-a-rama, by June 1st

5% complete

Backlog: All articles to be merged
Goal: 0 articles
Current: 10,734 articles
Initial: 11,294 articles


I have decided that I need a Herculean project. So, I have made it my personal challenge to cleanup the backlog of articles at Category:Articles to be merged by June 1st. I will, of course, do all the easy ones first (no consensus to merge, quick redirects, merging a paragraph or two), then after work on the more challenging ones. So if you're interested in helping, I suggest you get in there quick before I pluck all the low hanging fruit.

Of course you're all invited to join all the fun in Merge-a-rama. It will be fun. But it looks like I'm on a tight deadline, because without any help I'll have to about 130 a day all by myself. I'll bet some random wikifolk will do a few in the next three months, but many hands make for light work, and I think if we all chip in we could have this backlog slain by mid May.

Any takers? --NickPenguin(contribs) 01:34, 25 February 2013 (UTC)

  • I'm in! GenQuest "Talk to Me" 03:51, 25 February 2013 (UTC)
  • Oh all right!. I will try and help. 03:59, 25 February 2013 (UTC) — Preceding unsigned comment added by Alan Liefting (talkcontribs)
  • I will do what I can!--Amadscientist (talk) 04:55, 25 February 2013 (UTC)
  • Why not? I'm skeptical that this can be done, but I'd love to be proven wrong. --BDD (talk) 16:50, 25 February 2013 (UTC)
We've passed the 1% mark, only 99% to go.
Bloody optimist... -- Alan Liefting (talk - contribs) 04:57, 27 February 2013 (UTC)
I hear optimists live longer. I plan to live until I'm 100, so I've got a ways to go yet. --NickPenguin(contribs) 12:48, 27 February 2013 (UTC)

May I request that participants attempt to follow the best practices at WP:Merging#How to merge? My primary concern is that {{R from merge}} has been skipped on some redirects where merging has occurred. (A simple redirect doesn't need the tag.) I prefer that talk page templates ({{Merged-to}}, {{Merged-from}}, {{Copied}}) be placed, but I understand that they require extra time and effort. Flatscan (talk) 05:41, 27 February 2013 (UTC)

I will ensure the R from merge tags are always in place on my merges. The other tags, probably only in cases where a significant amount of content is merged. --NickPenguin(contribs) 12:48, 27 February 2013 (UTC)
I must be doing it wrong, becuase as far as I can tell, I placed the tag right on Fact_(data_warehouse) and nothing happens. A cursory check of three other articles reveals the tag being used differently than the template doc, but displaying no different than the way I used it. --NickPenguin(contribs) 13:01, 27 February 2013 (UTC)
There is a long running bug where the text associated with redirected category templates (such as {{R from merge}}) doesn't display on the screen. You placed the template just fine. Ego White Tray (talk) 13:10, 27 February 2013 (UTC)
If that's the case, then I'll go through my old merged articles since I started doing this and properly add the tag. --NickPenguin(contribs) 13:57, 27 February 2013 (UTC)
Thanks for the quick fixes. Thanks for the effort, everyone. Flatscan (talk) 05:12, 28 February 2013 (UTC)
  • Looks like we've dipped below the 11,000 article mark. I look forward to other significant milestones. --NickPenguin(contribs) 01:41, 2 March 2013 (UTC)
    • I made some copy 'n' paste templates to get all the merge steps done faster, if anybody's interested. See Merging aids. GenQuest "Talk to Me" 06:04, 2 March 2013 (UTC)
  • I have made a bot request to add any missing merge tags. It has just completed it's trial and will likely roll out this week. It will, of course, set the progress bar to negative a million percent, but my thinking is that adding the missing tags will get people to remove the tags from both articles if there is no consensus to merge, and give the merges themselves more time in the spotlight. I still stand by my June 1st challenge. --NickPenguin(contribs) 15:49, 4 March 2013 (UTC)
  • 5% completed. --NickPenguin(contribs) 21:05, 6 March 2013 (UTC)

Attributing source material from the main article after a bold merge

Is this [1] sufficient attribution. If so do we need to change our guide?--Amadscientist (talk) 22:58, 20 March 2013 (UTC)

I didn't see any attribution - did you post the right link? The way to attribute properly is to places {{merged-to}} and {{merged-from}} on the talk pages (or instead {{copied}}. Ego White Tray (talk) 00:59, 21 March 2013 (UTC)
That was the attribution they believed was enough. The talk page is redirected to the main DR/N page so I don't belive the copy template would be appropriate here, but yeah....It doesn't even give the full name of the page that was copied from.--Amadscientist (talk) 01:01, 21 March 2013 (UTC)
Wait, is that edit summary what you're talking about? I guess that could be okay if you only copied a line or two from the other page, but a full-blown merge requires more. Ego White Tray (talk) 02:26, 21 March 2013 (UTC)
Yes, that is the edit summary. There was quite a merge of content and to be honest it was being done in a manner not consistent with policy. Twice it was attempted to merge all the content to the other page and request an admin delete the page as a housekeeping matter. When I mentioned that there was no attribution, this is what I got. Frankly, I feel that is not enough to find the page the information came from and I would assume a redirect would be used not a deletion.--Amadscientist (talk) 02:38, 21 March 2013 (UTC)

Automation of merge proposals

See VP:Wikipedia "Merge" like WP:RM or WP:AFD

The discussion at the village pump is now archived (here). Of those who expressed an opinion nearly all consider that the system, based on the current templates and the Wikipedia:Proposed mergers as currently implemented, is inadequate.

Of those who expressed concrete proposals to initiate some sort of change, most suggested an automation of the process (as was done a few years ago for WP:AfD and shortly afterwards with WP:RM). I proposed that user:Wbm1058 was involved in an automation process because Wbm1058 has very successfully taken over the RM automation, and the requesting of the merging of pages is quite similar to the process used for multi-page moves at WP:RM (see Wikipedia:Village pump (proposals)/Archive 98#Bot-assisted solutions).

Two major concerns were raised, those coming from an AfD background were concerned that a merge request might be used by some acting in bad faith to try to get a topic deleted by merging it away. This raised the issue of how to decide on a consensus for a move (ie unlike WP:RM where an unopposed move will be moved it was suggested that more just the nominator has to agree to a move).

The second was what mechanism to use for ensuring that agreed mergers were done in a timely manner, because the merging of articles can be time consuming and so unlike moves or deletes it is not reasonable or pragmatical to expect the closing editor/administrator to do the merge (see Who's gonna do it).

So would anyone like to propose how we implement the consensus that was shown to exist at Village Pump? -- PBS (talk) 10:18, 15 February 2013 (UTC)

Ego proposal

While we could easily automate the discussion process, we can't really automate the merging itself. The solution is to expect the nominator to do so and to mark them stale if no completed.

The following only would apply to merges with controversy. Any editor may boldly merge without discussion, but if disputed, it should be reverted and put thru the process below. The nominator is expected to carry out the merge himself.

  1. Add a template to the talk page of either article, which would be similar to the requested moves template
  2. A bot would create a new discussion page, list both pages in Category:Articles under discussion for merging, and link the discussion page to a centralized listing of merge discussions
  3. Discussion would close as merge, don't merge, speedy merge. Redirect votes would also be accepted and carried out, but deletion could not be carried out.
    1. Merge - Articles would be moved to category Category:Articles with consensus to merge, with tags placed on top of both pages saying so, and the discussion would move to a holding pen
      1. The nominator is expected to carry out the merge, however, anyone may do so. The nominator would receive a post on their talk page notifying them the merge was approved and with instructions on how to do it.
      2. When completed, a tag will be left on both talk pages announcing the pages were merged and linking to discussion. The pages would be removed from all merge categories and discussion archived.
      3. If not completed after 30 days, the merge will be considered stale. A tag will be left on both talk pages saying there was consensus to merge but it wasn't carried out promptly. The pages would be removed from all merge categories and discussion archived. However, any user could still carry out the merge without restarting discussion.
    2. Don't merge - A tag would be placed on both talk pages saying the merge was rejected and linking to the discussion. The pages would be removed from all merge categories and discussion archived.
    3. Speedy merge - Permitted when the two pages are obviously about the same topic. It may make sense to specify exact criteria. The process would be the same as a merge consensus.Removed due to objections Ego White Tray (talk) 19:35, 23 February 2013 (UTC)

Comments? Ego White Tray (talk) 13:55, 15 February 2013 (UTC)

  • Comment No speedy merge in the first cut. For many years there was not technical move at RM introducing it caused complications. I would suggest that initially there is no speedy merge. It reminds me of the ability to set +nice levels in applications, obviously as an application developer you set your program to hog the resources and make those who do not look as if their program is sluggish. As we have a limited pool of people willing to do merges, a speedy option would allow people to jump the queue -- better to have merge and let the people doing the merges decide that (it simplifies the instructions and it can be introduced later once the new process has bedded in and there is shown to be a need for it. -- PBS (talk) 20:04, 17 February 2013 (UTC)
  • Comment. As the system is new and at the moment there are 1000 of proposed merges that have been around for many many months. I suggest that initially the length of discussion used is that used for RfCs (one month) and the merge length is set to three months. However this should be on the understanding that over time if it proves expedient the process will move towards the Week and Month proposed. -- PBS (talk) 20:04, 17 February 2013 (UTC)
A month? Yikes. Most merge proposals aren't that complicated, so this seems like way too much time. WP:MERGE and H:M both specify a minimum listing time of a week, which is reasonable and more in line with RM. Not that RM doesn't have a backlog, but can you imagine how bad it would be if requests ran for a month? And it's easy to relist if discussion is ongoing. When this system is set up, all of those old merges out there should be considered to have run their course and closed as appropriate. The WikiProject is already doing this to a certain extent, but an automated system should be helpful in facilitating this. --BDD (talk) 19:29, 21 February 2013 (UTC)
  • Commnet. Yes there should be one central page (like that at WP:RM but I propose that instead of writing to that central page a transclusion option is used (as I think is done at Wikipedia:Copyright_problems then it will appear in the central page, but the page edit history will not get very very large. Then instead of deleting them we can keep the entry with a Bot comment on it current status (Open -- close with merge/no merge/etc/ -- Merge not done/done). -- PBS (talk) 20:04, 17 February 2013 (UTC)
  • I like this proposal overall; I missed the VP discussion somehow, but I've long wanted mergers to better resemble RMs. I would agree that "speedy merge" isn't necessary as an articulated option. If it's an obvious case, early closure is always fine per WP:IAR/WP:NOTBUREAU. --BDD (talk) 19:29, 21 February 2013 (UTC)

Deletion by redirection

those coming from an AfD background were concerned that a merge request might be used by some acting in bad faith to try to get a topic deleted by merging it away
— User:PBS

Redirect votes would also be accepted and carried out, but deletion could not be carried out
— User:Ego White Tray

I feel that a fourth closing option should be included: Redirect, which means, Deletion by redirection (policy, essay). My attempt to place a link to the essay in the policy section was reverted by an administrator who felt that the contents of the essay do not reflect mainstream consensus. I would like to flesh out what, if anything, in WP:Deletion by redirection is not mainstream consensus, and try to rewrite the essay to make it consensus if possible. I feel that this should be a valid option where:

  • the article to be redirected (deleted by redirection) has no sources given, but editors believe sources could be located by someone willing to do some research
  • there are no copyright, WP:BLP or other "show-stopper" issues making outright deletion necessary
  • no editor has stepped forward to volunteer to do the merge
  • any editor may boldly merge some or all content from the redirected article in the future, but we will not tag it into any work queues

For an example of where I feel this would be applicable, which I view as something of a test-case for my suggestion, see Wikipedia:Articles for deletion/Warren (Porridge). Comments there are encouraged, as it's been relisted to generate a more thorough discussion so a clearer consensus may be reached. Wbm1058 (talk) 16:01, 15 February 2013 (UTC)

Your fourth closing option is exactly what I'm suggesting, isn't it? And, due to the ability to revert by any editor, a redirect isn't really a delete at all. Ego White Tray (talk) 04:31, 16 February 2013 (UTC)
Right, I think we're basically in agreement, but the distinction between merge and redirect is perhaps a bit subtle. I would like to make redirect a mainstream option, and make clear that it isn't a "bad-faith attempt to delete an article via some backdoor means". I think this "bad-faith back-door" attitude is behind the perception that this option isn't mainstream. I've been working on the WP:Deletion by redirection essay, so please take another look at it. Also, see WT:Deletion by redirection for background on how the redirection alternative to deletion became the seventh, and most recent, alternative to deletion. In practice, the difference is that merge consensus means the articles are added to Category:Articles to be merged after an Articles for deletion discussion, while redirect consensus articles are not. The objective is to reduce the Category:Articles to be merged after an Articles for deletion discussion backlog by prioritizing what articles get put into it. Priority should be given to sourced articles which are obvious content forks. These are the articles we want disinterested volunteers working on. We're not saying that the unsourced, non-notable articles can't be merged, if they flat-out shouldn't be merged under any circumstances, then they should be truly deleted. We would be saying that an interested editor must boldly merge them, if they really want it done. Wbm1058 (talk) 22:20, 16 February 2013 (UTC)
  • I strongly agree that this should be an option, and I think it already is in practice; I've closed merge proposals with a ruling of redirect when no actual merging is necessary. This is actually a pretty common occurence—cf. the essay Wikipedia:Merge what? which, in the interests of disclosure, I wrote. I'd love to see this accepted as a mainstream option for merge discussions. It addresses the difficulty of merging, discussed elsewhere on this page, and, hopefully, will make people think more critically about when actual merges are necessary. --BDD (talk) 19:21, 21 February 2013 (UTC)
Good point. Shouldn't merge discussions under a new system include determination of consensus on what to merge, if the consensus is to merge? Maybe not down to specific details, but at least on some general higher level (e.g., merge "the entire article", or "just the second section", or "everything except the unsourced section"). Wbm1058 (talk) 02:47, 22 February 2013 (UTC)
Normal discussion should cover that. A nominator should propose just what is to be merged. In many cases, it will be the whole article. But other editors may move the discussion in a different direction, and part of the job of the closer will be to gauge what there is consensus to merge. Similar processes can happen at RM, when someone suggests an alternative name, which sometimes ends up being the consensual choice rather than the initial proposal. --BDD (talk) 02:53, 22 February 2013 (UTC)

Dr. Kubla's proposal

I don't think it's reasonable to expect the nominator to perform the merge. Merging is a complicated business, and such a requirement would likely mean that all but the most experienced editors would be discouraged from proposing a merger in the first place. I also don't agree with artificially reducing the backlog by removing proposed mergers that haven't been acted upon within a set period of time. Instead, I'd like to expand on an idea discussed briefly at the Village Pump. The process I envisage goes like this:

  • An editor proposes a merge by tagging both articles with a "proposed merge" tag – something like the current {{merge to}} and {{merge from}}.
  • The editor would then initiate a discussion on the target article's talk page, and add a link to the discussion to WP:Proposed mergers, or some other central forum, similar to how requested moves are handled.
    • Better idea: add a "proposed merge" tag (modeled after Template:Requested move) to the talk page of the target article, in a new section, with a brief rationale. A bot would then add a link to the discussion to WP:Proposed mergers, or some other central forum, exactly the same as how requested moves are handled. Proposal amended at 21:19, 23 February 2013 (UTC)
  • Possible outcomes would be "Merge", "Don't merge", "Redirect", or "Send to AfD". In the case of the latter three outcomes, the closer would be expected to act upon the decision himself, by either removing the merge tags, redirecting the article, or creating a procedural AfD nom. If the outcome is "Merge", the closer would replace the "proposed merge" tags with "consensus to merge" tags, which would say something like "A consensus has been reached to merge Article X with Article Y". This tag would add both pages to a new maintenance category.
  • Any editor may then perform the merge.

Yes, this would mean there would still be a backlog. The difference is that

(a) listing each discussion at a central forum would mean there would be more input into each proposed merge
(b) rejected proposals would be removed from the backlog straight away
(c) editors working through the backlog would therefore know whether a consensus has been reached, so there would be fewer judgement calls and fewer arguments
(d) it would no longer be possible to add a merge tag without starting a discussion, an annoying practice which is unfortunately far too widespread

This is the main thrust of my proposal; I haven't worked out all of the specifics yet. Any thoughts? DoctorKubla (talk) 08:24, 16 February 2013 (UTC)

  • Comment The point that your proposal significantly differs from Ego and Wbm1058 is they propose time limits for the merger. I agree with them. The reason I gave for that in the Village Pump discussion is that an agreed merger not yet carried out is likely to hang over further development of either or both articles and retard their development. And on the other side of the same coin if years go by between an agreement to merge, the articles may have changed significantly and a merge might not then be the best option (and editors can reasonably oppose a merger after months of inaction on the grounds that opinions can change. For these reasons I think a time limit on an agreed merger is essential. -- PBS (talk) 19:46, 17 February 2013 (UTC)
  • Comment There does need to be a deadline. However, I think a week is too short a time. Editor/Readers don't react as strongly or quickly to a "Merge" tag as opposed to, say, the dreaded "Deletion" tag. A month may be more in order for the merge process. This will save re-listing of the majority (I think) of the requests if a shorter standard is adopted.
I also feel that RfCs should go out immediately for any merge proposal upon discussion opening. As far as who should do it, the nom should, unless they feel incapable to the task, in which case, a page for Category:Articles awaiting merge needing editor assistance (or some equivalent) should be established and regularly patrolled, perhaps by the guild of copy editors, who already have the skill set to do merges. GenQuest "Talk to Me" 21:03, 21 February 2013 (UTC)
I respectfully disagree. AfDs and RMs are much more difficult to reverse, but a week is enough of a listing time for most of them. We don't want people to bypass the consensus-building involved in a good discussion due to impatience. I don't mean this as a threat or anything, but certainly if I had the choice between unilaterally merging two articles or sitting around for at least a month to talk about it, I'm probably just going to go ahead. --BDD (talk) 02:56, 22 February 2013 (UTC)
  • Comment Aside from the "consensus to merge" tag, this essentially the system we have now. We ask editors to start a discussion now, but they never do it. Your proposal misses the point that editors aren't following the procedure now. We need to automate as much as possible, reducing it to simply placing one template on one page, to ensure that whatever steps we have are followed. Ego White Tray (talk) 16:41, 22 February 2013 (UTC)
I was thinking that if there's a central discussion page, a bot could automatically remove merge tags which don't have an associated discussion (maybe this is possible now, but I'd imagine it would be a lot more complicated). But yeah, this proposal is fairly similar to the current system, which I don't think is so drastically broken as to need a complete overhaul. It just needs to be a little bit easier for editors to work through the backlog without getting drawn into arguments and edit wars. DoctorKubla (talk) 17:30, 22 February 2013 (UTC)
Arguments and edit wars are not the problem, and almost never are a problem. There are several problems, but it all comes down to editors rarely following the complete set of merge instructions that we already have, leaving a large number with zero discussion after three years. It sounds like the only change you propose is a central forum, but it isn't really that, it's sounds more like a list of links. Since editor's aren't starting discussion sections on articles now, what would change if we ask them to start discussions elsewhere instead? That's why we need to leave maintaining discussions to bots and not ask editors to do it. You also don't seem to address at all how to make sure these merges happen. The AfD merge backlog was once approaching 400 articles, for example, all of these approved merges. What's to stop that from happening again? Ego White Tray (talk) 19:31, 23 February 2013 (UTC)
Dedicated editors working through the backlog. That's the only way the backlog will be reduced. The reality is that very few people who propose a merge will ever be willing to perform the merge themselves, and there's no way to force them to do it. Therefore, your proposal will mean that the majority of articles that ought to be merged won't be, which is pretty much the current state of affairs, except that you also then suggest that these articles then be de-tagged and removed from all maintenance categories, so editors who are willing to perform merges won't be able to find them. This will, of course, reduce the number of articles in the "Articles to be merged" category, but it won't reduce the backlog of articles that need to be merged. They will still need to be merged, even if they're not tagged. DoctorKubla (talk) 21:01, 23 February 2013 (UTC)
  • "(d) it would no longer be possible to add a merge tag without starting a discussion, an annoying practice which is unfortunately far too widespread" - Nonsense, it would still be entirely possible, and would still be routine. Ego White Tray (talk) 19:34, 23 February 2013 (UTC)
You're right, I suppose I wasn't quite sure myself what I was thinking. I've amended the proposal so that my point (d) makes sense. WP:Requested moves had this all worked out long ago; I think we should be following their example. DoctorKubla (talk) 21:19, 23 February 2013 (UTC)
At this point, we seem to be proposing the same thing except that I suggest having approved merges go stale and you don't. Ego White Tray (talk) 05:16, 24 February 2013 (UTC)

An example: Creative use of {{merge}}

I'm working on cleaning up some 40 or so merge tags which were incorrectly put on talk pages, and ran across one that had already been archived. Look at this one, which looks a lot like a requested move discussion: Proposed merger with Rangers F.C. – I've reserved {{Proposed merge}} for future use on talk pages. – Wbm1058 (talk) 20:26, 5 March 2013 (UTC)

Template placement

I think it important that a bot places the merge tags in the same place that they are placed for a multi-merge WP:RM. That is on the talk pages. This has two advantages.

  • The first is that there is a permanent record of the merges kept on the talk page or its archives.
  • The second is that it is far less likely that a merge tag will be deleted manually from a talk page section than it would from the top of article space by an editor who disagrees with the merge proposal.

As a matter of fact when an alternative template that could be placed in article was available for requested moves, it did not seem to attract any amount of attention that a template on the talk page does. This became evident from looking at the responses to such a template. If any interest at all was shown by posting to the section, it was within a couple of days of the initial posting, after that there was next to no postings, suggesting that the responses were to pages on watch lists, not causal editors/readers who happened upon the article while the template was displayed at the top of the article. -- PBS (talk) 13:39, 6 March 2013 (UTC)

I'll have to re-read the above discussion at some point. Maybe this issue has already been covered, but I noticed that the current Wikipedia:Proposed mergers system doesn't routinely provide links from the talk pages of the merge candidates back to the central Wikipedia:Proposed mergers discussion. I've been working on Neighborhoods of Miami-Dade CountyList of communities in Miami-Dade County, Florida and realized that editors could read the merge tags on the articles, and their talk pages, and have no idea that Wikipedia:Proposed mergers#Awaiting consensus even exists. There should be a way of reciprocal linking, regardless of whether the discussions are on a centralized page or (target) article talk pages. I agree with PBS that moving these discussions to the talk pages is probably best. Wbm1058 (talk) 20:31, 22 March 2013 (UTC)

Category:Articles for merging with no partner

Another one: Category:Articles for merging with no partner, populated by {{Merge partner}}.

In the future, if your lovely robut sees a naked merge tag (e.g. {{merge}} or {{merge-to}}, all by itself like that), could it remove it instead of adding a date? Also, it would be just lovely if your bot could also maintain merge tag consistency across articles. For example, if X had {{mergeto|Y}}, but Y did not have {{mergefrom|X}}, SmackBot would tag Y. @harej 12:59, 5 September 2009 (UTC)

Hm, the first one is easy to do and sounds sensible, there is an alternative which is to categorize them into category:Articles for merging with no partner. The second sounds sensible, is hard, but should not be done. This could be used a as a back door to vandalise semi-protected articles. Rich Farmbrough, 16:09, 5 September 2009 (UTC).

BTW, I fixed all ten pages in Category:Articles for merging with no partner. Debresser (talk) 20:08, 22 September 2009 (UTC)

Could you spell out the message, please? It must be a piece of cake after a few joints, but alas, I am a bad Dutchman, and don't smoke. (Nor do I drink beer, or like football.) Debresser (talk) 20:15, 22 September 2009 (UTC)
No, that's fine. You're just English. Peculiar sense of humor. Even for a fellow European. Debresser (talk) 20:20, 22 September 2009 (UTC)
BTW, I have added Category:Articles for merging with no partner to my select group of categories to check daily. Debresser (talk) 11:10, 23 September 2009 (UTC)

I have suggested to SmackBot's author that it should do something different when {{Merge}} does not specify where to merge to. The template should also be adjusted to highlight that it needs an article to merge to. I don't have a specific suggestion on what it should do, but the current version does seem to be ignored by a handful of people. In one case there has even been discussion added when the page has been specified there (where I fixed the issue), but otherwise I just deleted the template [2][3][4], and suggested SmackBot does the same, with a note to the adding editor (which I only did for the only recent merge suggestion). Mark Hurd (talk) 08:21, 22 August 2011 (UTC)

That is an idea. We could start by making it more clear in the documentation, that a merge candidate must be added. Debresser (talk) 16:13, 22 August 2011 (UTC)

The examples already included OtherPage, so that is why my first thought was that the bot(s) that automatically date these templates should handle untargeted templates differently. I have now added OtherPage to the first references as well, and some other updates, including adding these wrong cases to Testcases. Mark Hurd (talk) 09:59, 23 August 2011 (UTC)

This is certainly do-able, although it would require a BRFA since it would be both removing templates and writing to user talk pages, it would also involve digging in history, which the bot doesn't do right now. An quick alternative would be to throw an error if no parameter 1 is specified. Rich Farmbrough, 21:48, 28 August 2011 (UTC).
{{Merge partner}} already does this, placing the articles in Category:Articles for merging with no partner. Rich Farmbrough, 21:50, 28 August 2011 (UTC).
Yes, I saw this issue because of that category (I linked to it above under handful of people). What I saw as a problem was that {{Merge}} templates that don't mention any target don't currently highlight this mistake in anyway (other than this category, which isn't very obvious), and the bot comes along and dates the template as if nothing was wrong.
I've updated the sandboxes of {{Merge}}, {{Merge to}}, {{Merge from}}, and {{Merge partner}} where I added something visible when {{Merge partner}} does its thing and the end of the Mbox needed changing to include the possible output of {{Merge partner}}. You can review the testcases. Mark Hurd (talk) 15:25, 15 September 2011 (UTC)
The two incidents I just covered from Category:Articles for merging with no partner were added using Twinkle. I have notified the developers on the talk page. Mark Hurd (talk) 15:08, 6 November 2011 (UTC)

Wbm1058 (talk) 23:13, 5 March 2013 (UTC)

I'm not sure what the question is here, but in my view, if you see a merge tag with no target suggested, or a non-existent page, delete it immediately. Make no attempt to merge. Of course, if the non-existent page is an obvious spelling or other error, fix it, of course. Ego White Tray (talk) 04:31, 6 March 2013 (UTC)

No question really, just some research I did, analysis of existing systems, FYI and so I have a concise record of this stuff. Wbm1058 (talk) 22:49, 29 March 2013 (UTC)

{{move portions}} and {{move portions from}}

Would anyone object to me redirecting these to {{merge to}} and {{merge from}}, respectively? Those don't necessarily need to refer to full merges; the scope can, and should, be defined on the talk page. Standardization seems wise, especially if automation of merge proposals ever takes off. --BDD (talk) 21:09, 29 March 2013 (UTC)

You think those are redundant, how about {{move section portions}} and {{move section portions from}}? See User talk:Fgnievinski#Template:Move section portions and Template:Move section portions from for the kind of issues you'll probably need to be sure to address. Of course this kind of stuff is distracting me from what you want me to work on. Sigh. I still hope to get to it eventually. Wbm1058 (talk) 22:45, 29 March 2013 (UTC)
I suggest you take all of these to Wikipedia:Templates for discussion. These seem to be used and liked by some editors, so boldly doing it is probably not a great idea. Ego White Tray (talk) 23:29, 29 March 2013 (UTC)

English Setter/Llewellin Setter

Hi, I'm not sure if this is the right place to post, so my apologies if I'm getting this wrong. In October 2012 I proposed that Llewellin Setter should be merged with English Setter. This is the merge discussion. It has recently been brought to my attention that there appears to be overall consensus to do the merge and that I should request an Admin look at it with the view to closing the discussion. I don't know where the appropriate place is to ask, which is why I have landed at this project. Could someone help advise me, please? SagaciousPhil - Chat 08:45, 20 April 2013 (UTC)

The place to ask is at WP:Administrators' noticeboard/Requests for closure – but you don't really need an admin to close a merge discussion, unless you expect it to be particularly controversial. If I were you, I'd just boldly carry out the merge; the consensus seems pretty clear in this case. DoctorKubla (talk) 11:32, 20 April 2013 (UTC)
Thank you! SagaciousPhil - Chat 11:34, 20 April 2013 (UTC)

A general question on merging formalities

Does the proposer have to give a rationale at all? On the other hand, can a proposal just boldy be reverted? Thanks and kind regards, (talk) 21:12, 20 May 2013 (UTC)

First question: No, but may be helpful if the merge is possibly of a controversial nature. Second: a bold merger is allowed, as is a bold revert of the merger. If reverted, a dialogue should follow as to potential outcomes before further merging of content. GenQuest "Talk to Me" 03:10, 1 June 2013 (UTC)

Thank you very much! Kind regards, (talk) 08:19, 1 June 2013 (UTC)

Multimerge confusion

I have previously proposed that QuayWest 107.4FM and Quay West 102.4/100.8 be merged into Quay West Radio (see Talk:Quay West Radio#Merger proposal. I have now discovered The Breeze (Bridgwater & West Somerset). and proposed that all the other three be merged into that one (see Talk:The Breeze (Bridgwater & West Somerset).#Merger proposal, as they all seem to cover the same content, however I have got myself totally confused as to what and how the merger should take place and what templates go where, what should redirect to what etc. Would anyone be kind enough to take a look and try to make sense of this one (and even do the merge if appropriate).— Rod talk 11:13, 11 January 2014 (UTC)

@Rodw: You had everything right for the first 3 Quay articles. The only thing I would have done differently is instead of 3 seperate tags, I would have made one tag for all 3. Ichanged the targets to be the Bridgewater article, so it should all be good not. --NickPenguin(contribs) 18:36, 11 January 2014 (UTC)
Thanks for sorting that. I'll wait & see if there are any comments.— Rod talk 18:43, 11 January 2014 (UTC)

Elimination of backlog at Category:Articles to be merged after an Articles for deletion discussion

This category has been reduced to less than 10 items. As such, I will remove the collaboration section for this on the project page, and instead create an area on the top right to monitor the number of articles in this category. Thanks to everyone who has worked on merging items. --NickPenguin(contribs) 18:40, 15 February 2014 (UTC)

Village pump discussion

There is a discussion that has just been posted at the Village pump that directly effects the merge process here. Everyone should weigh in with their opinion.--Mark Miller (talk) 00:53, 13 March 2014 (UTC)


The merger backlog till November 2010 has been eliminated .We have a reason to feel proud of our cooperation,coordination and hard work and I wish with all these qualities we will be able to clear the whole backlog very soon.Skr15081997 (talk) 13:32, 19 March 2014 (UTC)

History unmerge needed

An editor made a "bold" merger of the constructed Dothraki language and Valyrian language, into what is now Languages of A Song of Ice and Fire, because they were created by the same person for the same TV series. Two of us have rejected the merger. It would have been fine if the articles had been about the use of the languages in the novels/series, but they were instead descriptions of the grammars of the two languages, which do not make a coherent article together – it read as two articles stitched together, rather than as one article, and there was no way to improve it. The difficulty is that the editor merged the page histories, so that when you go through the history, you flip back and forth between one grammar and the other. That should not have been done even if the merger had been appropriate. We've asked him to unmerge them, but no luck. The talk page history might also need to be unmerged, depending on whether both had substantial comment, and it's possible that the article that was deleted to prepare for the merger might should be restored as well, if it had substantial content.

Sorry if this isn't the proper location for the request. I haven't come across this problem for years, since I screwed up an article this way.

Thanks — kwami (talk) 16:29, 2 May 2014 (UTC)