Jump to content

Wikipedia talk:Merging/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

Unreferenced text

Is it appropriate to merge the text of article A into article B, as a result of an AfD, if the text in article A is not referenced? Thanks.--Epeefleche (talk) 06:02, 10 January 2012 (UTC)

  • Well, it depends. If article B is unreferenced or poorly referenced, there's really no problem at all with simply merging in article A. If article B is a well-referenced quality article, it's best to only merge in the referenced material. If there is no referenced material in article A, I would say to redirect without merging, and that the AfD voters were wrong to say merge. This is not a deletion, as the content of article A would still be in the article history and readily available to anyone. D O N D E groovily Talk to me 13:26, 10 January 2012 (UTC)
  • Thanks. The reason for my question is I've noticed a number of merge !votes at AfDs, where the material that the !voter is suggesting be merged is completely unreferenced. It struck me that if we were to merge such material, we would be at odds with our verifiability guideline -- especially as the article has been challenged at AfD.--Epeefleche (talk) 20:12, 10 January 2012 (UTC)
I think you've misunderstood WP:V. A 100% unreferenced article can fully comply with WP:V. What matters is whether reliable sources have ever been published (in the real world), not whether the names of those reliable sources have been typed into the article (yet). WP:V cares whether it would be possible for a motivated editor to find sources that support the article content. It does not care whether any editor has actually done that yet. You might like to read WP:MINREF and WP:PRESERVE for more information, but the short answer is: if you believe (in good faith, using your best judgment) that the material could be supported by proper reliable sources, then you should not be deleting the material merely because it is WP:NOTDONE already. WhatamIdoing (talk) 23:35, 11 January 2012 (UTC)
FWIW, in most of these cases, you probably couldn't find sources. D O N D E groovily Talk to me 00:49, 12 January 2012 (UTC)
  • My concern here is text, in articles nominated for deletion, that is both: a) unreferenced; and b) challenged. Per WP:CHALLENGED, part of our core verifiability policy, "All ... material challenged or likely to be challenged must be attributed to a reliable published source using an inline citation. The citation should fully identify the source, and the location within the source (specifying page, section, or such divisions as may be appropriate) where the material is to be found." [emphasis added].--Epeefleche (talk) 20:14, 21 January 2012 (UTC)
  • Merging is, as I understand it, independent of the challenge/fix/remove process. It is, in my experience, common to merge unreferenced material with CN or other tags, and to continue the resolution of those tags in their new home, unless the target article is at a significantly higher standard (e.g. GA, FA) than the source article. In fact, resolution of such tags (by removal or sourcing) is often sped up as a result of merging. I don't think WP:CHALLENGED implies immediate action: Wikipedia is a work in progress. -- 202.124.75.50 (talk) 06:51, 27 January 2012 (UTC)
  • WP:V is a core policy. To take the affirmative step of re-creating challenged text, in a target article, without the inline citation required by the core policy would not be an appropriate action. It would fly in the face of WP:CHALLENGED, which says: "any material challenged ... must be attributed to a reliable published source using an inline citation."--Epeefleche (talk) 06:58, 27 January 2012 (UTC)
  • Sure, inline citations should be provided, but a reasonable period of time should be provided for doing so. That's what CN tags are for. In particular, there's no reason not to merge while the challenge and CN tags are being resolved. What you are suggesting is that article with CN tags may never be merged: I don't think that would be a helpful change in policy. -- 202.124.74.218 (talk) 11:55, 30 January 2012 (UTC)
  • No -- the guideline is quite clear that any material lacking a reliable source that directly supports it can be deleted immediately. There is no requirement that the text be tagged, let alone as you suggest that any time lapse between the tag and the deletion. That's not the case. Even the application of the tag, rather than the immediate deletion of the text, is simply an editorial discretion courtesy, and one that the guideline makes clear is not required.--Epeefleche (talk) 18:43, 30 January 2012 (UTC)
Yup, it says "you may remove". Not "you must remove". WhatamIdoing (talk) 22:16, 30 January 2012 (UTC)
WP:CHALLENGED uses the word "must". To recreate challenged text at a target merged article -- subsequent to the challenge -- would be to take an action that conflicts with the requirement that such text contain an inline citation. If it makes it easier for some to accept, editors can of course simply delete the text in question. That way there would be no debate, as nobody would restore it without an inline citation. But the guideline clearly contemplates the same chilling effect on recreation of the challenged text, in whatever manner it is challenged (deletion being just one manner of challenge).--Epeefleche (talk) 22:46, 30 January 2012 (UTC)
It says "must be attributed", but it does not say "must be removed from Wikipedia", and it does not say "must be attributed, right this minute, by you in particular". You may legitimately move text as-is from one page to another without violating WP:V. WhatamIdoing (talk) 01:02, 31 January 2012 (UTC)
The very nature of AfD implies that something in the article is challenged, which should be (and often isn't) made clear in the nomination. If we accept that premise, then the nomination will provide guidance on what to merge and what to delete (if the ultimate close is a merge). WP:BURDEN comes into play for the merging editor (and content) in that they need to weigh whether or not the moved (merged) content is subject to the challenge that the AfD was based on to begin with. Simply moving the content to another article does not restart the clock for providing reliable sources, and the material still needs to be neutral, non-original research, and verifiable. The 'extra' attention given during the merge is an opportunity to enforce those core policies. --Tgeairn (talk) 18:41, 3 February 2012 (UTC)

Merge template on an FA

I don't know if this is the venue for such a thing, so my apologies if that is so. Thomas Dörflein has been tagged for merger since December 2011; the article it has been suggested that it be merged into, Knut (polar bear), is a Featured Article. After Knut was initially tagged, with no discussion introduced, I removed it. The original user then re-added the tag and began a discussion here. Although the user has no familiarity with the subject matter, I took the initiative to add more info to Dörflein's article. I then pointed out various reasons as to why the two articles should remain split. It's now been more than a month since they've return to the discussion, and no one else has weighed in. Could this discussion be closed, please? I know that there is an immense backlog, but I believe it's a shame that an FA should be tagged as such. Thanks for any input, María (yllosubmarine) 19:43, 3 February 2012 (UTC)

WikiProject

Please note that Wikipedia:WikiProject Merge has been created. You are invited to participate in the project, thanks. extra999 (talk) 03:39, 28 February 2012 (UTC)

I want a Wikipedia:WikiProject Split! -- Alan Liefting (talk - contribs) 03:52, 28 February 2012 (UTC)

Only for Articles or Not

Hi, I'm asking this question in order to solve a dispute on a local wiki edition. Is merger process intended only for articles (or what else can be merged other than encyclopedia articles)? Can user articles be merged with community consensus? Regards--Alperen (talk) 21:24, 19 March 2012 (UTC)

Various types of advice and help pages could be merged, so it's not just regular articles.
I'm not sure what you mean by a "user article", so I don't know what would be appropriate there. WhatamIdoing (talk) 22:22, 19 March 2012 (UTC)
If you mean WP:Policies and guidelines, the merger process will probably be inappropriate. That page, particularly the Life cycle section, is more relevant. Flatscan (talk) 05:13, 21 March 2012 (UTC)
Actually I mean essays such as this one: Wikipedia:Put a little effort into it. Are these articles discussed, edited like any other policy, guideline etc.? Has there been any merge case for such an essay? (I'm aware that this is a very specific subject).--Alperen (talk) 19:32, 21 March 2012 (UTC)
Essays are generally the opinion of one or maybe two editors, so it usually doesn't make sense to merge them. You could talk to the writers of the essays in question and ask them if they're up for it. D O N D E groovily Talk to me 01:33, 22 March 2012 (UTC)

Withdrawing a merge proposal?

Yesterday I proposed merging Azaouad with Azawad, but the issue was solved when the former article was moved to a new title (Azawagh), a redirect was created, and both articles were substantially rewritten to define their subjects. This has left the merge proposal !votes out of date (and also unnecessary). Is it possible to have my move closed early to avoid any further confusion? Khazar2 (talk) 20:34, 3 April 2012 (UTC)

Confusing instructions

Please can someone clarify step 4 in "Proposing a merger", particulalry this line: After closing the merger proposal discussion, place the following template on the source article's talk page and on top of the source article's main page:. Presumably this would interfere with a redirect, so it can't be correct, or am I missing something? Betty Logan (talk) 20:40, 8 April 2012 (UTC)

 Fixed This was a good old-fashioned mistake. This is only needed on talk pages. D O N D E groovily Talk to me 03:28, 9 April 2012 (UTC)

Extra step in #How to merge

I propose an extra step in Wikipedia:Merging#How to merge and Help:Merging#Performing the merger to go at the end.:

  1. Check the merged content for non-free files. If any of these files are present, edit the non-free use rationales to replace the old article title with the new one. This is required under the non-free content criteria.

I assume most people would do this anyway, but there's no harm in making it explicit for people who might not be aware of this requirement. I noticed this was missing after working through a merge with a non-free image. A similar step is in Wikipedia:Moving a page#How to move a page, and the issues involved are identical between the two processes. Are there any objections to such a step? Regards, Quasihuman (talk • contribs) 18:38, 28 July 2012 (UTC)

Removal of "merge_from" and "merge_to" tags

The process does not explain who should remove the "merge_from" and the "merge_to" tags after the consultation process. I suggest that there be a "Step V" which which contains the following:

  • Perform any mergers for which there was consensus (See instructions below)
  • Remove and "merge_from" and "merge_to" tags in the source and destination artciles.

(I assume that such removals are not done automatically). Martinvl (talk) 06:53, 16 August 2012 (UTC)

Update nutshell description

Could someone please revise the nutshell description? The part that says "For uncontroversial mergers, no permission is needed to merge; just do it. " is evidently out of date; every merge must be bureaucratically labelled and debated for at least a month, or so I'm being repeatedly told. --Wtshymanski (talk) 19:39, 15 October 2012 (UTC)

1. Please see WP:POINT.
2. I just read the relevant discussion on your talk page and encountered no such statement. The dispute pertains to a merger that you performed, which was undone not on a procedural technicality, but due to another editor's belief that it's ill-advised and wasn't properly carried out. In other words, it isn't uncontroversial.
And you somehow arrived at the above determination (which you also posted on your talk page) after you unilaterally reinstated the "uncontroversial" merger and it was reverted again. —David Levy 21:43, 15 October 2012 (UTC)
For good measure, I added a note that any merge that is reverted needs discussion before being restored. Ego White Tray (talk) 01:22, 16 October 2012 (UTC)
A definite improvement. We really do need to be careful about how we word these "nutshell" boxes. —David Levy 01:44, 16 October 2012 (UTC)
But the nutshell is leaving out the multiple tags on source and destination pages, the mandatory month-long debate period, etc. etc. - it's a start, but this "nutshell" guide doesn't seem to summarize the policy as heavily enforced. --Wtshymanski (talk) 02:33, 16 October 2012 (UTC)
Okay, where do I start here? First, there is no mandatory month-long discussion, it simply does not exist, and I don't know why you think there is. Second, the nutshell explicitly says to "follow the instructions below". Third, the policy is not, and never has been, heavily enforced, it's always been pretty loose, and that's the way it should be until we have a better merge system in place. Ego White Tray (talk) 03:07, 16 October 2012 (UTC)
I shall have to point at this discussion when next I'm told of these strict requirements. --Wtshymanski (talk) 03:11, 16 October 2012 (UTC)
Please point to the discussions in which you've been told such things. I'll inform the editors that they're mistaken. —David Levy 03:50, 16 October 2012 (UTC)

Tag deletions

A question concerning best practice. I am not sure if this is the right place to post, but I note that User:Wtshymanski has been deleting a very large number of merge tags from talk pages, and I see some discussion of his merge edits above. In some cases these have been reverted by people such as myself who wanted to point out that a merge discussion was still open, but these reverts are simply being re-reverted. In my case, I posted a question on the editor talkpage, but there was a quick sarcastic response and then the whole discussion was deleted within a few hours. I see evidence from the talk page and contributions that this may be happening more. I take it that the original merge tags must have been in the wrong place, but if an editor has clear evidence that a discussion is open, shouldn't they WP:FIXTHEPROBLEM and move the tag to whatever the right place is, instead of deleting it a second time, or even a first time?--Andrew Lancaster (talk) 10:26, 29 October 2012 (UTC)

I looked at the unmoved mover talk page, and at the time that Wtshymanski removed the tag, there had been zero discussion since December 2011, almost a year. In that particular case, the merge proposal was stale, and I don't have a problem with the tags being removed, nor do I have a problem with someone merging them after the tags are gone. With no comments in nine months, the discussion can not possibly be considered "open", and removing an article merge tag would be equally valid. The revert issue has already been discussed above. Finally, Wtshymanski clearly has a problem with civility, but this is not the forum for that. Wikipedia:Dispute resolution would be appropriate if the revert war is still going, but I'm not sure which forum is best after the old Wikiquette was ended. Ego White Tray (talk) 12:23, 29 October 2012 (UTC)
If a participant in a discussion says a discussion is open then it is open, I would think. Consider WP:DEADLINE. The tags are, I think, meant to help keep track of things. --Andrew Lancaster (talk) 12:30, 29 October 2012 (UTC)
If there's no deadline, then why do we maintain backlog lists? Surely, over (geologic) time all the backlog items will vanish in brilliant prose. "No deadline" should not be an excuse for "no action". --Wtshymanski (talk) 14:14, 29 October 2012 (UTC)
Indeed, why? Does WP editing exist in order to make good backlog lists? You seem to have your priorities around the wrong way, because the aim of WP is to create an encylcopedia. If the apparatus to assist this actually makes editing difficult then it is failing. To repeat, in the example I gave a tag was deleted twice after special mention was made of the fact that discussion was still open. Why go to the effort of re-reverting (and then even deleting talk page discussion about it) when you know the merge tag still means something for the editors of that article? In such a case, why not just WP:fixtheproblem and/or explain where the tag should be? (Or indeed maybe invent some other type of tag for those of us who just want to edit, and who see tags reminders of discussions to guide our editing.) The general impression is that you are doing the job without even attempting to check whether the merge tags should be deleted or not, and/or (judging by your reactions) you feel some sort of disdain for people whose work on WP is of a different nature than your own.--Andrew Lancaster (talk) 15:07, 29 October 2012 (UTC)

Andrew, if there is no comment no something for a long period of time, the discussion is stale, and be bold applies. If a participant said it was open 9 months ago, it's not really open. We're not a bureaucracy and there is no need to wait for a discussion that will likely never be resolved before taking action, whether simply removing merge tags or doing the merge. Wt, when your actions are reverted, you shouldn't re-revert except for obvious vandalism. Instead, relaunch the discussion with properly placed merge tags and notify the appropriate wikiprojects so people knowledgeable can discuss it. Ego White Tray (talk) 02:34, 30 October 2012 (UTC)

This is one of the reasons we have a 12000 backlog in merges alone. The editorial model is supposed to make this less bureaucratic; if Moe comes along and deletes a maintenance tag, maybe Larry or Curly will feel motivated to do something about the issue. There's no point in having a static unchanging list of tags if no-one ever does anythign about it, and re-deleting a tag that was restored without any actual consideration of the problem at hand seems expedient. If no-one fixed the problem after 3 years with a tag, maybe there's no problem, or more likely, no-one cares. I'm dubious at the efficacy of Wikiprojects - yesterday I found 21 merge tags on talk pages, already part of a Wikiproject (for nearly 6 years, in some cases). Putting a tag on an article is not fixing it. --Wtshymanski (talk) 13:37, 30 October 2012 (UTC)
Some discussions take longer than others, and why is that such a problem? I can understand how this can be missed but in this case there was a clear message. The cart, and the horse.--Andrew Lancaster (talk) 21:05, 30 October 2012 (UTC)

I've seen several merge tags on articles as old as 2009 that were added with a single edit comment of "propose merger" and with no discussion being initiated on the talk page of either article being proposed for merger. I think it's safe to automatically delete these tags. WTF? (talk) 16:20, 10 February 2013 (UTC)

Why it is not a guideline?

The "information page" header for this page reads weird: "Please defer to the relevant policy or guideline in case of inconsistency between that page and this one." Isn't it true that we don't have any "relevant policy or guideline"? (If we have one about merging, then WP:MERGE should point there, not here.) Further, it "describes communal consensus on some aspect of Wikipedia norms and practices". If it is a consensus, then it is a guideline, isn't it? Staszek Lem (talk) 23:10, 13 November 2012 (UTC)

WP:AFD isn't a policy or guideline, either, and these are basically the same kinds of pages. WhatamIdoing (talk) 20:01, 14 February 2013 (UTC)

Mergers proposed after a deletion discussion

A keep outcome at a deletion discussion reflects a rough consensus to retain a page. See Deletion process. Deletion discussions generally reach a broader spectrum of editors than a particular talk page. As such, talk page discussions are not on the same footing as deletion discussions. If a deletion discussion that raises merge as an option is closed as keep and an editor then heads off to the article talk page to propose merge, that raises an issue of gaming the system by forum shopping for a venue where only a handful of editors are likely to come across the discussion and alter the retain a page formal consensus. To address this, I added Merger proposed after a deletion discussion. -- Jreferee (talk) 15:01, 13 March 2013 (UTC)

Proposing a merger of multiple articles into a new article

I tried to follow the procedure on this page, but I am unsure to what extend it is properly covers situations where multiple articles are proposed to merge into a new article (because I propose a different name than the earlier names), or did I misunderstand something? See this merger proposal talk which was speedy deleted and I had to quickly (temporary?) recreate in my sand box: User:LazyStarryNights/sandbox#Merger proposal. See my discussion on the deletion as well: Wikipedia:Requests for undeletion#Canary (dance). any ideas? I am investigating a potential other similar merge as well (Angloise, Anglais, and Engelska into Anglaise) and I would like to do it according to "the book". LazyStarryNights (talk) 21:15, 27 July 2013 (UTC)

You may use one of the existing Talk pages. The first note at WP:Merging#Notes anticipates the G8 speedy. I added the note to Help:Merging in 2009. Flatscan (talk) 04:33, 28 July 2013 (UTC)
I copied the merger proposal talk to one of the source pages (Canarie (dance)). Thanks for pointing out this procedure in the footnotes of Help:Merging and Wikipedia:Merging. Because these exceptions are in the footnotes and the article body completely ignores the existence of exceptions, they are easily overlooked (as is evident from this merger). Shall I try to come up with a proposal of how it could be rephrased a bit to make it more clear? LazyStarryNights (talk) 06:21, 28 July 2013 (UTC)
I think that would be an improvement – I knew that a note existed somewhere, but I had to look for it. Flatscan (talk) 04:49, 29 July 2013 (UTC)
I created a proposal for Wikipedia:Merging at User:LazyStarryNights/Wikipedia/Merging. I first copied the original there so it allows for easy comparison. Could you review it?
I could also create a proposal for Help:Merging, but before I spend time on that and with the risk of topic hijacking, I observed that Help:Merging has (a) much overlap, (b) is less nicely structured and (c) used about 4 times less frequently than Wikipedia:Merging so I was thinking more of a merge, but than I saw in this ancient discussion Wikipedia talk:Merging#Merge the MERGE! that it was once deliberately split. Do you know why? I observed that both pages point to each other as "main page". As a newbie I feel this is a bit confusing. LazyStarryNights (talk) 08:37, 29 July 2013 (UTC)
Your draft looks fine. One nit-picky point: when you copy text between pages, you should include a wikilink to the source page in the edit summary, per WP:Copying within Wikipedia. In this case, the source is obvious, so I won't ask you to fix it. When you copy your draft back, you do not have to do this, because the modifications are your own work. Regarding the WP: and Help: pages, the pages do have a lot of overlap after a major rewrite of this page in 2010. WP:Splitting has the opposite problem: Help:Splitting is a redirect, and users find the existing page insufficient (WT:Splitting#Does not actually explain how to split an article.). My opinion is that a combined WP:Merging and splitting should cover "why" and separate Help: pages should cover "how". Flatscan (talk) 04:29, 5 August 2013 (UTC)
Thanks for the comments. I brought the draft live. I knew about the edit summary, per WP:Copying within Wikipedia, but was not aware it also applied for drafts at user pages. I'm planning to have a look into your idea for WP:Merging and splitting after I first did my first attempt ever to split a Wikipedia page. LazyStarryNights (talk) 18:21, 5 August 2013 (UTC)
I would still prefer to merge it (see above). I think in practice, it's better to have one page to consult, than maintain the why v. how distinction. There are two parts of the process, one social (considering the policy/why merge/should we merge, making the proposal, seeing if there's consensus), and one mechanical (copying, doing redirects where necessary, putting the right text in the edit summary), but they are still one process. Superm401 - Talk 22:08, 16 August 2013 (UTC)
I think the Help:Splitting -> Wikipedia:Splitting redirect is okay. It looks like DexDor made some useful improvements to the mechanical procedure at Wikipedia:Splitting#How_to_properly_split_an_article. If that's still incomplete, it should be expanded (and clarified if needed). Superm401 - Talk 22:15, 16 August 2013 (UTC)

Bad instruction: "replacing everything" with one line

In Wikipedia:Merging#How to merge, point 2, we instruct editors emphatically to replace everything in the source page with one line.

That instruction should be limited to redirects without possibilities. Those pages may properly close with redirect template(s) such as {{R from alternate name}}, {{R from misspelling}}, {{R from move}}, etc. Those pages don't belong in article categories --and thus, if i understand correctly, don't need or benefit from {{DEFAULTSORT}}.

For Redirects with possibilities, on the other hand, the instruction should be to replace everything except template {{DEFAULTSORT}} and categories. Many or most redirects that result from merges are redirects with possibilities. Those are tagged with redirect templates such as {{R to section}}, {{R from book}}, {{redirect to joint biography}}, etc; or placed in hard redirect categories such as Category:Redirects from writers.

This has been discussed some at Wikipedia talk:Categorizing redirects, at least in current sections 11 "Most redirects should not ..." and 16 When not to categorize a redirect. See also section 14 DEFAULTSORT, which contains my comment without response.

--P64 (talk) 17:30, 20 February 2014 (UTC)

P.S. The archive of WP:CATREDIRECT talk (cited immediately above) ends with 2010 discussion whether all Redirects from songs should be in article categories. I haven't looked at the 35 sections of older talk. Wikipedia talk:Categorizing redirects#Archive 1
--P64 (talk) 17:48, 20 February 2014 (UTC)

It's a legacy of old software. Some years ago, restrictions in the MediaWiki software meant that only the first line of a redirect page would be processed (and only the #REDIRECT [[...]] instruction and the categories would actually be displayed), hence the instructions on various pages to place the {{R from merge}} and similar templates on the top line after the redirect instruction - that way, their categories would be processed for display. That restriction was relaxed in about 2009 or 2010, after which you could put each {{R ...}} template on a separate line, and also put categories on separate lines as well; but the only displayed items were still the redirect instruction and the categories. Since mw:MediaWiki 1.23/wmf10 (about a month ago), all text on the page is processed and displayed, so that you get a display like the one shown at FUBAR. --Redrose64 (talk) 23:03, 20 February 2014 (UTC)
To replace everything with either of the examples given, however, is to delete template {DEFAULTSORT} and all hard categories --perhaps cut them for paste into the target merged article; perhaps consign them to the void. --P64 (talk) 01:51, 21 February 2014 (UTC)

Father Rale's War

There is a merge tag for Father Rale's War. It has been there since September 2012, and I have an opinion it is 50/50 for the merge. Adamdaley (talk) 02:33, 3 April 2014 (UTC)

I added my thoughts. I wouldn't be in a hurry to merge Grey Lock's War, it seems to me a perfectly fine stand-alone article. Wbm1058 (talk) 03:10, 3 April 2014 (UTC)

Criminal–Crime-for-which-noted

Any thoughts or suggestions out there about some wording to crystalize the best Wiki practice with regard to cover criminals–crimes in distinct articles and when to combine them?

Currently the question seems to turn on guideline questions of

  1. Overlap - "There are two or more pages on related subjects that have a large overlap"--and
  2. Context - "If a short article requires the background material or context from a broader article in order for readers to understand it."

For example, I believe it appropriately that at present there is a single WP article for Roeder–Tiller, a topic that is essentially intermingled. Yet, as wp:BLP1E mentions, in the case of the pair of Hinckley–Reagan WP articles, separate treatments seem to work better than a combined one--after all, there was but a few seconds of confluence between Hinckley's and Reagan's life, with the psychotic wooing of Jodie Foster having zero to do with how the crime affected the Reagan presidency or the life of W.H. Press Sec'y Brady.

Whereas in Mitchell–Smart various threads Mitchell's psychosis and pathology has everything to do with the quasi-Stockholm syndrome experienced by Smart for 9 months as well as all the trials and media coverage (the only thing that doesn't fit in with these threads is Smart's subsequent activism, which is actualy found within her own separate blp.) Likewise, in the Army-of-God militant Scott Roeder – George Tiller, M.D. case, there is nothing yet compiled by Wikipedians about this assassination separate from Roeder's crime and its psychopathology and thus no need for separate articles.

Yet in the case of the alleged so-called "Craigslist Killer" (Markoff–Brisman), Philip Markoff's biography and the murder of Julissa Brisman that he was accused of before his suicide are covered in a single article, fwiw. ......?--Hodgson-Burnett's Secret Garden (talk) 18:00, 12 December 2010 (UTC)

Hi NBSG. This is something I've had cause to think about today and here is how I've concluded it works...


  • Victims of crimes only ever get their name set up as an article title if they have notability independently of the crime (eg Jill Dando, Ronald Reagan).
  • Where the victim of a crime is notable, the decision about whether the crime should be wholly incorporated into their article or should be the subject of a separate article comes down mainly to a consideration of article-length issues, although the relative notability of the event may be taken into consideration (John Hinckley Jr gets an article because the crime he perpetrated was historic and because there's a lot of other important stuff to do with Reagan that needs a mention, but Winona Ryder's shoplifting is incorporated within her article).
  • Likewise if a notable person commits a crime (eg there is not a standalone article for Murder of Lana Clarkson because it looms large in the life of Phil Spector and should not be taken out of that article to make room for a lengthy discussion of Back to Mono).
  • Where one person is notable for committing one crime, that should be covered in one article. The title of the article will normally be the name of the criminal, but may be the name of the event if it is clear that that will be more familiar in the English-speaking world (so: "Murder of Philip Lawrence", even though only one person committed the crime).
  • Where one person is notable for a series of crimes (eg Ted Bundy), there should be a single article whose title will normally be the name of that person, but with the same caveat as above.
  • Where multiple people are notable for participating in one crime, that should also be covered in one article. The title of the article should be the name of the event (eg Murder of James Bulger, Brink's-MAT robbery - but Kenneth Noye gets a standalone article because he is also notable for a later crime and Micky McAvoy has a standalone article but probably shouldn't), unless it is clear that a collective name for the participants will be more familiar in the English-speaking world (eg Lyle and Erik Menendez).
  • Where multiple people are all notable for participating a series of crimes, that too should be covered in one article named after the series (eg Moors Murders), unless it is clear that a collective name for the participants will be more familiar in the English-speaking world (eg Bonnie and Clyde).
  • Where a crime or crimes perpetrated by multiple participants is genuinely so significant that overspill into articles about individual participants and/or different incidents is inevitable due to article-length considerations, this is of course fine (eg Red Army Faction, Charles Manson), Mohamed Atta, Guy Fawkes), but it should always be considered whether this is really necessary or whether there is just too much detail.


IMO that covers most situations in the appropriate way, but please feel free to say if you think I've missed the point anywhere. There is a policy thread running through it (hopefully you can see it), but that took me a long time to type, so maybe I will come back and elaborate some other time. --FormerIP (talk) 02:52, 16 December 2010 (UTC)

IMO I generally agree with what's written above however:

  • there is a point where the individual criminal is know as such, ie a criminal who did this or that, and widely know.
  • Also there is a point were there is so much biographical information available that the size of the resulting biographical article simply makes it unpractical to add into the general article covering the crime.
  • Plus there is also the universal desire to keep the victims unnamed where possible but to name and shame the criminal where possible.

With all that in mind it may be better to have a separate bio article about the criminal first and then secondly an article about the crime. But there should be more discussion about all this. Also the Josef Fritzl case is a good example of how the public's response changes over time from firstly the victim (Josef's daughter) and how she is today, how'd she survive; then to the case (Fritzl case) and its details; to today the criminal himself with several books and documentaries made covering Josef himself and what motivated him and made him become the monster he is. Today I'd say that a separate bio page should exist for Fritzl alone with a second smaller page for the case (also note that the wiki page about the case is very user UNFriendly and difficult to follow. Wombat24 (talk) 09:04, 26 December 2010 (UTC)

Hi Wombat24. Yes, I agree (per the above) that the normal default should be "article title: name of criminal" and then further articles if there is a need due to article size considerations. Exceptions would occur, though, where there is a clearly more common way of naming the incident in the English-speaking world (eg Murder of Philip Lawrence, as noted above). The other case where this doesn't fit is where there are multiple offenders (eg Moors Murders, Brink's-MAT robbery), so in those cases we have a different default setting. That seems to be normal practice anyway.
So, yes, I would say there is a case for titling the main article "Joseph Fritzl" for the Fritzl case, although it's not something I would personally campaign over. I suppose a key issue is that Elizabeth Fritzl gets a lot of coverage in the article (understandably) but maybe there is (understandable) reluctance to give her her own article on the basis that she has become additionally notable as a minor media figure (there has been a lot of biographical coverage of her indepentently of her father). Taking WP:BLP1E one the other hand, a tough one to call, I'd say. --FormerIP (talk) 00:27, 31 December 2010 (UTC)
"the universal desire to keep the victims unnamed where possible but to name and shame the criminal where possible." Note that this is changing significantly in recent years: there is some heavy pushback against glorifying and remembering mass-murderers rather than their victims. From Wikipedia's point of view, this probably means little for now, but may mean redirects from victim names to the crime page, and a higher tendency to place articles under the event name rather than the criminal's name, with the perpetrator's name just a redirect to a #Perpetrator anchor within the event page. The Sandy Hook Elementary School shooting and Adam Lanza are perfect examples of this. Few people now remember Lanza's name: they remember Sandy Hook instead, and this seems to be as it should be. DewiMorgan (talk) 21:34, 7 June 2014 (UTC)

Is 7 days long enough ?

I have recently been on a talk page for Talk:Comparison of orbital launch systems where a merger of about 4 different pages was proposed and closed on 7 days. I am neutral on the merger itself, but do feel that the merger time frame is too short. The proposer (and subsequently also the closer) of the proposal insists it was unanimous and 7 days is all he needed, though other editors feel it was rushed. Basically (and not just for the page in question) is the '1 week' sufficient ? For a fairly larger merger involving a number of pages, why is there a rush ? Surely we should allow a reasonably length of time, and acknowledge that not everyone who may be interested in the pages may, even know of, or even could, visit them within the 7 day time frame, and so a decision can be made ultimately excluding their input. I request that this page (WP:Merging) be amended to reflect this, and this actual length of time be discussed. The Yeti (talk) 15:45, 25 September 2011 (UTC)

The original proposal is the one at Talk:Comparison of orbital launch systems/Archive 2#Merger proposal? As the wording "normally 1 week or more" indicates, one week is a minimum. Considering the merged length of Comparison of orbital launch systems and the number of articles involved, I would have proceeded more slowly. It seems that questioning the legitimacy of the merger discussion (Talk:Comparison of orbital launch systems#Restoring status quo (split), Talk:Comparison of orbital launch systems#RfC: Did the merger of orbital launch system pages happen within policy and with respect to verifiable sources) distracts from the actual issues. Flatscan (talk) 04:18, 26 September 2011 (UTC)
The questioning of the legitimacy is by other editors; however if things had been progressed more slowly, some of the other issues may not have arisen. Anyway, my question here is more general, in that it is asking whether the 7 days minimum is enough for merger proposals for any mergers (or at least those more complicated / with multiple pages)? The Yeti (talk) 23:40, 28 September 2011 (UTC)
In my opinion, 7 days is enough for simple proposals, but very short for anything requiring discussion. Increasing the minimum will unnecessarily delay straightforward proposals from good-faith users trying to follow the rules. Flatscan (talk) 04:47, 30 September 2011 (UTC)
I feel that commenters should be allowed to extend the time, or at least ask for an extension for further discussion. 7 days should be enough time for someone to notice that the deadline is too short, and request an extension. Alternatively, I'd leave a discussion open so long as there's a reasonable number of good-faith comments still coming in, since clearly there is still some discussion to be had at that point. DewiMorgan (talk) 21:39, 7 June 2014 (UTC)

Merge the MERGE!

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus is to MERGE the two articles. — Keithbob • Talk • 21:07, 27 July 2014 (UTC)

WP:MERGE redirects here currently. I propose we simply redirect this page to Help:Merging which is already a how to guide. The general info on when socially to merge can be moved there. It's better than having two parallel instructions. Protonk (talk) 18:15, 24 November 2009 (UTC)

This page was split from Help:Merging in June 2009. With some of the attribution how-to now covered in WP:Copying within Wikipedia, the Help page can be trimmed. However, I would prefer to merge this page and WP:Splitting since they're opposite sides of the same coin – whether to treat a topic in one or multiple articles. Flatscan (talk) 03:57, 25 November 2009 (UTC)
I think this proposal is still valid. Wikipedia:Merging and Help:Merging should be merged. It's very weird, particularly when even individual sections (Wikipedia:Merging#Proposing_a_merger) link to the other one. By vising Help:Merging, I initially missed the key info that template merges are proposed differently. Superm401 - Talk 16:53, 8 August 2013 (UTC)
Another indication of the problem is that both pages use {{main}} to point to the other one. Superm401 - Talk 17:01, 8 August 2013 (UTC)
Agree something needs to be done. FYI:Flatscan and myself have discussed this topic a couple of days ago as well under #Proposing a merger of multiple articles into a new article. LazyStarryNights (talk) 20:57, 8 August 2013 (UTC)
Indeed. WikiProject Merge is still a neglected mess with an impenetrable backlog. Some time ago I was tasked with improving and automating proposed mergers. Of course, that would involve changing the help and how-to instructions. A good first step would be to merge the project's own instructions! If we can't even manage our own instructions, how can we expect to manage article merges? The original 00:43, 10 June 2009 split from Help:Merging and moving pages happened right before that was moved to Help:Merging at 06:03, 10 June 2009. In theory, maintaining separate pages for the rationale and the how to may have seemed like a good idea. The problem is that it's too tempting for other editors to add how to to the rationale and rationale to the how to. Especially since it's a leap to suggest that "Wikipedia:" namespace means rationale and not how to. Anyhow my solution is to implement something analogous to what I did with Wikipedia:Moving a page and Help:How to move a page a couple of months ago, as that solution seems to have been accepted. It will take me several edits to sort out the redundancies and get there. – Wbm1058 (talk) 08:19, 30 August 2013 (UTC)
Agree, but I just want to point out that it's ironic that it is being suggested to merge the article on merging. - tryme1029 (talk) 1:46, 1 December 2013 (UTC)
Indeed. Sigh. I meant to get to this in September. I guess now it's a New Year's resolution. Wbm1058 (talk) 21:02, 11 December 2013 (UTC)
  • Support It is confusing that there are two merging guides. Often when I Google them I get to the wrong one. --Spannerjam 03:42, 21 October 2013 (UTC)
  • Strong Support (and do it quickly!) - no reason to keep two pages on the same content. It is pretty confusing going to a help page on merging and seeing that it has been proposed that it be merged with another page on merging, so it's probably a good idea to get it done soon. Jr8825 • Talk 06:07, 12 January 2014 (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.

Automating the perform

Is there a way? The backlog is around 10k and maybe this is because it's such a pain to do manually. Anna Frodesiak (talk) 00:35, 23 July 2014 (UTC)

Merging talk pages, possibly. Merging content? In some cases, I suppose, it could be automated with appropriate templates. {{merge move to|new article|section number}} and {{merge move here|old article|section number}}, but there are usually so many things that need to be checked. — Arthur Rubin (talk) 00:54, 24 July 2014 (UTC)
Probably the last thing we need are more merge templates, as we are already overwhelmed by them. There is probably a subset of content forks that could be history merged, which is a semi-automated process requiring administrator privileges. A new feature was recently introduced that may help. See A Wikipedia feature I just discovered today - good for history merges. If I had the tools, I might be in a better position to evaluate this. But that will at best only chip away at a relatively small subset of Backlog Mountain. I think the larger issue is the vast number of requests for merging summary style subtopic stubs on the grounds that they will never be expanded to the point where a subtopic article is justified. There is often no consensus on whether a subtopic should be merged, and when there is, it's often left as a job for someone else to do and there may not be a consensus on how much of the stub to merge. Sometimes POV editors want to "merge" an article as a backdoor way of deleting it (see WP:D-R). I don't have enough hard data on this yet and need to get back to my analysis. See #Merge the MERGE!. Wbm1058 (talk) 14:43, 24 July 2014 (UTC)

Special:MergeHistory, a special page that can automate history merges, has recently been enabled on the English Wikipedia. It's currently being discussed on the admin's noticeboard. Graham87 02:48, 23 July 2014 (UTC) – copied from Wikipedia talk:Moving a page. Wbm1058 (talk) 15:00, 24 July 2014 (UTC)

One of our problems is that we have too many different talk pages for discussing merges. Wbm1058 (talk) 15:00, 24 July 2014 (UTC)
Merging page history is used to fix cases where a cut-and-paste move was performed, resulting in two separate page histories where there should only ever have been one. The issue that Anna Frodesiak is of a backlog of article merges, not history merges - cases where we have two articles that have grown up independently and in parallel, and it has been agreed that one article should suffice. A history merge is a very bad idea in such cases, for the reasons described at WP:HISTMERGE#Parallel versions. --Redrose64 (talk) 15:30, 24 July 2014 (UTC)
Thank you, Redrose64. Exactly. I'm sorry to all for not being clear. I was indeed referring to the actual section Wikipedia:Merging#Step 5: Perform the merger. Also, I was unaware that there was a project merger at enwp. I would have posted there had I know. My apologies for that again. So, yes, just some sort of automation with drop down menus or something that could help. I takes ages when not in practice to get the old_id thing right and all. Surely there could be some sort of way to automate some of this. Anna Frodesiak (talk) 00:55, 25 July 2014 (UTC)
OK, no, we don't have anything like that. I was just pointing to what we do have, which, as I said, has limited application in this area. Why the WMF is working on "Flow", and not this, is beyond me. The thing is, that I don't have much idea what the specs for "Flow" are (they may be dynamically changing) and the degree to which it will disrupt current talk page technology. So, at this point, until Flow's operations become more clear, there isn't much point or incentive for creating new semi-automated processes that output talk-page templates, as any efforts in that area could be rendered broken and obsolete by "Flow". I'm referring to the desire to get the old_id thing right. Wbm1058 (talk) 18:17, 25 July 2014 (UTC)
Flow, eh? Interesting point. Hmmmmm. Anna Frodesiak (talk) 21:25, 27 July 2014 (UTC)

Consensus to Merge

I've just closed the merger discussion as consensus to Merge this page with Help:Merging. Would someone like to enact the consensus to merge?-- — Keithbob • Talk • 21:11, 27 July 2014 (UTC)

Is discussion necessary?

I titled the now-longer intro of "Proposing a merger" as "Is discussion necessary?" to make it clear that the answer to this question is "No" (but depending on the circumstances you should do so anyway to avoid some headache). User:Dsimic reverted with the edit summary "Sorry, but to me this title addition looks like twisting the rules". The point of putting it there is to make it clear that there is no "rule" that requires discussion. Is there a disagreement on that point? -- Beland (talk) 21:56, 23 September 2014 (UTC)

To me, the addition of this title isn't something that's beneficial. Having "Is discussion necessary?" potentially suggests that it never is, what does flow together with the founding "be bold" principle, but in my opinion that should be left to the description of "be bold" guideline itself. FWIW, I've never performed a merger before starting a discussion first, as to me it simply seems more appropriate that way. Of course, let's see what other editors think about it. — Dsimic (talk | contribs) 22:18, 23 September 2014 (UTC)
Betteridge's law notwithstanding, the answer to "is discussion necessary?" should be a resounding "sometimes". I appreciate the sentiment of "be bold" here but undoing merges can sometimes be a pain in the ass and mergers which appear obvious often aren't in retrospect. I saw the edits and didn't revert them because I felt the thrust of it is basically ok. We probably should note at the top of the section that mergers can be performed without discussion but in many cases you should discuss it first, as editors can be prickly when something they've worked on becomes a redirect. Protonk (talk) 23:20, 23 September 2014 (UTC)
I think we do note that; not sure if you're for or against the header. -- Beland (talk) 15:10, 25 September 2014 (UTC)
  • I'm a bit concerned that instruction creep will reduce the number of merges performed successfully. I do a lot of merges that I find obvious, with no prior discussion, and no subsequent complaints. I also find a lot of articles that either need to be merged but I don't have the time, or in a smaller number of cases I'm not sure about. These I usually tag for merge and don't come back to. I'm not really interested in hanging around for days or weeks to deal with an article I didn't really care all that much about in the first place, so I assume someone else will merge it eventually if the discussion supports doing so. I definitely agree that we shouldn't encourage editors to merge articles in ways that will be controversial, cause bad feelings, or take a lot of work that is wasted. But probably the larger problem is the long backlog of unmerged articles, which a non-lightweight process makes a bit worse. -- Beland (talk) 15:10, 25 September 2014 (UTC)
Well, if we're worried about instructions growing too large, what's a totally reasonable concern, then having fewer sections and no additional headers is a good thing, right? :) Personally, I'd never do a merger before starting a discussion first, as someone had invested a lot of time into creating an article that's going to be merged; in case I wouldn't want to spend some time waiting for the merger discussion to grow or to "die off", then I'd feel like not respecting the time and effort other editors have invested earlier. Sure thing, there's no ownership of articles, but there should be enough respect. In other words, if I don't care enough about a particular article, I'd leave it for other editors that care more about it. — Dsimic (talk | contribs) 17:27, 25 September 2014 (UTC)
The instructions about how to hold a discussion are needed; what I was trying to do was make a clear "skip the rest of these instructions" opportunity for appropriate cases, which can save a lot of reading. -- Beland (talk) 20:44, 29 September 2014 (UTC)

I think we should excercise common sense in deciding whether a merge is so evidently needed that it doesn't require discussion to be done. Yesterday I merged Android Cloud to Device Messaging (a single paragraph article) into Google Cloud Messaging (another single paragraph article about a technology that was the evolution of the previous, which in turn was rendered obsolete), and I honestly didn't think it was necessary to ask anyone whether it should be done. --uKER (talk) 20:02, 25 September 2014 (UTC)

@Dsimic: So, it seems clear discussion is not necessary in all cases. But we don't want to make that too clear by adding the section back? (We disagreed in edits whether it should be added back.) -- Beland (talk) 00:55, 1 November 2014 (UTC)
Yeah, the discussion isn't required in obvious cases, and can be skipped following the "be bold" rule. However, in my opinion the subsection shouldn't be added back as it might induce "no" as the mental response from people who will be reading it. That way, people might simply skip the description and take "no" as the general rule. That's my opinion, FWIW. — Dsimic (talk | contribs) 01:07, 1 November 2014 (UTC)
@Dsimic: Would you prefer it to be phrased "When is discussion necessary?" or something else? -- Beland (talk) 15:37, 1 November 2014 (UTC)
In my opinion, it would be the best not to have additional subsection at all so people don't just "skim" across subsection titles. What might be an alternative to having a subsection is bolding the sentence "If the need for a merge is obvious, individual editors can be bold and simply do it.". That should make it more easy to spot that a discussion isn't necessary in some cases, counter-balancing at the same time "Step 1/2/3/4" subsection titles below. Thoughts? — Dsimic (talk | contribs) 21:39, 1 November 2014 (UTC)
Done. Good enough for now. -- Beland (talk) 21:30, 3 November 2014 (UTC)
Great, I'm glad that we've reached some kind of a compromise. — Dsimic (talk | contribs) 22:49, 3 November 2014 (UTC)

Strete Gate

Hi. Please take note about this Merge-Discussion please. Thank you & Regards. Gary Dee 10:29, 19 August 2015 (UTC)

Confusing instructions: "How to merge" - and "Is this a record?"

I've just done a merge, having rarely done so before, so was trying to follow the instructions. But it's very confusing!

At "How to merge" there are a set of instructions ... followed by two separate sets of instructions, for "Full content paste merger" and "Selective paste merger". Are these three parallel sets of instructions, or are (as it seems to me) all merges either "Full content paste merger" or "Selective paste merger"? I worked through the instructions in the first set, then realised that "Full content paste merger" applied so had to check to see whether there were any differences. Not very user-friendly.

Incidentally, I was merging two articles on one man which have co-existed since February 2006. Are there any records kept for the longest-standing undiscovered duplication in the encyclopedia? (Peter McDonald (critic) and Peter McDonald (poet) - see Talk:Peter McDonald (critic)#History of a merger. PamD 21:34, 17 November 2014 (UTC)

Furthermore, we say in the first set of instructions (section 4.0, before the first subsection),
3. Reconcile talk page tags. ... [subpoint two]
... In most cases, you must transfer any WikiProject template unique to the source page ... Delete any WikiProject template that does not get moved.
We don't want that now, if ever we did. More or less "No, don't delete redirect talk page banners" I advised or urged somewhere last month and User:Paine Ellsworth provided more explanation in support, with advice to put some template above the talk page banners. I don't find that now and hope Paine will.
--P64 (talk) 20:50, 3 October 2015 (UTC)
When a merge results in a redirect, the {{Talk page of redirect}} template can be placed at the TOP of the redirect's talk page to, sort of, soft-redirect the talk page, to inform readers that the talk page is pretty much unwatched so they should post on the target article's talk page, and a link to the merged page's history to preserve attributions. Any banners that are on the talk pages should be "reconciled", that is, the same projects should be represented on both talk pages. On the redirect's talk page, the |class= parameters in all the banners should be reset to |class=Redirect. Thank you for pinging me, P64, if you want to make any needed changes to clarify or to reorganize (PamD's comment about user-friendliness above), that would help a great deal! Paine Ellsworth (talk-contribs)  01:12, 4 October 2015 (UTC)
@Paine Ellsworth and P64: Hi, guys. I am yet to see a WikiProject that supports a redirect class in its scope. But if you know any, you can change the |class= of that WikiProject instead of deleting its template. I will update the page to reflect this. Do you know of any WikiProject that supports redirect class? Best regards, Codename Lisa (talk) 08:43, 4 October 2015 (UTC)
To editor Codename Lisa: I come across several almost everyday, such as {{WikiProject Television}} (example). More than half the banners I see and set |class=Redirect default to "NA class", but a seemingly growing number of banners support the Redirect class. Another important reason to set the class equal to "Redirect" in all banners on talk pages of redirects is because of the automatic nature of some WikiProject templates. If they're placed on the talk page of a template redirect, then they'll auto-sort to "Template class" unless "class=Redirect" is set. Project pages and the like will do the same thing. So it's important to use "class=Redirect" even if the sort is to "NA class". One never knows when someone might upgrade the project banner to support redirect class. Paine  (talk – contribs)  02:22, 5 October 2015 (UTC)
To editor PamD: Your question about whether or not 2006 is a record is interesting to me because I have had the same thoughts about page moves. Almost daily I come across redirects that are the results of page moves and that have not been tagged and categorized as such. The dates of the page moves vary, of course, and the earliest I've come across was in 2001, so when I found that back in 2013 it had been tagless for 12 years. To get an answer to that question you might try the Village pump (technical) page, where they will be able to tell you if such a history check is possible. They might even know someone who has already used a bot to check category entries, so you wouldn't have to reinvent the wheel. Joys! Paine Ellsworth (talk-contribs)  01:32, 4 October 2015 (UTC)

Wikidata

Hi. Shouldn't there be some advice on sorting things out at Wikidata after performing a merger? Sander1453 (talk) 04:53, 7 October 2015 (UTC)

Hi. I have the same question too. Best regards, Codename Lisa (talk) 13:04, 7 October 2015 (UTC)

European Rugby Champions Cup

I'm concerned about the way Heineken Cup was merged into European Rugby Champions Cup. Since the ERCC is effectively a continuation of the Heineken Cup (despite the two competitions being run by legally distinct entities), the latter article has largely been copied and pasted from the former. Because of this, the history of the former article has been lost. Should the histories of the two articles be merged? – PeeJay 21:07, 3 November 2015 (UTC)

reason = parameter in merge template

In my experience to date, mergto templates rarely have a reason offered on the talk page. Did I say "rarely", I meant pretty much never ever. As such why don't we add a reason = parameter to the template? Maury Markowitz (talk) 13:33, 8 November 2015 (UTC)

Veiled Rebecca

Hi, what's the best way to proceed with the merge mentioned on this page? I'm not sure if I should go ahead with a copy and paste or if there is a better way to do this that preserves the history of both pages. All this talk of cut&paste merges vs. history merges has me confused. Thanks.--Cpt.a.haddock (talk) (please ping when replying) 12:50, 20 November 2015 (UTC)

Twinkle support - does it really exist?

Template:Merge says that it "is used in the standard installation of Twinkle." but I can't figure out how to get Twinkle to use it. So I did this which I'm thinking of self-reverting. Is Template:Merge wrong? If so, how should this be corrected? In other words, how do I merge via Twinkle, and can we better document that here? --Elvey(t•c) 14:46, 4 January 2016 (UTC)

Twinkle offers support at the level of tagging articles to suggest merge - from the dropdown menu pick "tag", then "merge", "mergeto" and "mergefrom" are all options: the last two ask for the name of article to merge to/from. PamD 16:01, 4 January 2016 (UTC)
Yea, that's a problem. Making it too easy to tag for merges means we have an epidemic of proposals. I'm fine with tagging obvious content forks this way; summary-style judgments, not so much. There really needs to be discussion of the rationale for these, and I don't think that semi-automated tools encourage that. Most recently, it took 13 months to work through one single month of the Wikipedia:WikiProject Merge backlog. Wbm1058 (talk) 18:36, 4 January 2016 (UTC)

Merging as a process is a problem....

We have a serious problem with MERGE. There are currently 11,172 articles in Category:All articles to be merged. That number is going to keep going with the trend to merge at AfD. According to Category:Articles to be merged, there are articles from May 2012 that need to be merged. I am aware that there are pages where discussion is ongoing/recently started, but five years is a totally different matter.

With a smaller active userbase, and a lot more articles, consensus for processes is a lot harder to come by in a reasonable amount of time in general. For example, I AFDed Supercute!. I got no consensus (and actually, no participation) after a month, and the NAC suggested either renom or merge, so I figured I'd set up a merge discussion and see what would happen. I have had no comments on it in a few weeks, and no one has edited either article in years. AFAIK, I can't simply close out the discussion and do it myself, because there's no consensus to do so. I have also been AfDing other material, and a lot of what is happening is malformed merge requests - somebody dropped the template on the source, but never set up the discussion on the target. I'm not sure how widespread it is, but clearly you can't merge a page if no one knows about it.

This "stagnation of merge" is a problem at AfD, because people are voting merge on articles just because there's one piece of potentially useful information. However, when the merge isn't executed, it's effectively a default keep. I know exactly what the problem is, and that's that the needs of the licensing make the merge process complicated, and it's easier to do it wrong than do it right. I've read it over several times, and I'm still not sure how to do it, or in what manner to do it. However, by not doing it, we're effectively violating community consensus and somewhat breaking the encyclopedia. Is there some way we can make merging easier, either with an automated tool to do it, or a different process to get to a position to merge? MSJapan (talk) 21:03, 20 June 2016 (UTC)

Actually you can be bold and merge the article. If someone reverts you, then you need to gain consensus, but until that happens you are free to merge the content. There is no discussion required for you to merge two pages together, if it seems obvious to you then do it. As for your example above, you have two discussions showing that no one seems to care about the article. Do a quick merge, redirect Supercute! to Rachel Trachtenburg and be done with it. -- GB fan 10:54, 21 June 2016 (UTC)
On a positive note, the current 11.4k merges is better than Nov. last year (at 12.4k) and better than the 2010 level (16.5k); also, May, June and July are now clear, so its August 2012 that is the earliest. So, under the 4-year mark now, and I recon we should push to a 3-year tail over the next 12 months. With these 3-4 year old proposals - be bold! Klbrain (talk) 11:55, 21 June 2016 (UTC)
PS:No disagreement counts as 'consensus' in my books, as long as adequate time has been left for those with an interest to respond. Klbrain (talk) 11:56, 21 June 2016 (UTC)
Well, I executed the Supercute! > Rachel Trachtenburg merge, but as it's my first one, can someone make sure I tagged everything adequately? MSJapan (talk) 06:27, 23 June 2016 (UTC)
Your redirect and templates look fine to me, as does the merge itself. Klbrain (talk) 15:32, 23 June 2016 (UTC)
I think you did everything right. The only thing left to do is remove the circular links in Rachel Trachtenburg. There are at least two links to Supercute! that links right back to Rachel Trachtenburg, one in the lead and the other in the infobox. -- GB fan 15:36, 23 June 2016 (UTC)
Done. MSJapan (talk) 05:48, 24 June 2016 (UTC)

Do we merge unsourced content?

This seems to be coming up in AfDs, where fully unsourced articles are being merge-voted, but AFAIK, the "removal of unsourced content" idea should preclude that. IMO, one cannot dump unsourced material into another article, because one is not improving the article that way. However, there is no statement either way in the merge guidelines. What's the usual practice? MSJapan (talk) 18:22, 28 June 2016 (UTC)

You've confounded your point given that WP:V does not require sources.  It requires verifiability.  I suggest that you restate your contention without this confounding element.  As for usual practice, WP:V is a core content policy which all editors should normally follow.  Unscintillating (talk) 22:57, 28 June 2016 (UTC)
On a pratical level, preventing a merge until all material is verified (WP:V) would paralyse the merge process. WP:FMERGE does not require verifying material before a full-content merge. If there are concerns about any content then these can be tagged in the usual way. Merging is a distinct process from creating new content. Klbrain (talk) 11:54, 30 June 2016 (UTC)
I'd say that it all depends on who actually performs the merger. I've never (neither I would've ever) merged an article I'm not familiar with, so I've always been able to either "weed out" any misleading content, or to provide references where needed. — Dsimic (talk | contribs) 12:05, 30 June 2016 (UTC)
It is always better for an expert to merge. However, if the page has been awaiting an expert for 3 years, with a clear agreement that a merge is needed, I think that it is right to be BOLD while also being a CAREFUL non-expert. Klbrain (talk) 10:03, 2 July 2016 (UTC)

Entry

Do you support this entry? Pwolit iets (talk) 10:20, 30 August 2016 (UTC)

Semi-protected edit request on 21 December 2016

2602:306:CC81:E0B0:2C81:AE57:AFCD:C2B4 (talk) 18:23, 21 December 2016 (UTC)CrissyCarter 

2602:306:CC81:E0B0:2C81:AE57:AFCD:C2B4 (talk) 18:23, 21 December 2016 (UTC)
Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. 🔯 Sir Joseph 🍸(talk) 19:41, 21 December 2016 (UTC)

Confusing text in "How to merge, step 3": 3/10/17 UTC

Hi! I'm confused about something in this sentence:

Once the copying is done, make sure the WikiProject templates have a |class=redirect parameter-value pair.

Which WikiProject templates is it talking about: the ones on the source page, the ones on the destination page, or both?

Note: I have just done a merge, merging Hangwa (yugwa) into Yugwa, and this step has not been done yet due to uncertainty about this step.

Thanks! Noah Kastin (talk) 09:13, 10 March 2017 (UTC)

@Noah Kastin: That's a good question. If the original article was identified on its talk page as being part of a WikiProject (i.e. it had a WikiProject template placed there), those templates should remain on the old talk page, but have the class parameter changed to redirect (from say stub or start or C). For example:
{{WikiProject Food and drink|class=start|importance=low}} would become:
{{WikiProject Food and drink|class=redirect|importance=low}}.
Also, any of those templates on the old talk page should be merged to the new talk page with the original stub/start/etc. value left in place. Looking at your articles, I see Talk:Hangwa (yugwa) had no WikiProject templates, so you don't need to worry about. --Mindfrieze (talk) 15:17, 10 March 2017 (UTC)
Thanks for the answer, Mindfrieze! Should the text in the sentence I brought up (the subject of the discussion) be changed to make this clearer? Maybe something like this would be good:
Once the copying is done, make sure the WikiProject templates for the source article have a |class=redirect parameter-value pair.
This way, it would specify that the affected templates are for the source article only, not
  1. both the source and the destination article or
  2. the destination article only.
Thanks again!
Noah Kastin (talk) 01:20, 11 March 2017 (UTC)
@Noah Kastin:, that sounds like a reasonable change. Please feel free to make the edit yourself. --Mindfrieze (talk) 02:17, 11 March 2017 (UTC)
Thanks, Mindfrieze! I just did the edit, per your suggestion. Thanks again! Noah Kastin (talk) 02:29, 11 March 2017 (UTC)

Tide (time)

turns out to not actually exist, apart from hours and canonical hours. The non-hoax aspects of the page will be merged to the proper page at Canonical sundials.

Is it worth merging its edit history there as well or should the page's redirect to Hour just store the edit history about the non-existent unit? — LlywelynII 09:21, 16 March 2017 (UTC)

I don't think that a history merge is necessary, particularly given that several of the earlier edits were to poor sources; better kept where they are. Klbrain (talk) 13:51, 16 March 2017 (UTC)

When to request a histmerge

The current instructions (step 9 of WP:FMERGE) say that a WP:HISTMERGE should not be requested in any situation, with the explanation given (via a link) at Wikipedia:How to fix cut-and-paste moves#Parallel versions. However, this rationale only applies to the cases when the two pages have parallel editing histories. Is there any reason to avoid a history merge when there is no such overlap in editing histories? Just noting that this part of the instructions dates all the way back to 2009 [1] – Uanfala (talk) 17:19, 20 May 2017 (UTC)

I don't see a problem with hist-merging if there is no overlap, but this probably requires some administrator-judgement on a case-by-case basis. wbm1058 (talk) 17:54, 21 May 2017 (UTC)
Maybe then the instructions could be modified to allow for the possibility of a histmerge? Currently they read as:
Afterwards, DO NOT ask for a history merger between the two articles. See this link for the reason
Should this instead read as:
Afterwards, DO NOT ask for a history merger between the two articles unless they have no overlaps in their edit histories.
Any thoughts, wbm1058, Anthony Appleyard? – Uanfala (talk) 00:50, 27 May 2017 (UTC)
  • @Uanfala: This seems to be the case of people asking for history-merge after text-merge. People often do that. In my opinion, there should not be a history-merge here, as there was not a single complete cut-and-paste event leaving a blanked or redirected page AND ALSO creating a new page. For attribution, put a history note in the starts of the talk pages of the affected articles. Anthony Appleyard (talk) 04:48, 27 May 2017 (UTC)
  • @Uanfala: Sometimes people ask for a histmerge where there has not been a cut-and-paste event. Sometimes this is where the 2 articles are about the same topic. For example :: Someone writes an article about a forthcoming movie, called (say) Murder in Zxcvbnmtown. It is deleted {{db-crystal}}. Later, the movie comes out and someone else writes a new article Murder in Zxcvbnmtown (2019 movie) about it. There may be point in undeleting the first article and histmerging it with the second article. Best treat each request as a judgement case. Anthony Appleyard (talk) 10:46, 27 May 2017 (UTC)
Thank you for your reply, Anthony Appleyard. I'm here mostly because I find myself unsure when to request a histmerge after merging two articles. So for example is the merge of Suba Language into Suba language one that doesn't require a history merge? – Uanfala (talk) 11:15, 27 May 2017 (UTC)
That particular example is an editing scenario I've seen before, and is the sort of thing that I, sorry, find rather annoying. Djh224 the author of Suba Language (which by the way violates Wikipedia WP:NOUN; use sentence case) is a self-declared student editor: Wikipedia:Wiki Ed/Rutgers University/Languages in Peril Section II (Spring 2017). Djh224 created a content fork. I can see how it would be easier to grade a new creation than to grade improvements to the work of others, but the professors making these assignments just need to deal with that. This was just moved to main-space on April 30, which happens to be the last day that editor edited. It looks to me like they just "turned in their assignment" by moving it to mainspace, and we may never see them again, now that the semester is over. This is abuse of the good will of volunteer editors, who are left to do the merging and clean up. Someone needs to explain this to the professors so that they stop giving out student work assignments like this. Suba language dates to 24 October 2004, and was started by copying text from the article that is currently titled Suba people (Kenya). So, no, there is nothing to history-merge here. – wbm1058 (talk) 14:16, 27 May 2017 (UTC)
I don't think I share your general annoyance, but the issue has been brought up at Wikipedia:Education noticeboard/Archive 16#Proposal for update in the student instructions for moving drafts into mainspace and a solution is likely to be underway. – Uanfala (talk) 14:43, 27 May 2017 (UTC)
Oh, I see. I just took a closer look at this. Thanks for the link to the education noticeboard. To be clear, my annoyance is not with the students themselves, but rather with the professors and/or the people who are behind the effort to integrate contributions of this sort into the encyclopedia. They should have thought this through, before unleashing it. You shouldn't have to do cleanup, and as you pointed out, things can and will go wrong... i.e., contributions submitted this way are just asking to be deleted. And they wonder why they have an editor retention problem.
Now, back to the question of merging. You can either copy-paste merge, or history-merge, but these two merging techniques are not compatible! There is more than one way to get this job done, but the method you pointed out is not among the best methods, due to the problems you pointed out.
I understand the desire to have students work in their sandbox, so they can maybe get local feedback and help before anonymous editors from far away start reverting their rookie mistakes. In doing so, they build up an edit history in their sandbox. If the student themselves is the only editor in their sandbox history, they could just copy-paste their final sandbox version that they deemed "ready for publication" to the properly-titled existing article. Someone supervising Wikipedia:Wiki Ed/Rutgers University/Languages in Peril Section II (Spring 2017) should never have assigned that student to work on Suba Language, they should have made the assignment to work on Suba language. The professors should be familiar with article titling policy, and should use due diligence to determine whether a stub article on the proposed topic already exists.
Back to the question of history merging. If you don't mind my deleting the five May 2017 edits to Suba language (I would actually move those to a subpage of this talk page), then I could history-merge Suba language into Suba Language, then move Suba Language to Suba language to get it back on the proper title. And we could revert the "removal" of content that existed before April 30. – wbm1058 (talk) 15:38, 27 May 2017 (UTC)
In other words, the "cut-paste" move we would be rectifying would be the "cut-paste" from mainspace to the student's sandbox, even though they did not actually cut-and-paste anything. wbm1058 (talk) 15:45, 27 May 2017 (UTC)
I got the impression that the Suba language pages weren't suitable for histmerging. But if they are, you're welcome to carry that out (I've got a backup of the last five edits to Suba language and wouldn't mind reintroducing the changes after the histmerge is done). – Uanfala (talk) 16:13, 27 May 2017 (UTC)
You were asking a general question without giving a specific example, so you got a general answer. We can't hist-merge Suba Language into Suba language as you suggested, but we can merge Suba language into Suba Language, though that's easier if it's done before any copy-pasting. One or the other. This isn't the typical hist-merge to repair a cut-paste move, though, so trying to make this the "routine and normal" way of doing things is going to be problematic, as with the forks where the fork is deleted or redirected without copying and merging any content. You may get different results depending on how much the admin you're asking is aware of the specific details of the situation. I can do this as a one-off, but if this technique is to go mainstream, then better instructions and processes need to be implemented so this scenario is handled consistently and smoothly. wbm1058 (talk) 16:55, 27 May 2017 (UTC)
Actually since Suba Language was started at 01:30, 24 January 2017 (beginning of the Spring semester), we have overlapping history during the entire duration of the semester. So we could merge everything up to 08:54, 21 October 2016. As it happens, there was only one overlapping edit during the semester, at 15:27, 7 April 2017 Katherinemoretti, another student in the same class, "updated grammar". So if we hist-merge, we lose that edit, but I suppose you could make the same update. Obviously a hist-merge would be a real issue if there had been a lot of intervening live edits to the article during the months between late January and early May. I'm having second thoughts about this. It would certainly look odd to see that the edit that converted a stub to an even lesser stub wasn't immediately reverted, though the sandbox tag makes it clear what was happening. – wbm1058 (talk) 17:24, 27 May 2017 (UTC)
Well, my initial concern was mainly with the discrepancy that I thought I saw between the instructions and what I thought was the usual practice. One-off instances like Suba Language aren't really worth the fuss. And I agree with your last point: if the two are merged then the history of the resultant article would really look odd. – Uanfala (talk) 18:58, 27 May 2017 (UTC)

Technical question

Two articles are to be merged. Topic 1 is the correct name, but has less content and less discussion on the talk page than Topic 2, which has far more good content and more discussion on the talk page, but a less suitable name.

How best should these be merged?

  1. Merge Topic 1 into Topic 2 is straightforward, but leaves the article with the wrong name. Moving the merged article into Topic 1 requires merge without redirect, which as far as I know requires admin intervention, or deletion, with same problem. I have no idea of what actually happens with the page histories, but they must go somewhere.
  2. Merge Topic 2 into Topic 1 is more work, and may leave a more confusing talk page history, but at least puts the new merged article into the correct name.
  3. Some other method I have not thought of yet?

Advice requested. Cheers, • • • Peter (Southwood) (talk): 12:40, 6 June 2017 (UTC)

This looks like it might be a similar problem to that described in the previous section, but as I have no understanding of what happens in a histmerge, the previous discussion just leaves me confused. • • • Peter (Southwood) (talk): 12:51, 6 June 2017 (UTC)

I would certainly merge Topic 2 into Topic 1, on the grounds that the best final page is the main priority. Leaving a merged-from template on the Topic 1 talk page gives a link to the previous talk page, and the histories remain traceable for anyone with an interest. Klbrain (talk) 23:28, 6 June 2017 (UTC)

Discussion

There is a relevant discussion pending on Template talk:Merge#Adding criteria to template itself. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 16:58, 14 August 2017 (UTC)

"How to merge" step 3?

The first bullet point under "How to merge" step 3 says Move all {{Merge-from}} and {{Copied}} templates to the destination page's talk page. {{Merge-from}} is the template used for proposing a merger, and it wouldn't make sense to move that to the talk page. We'd wanna remove that once the merger's been done. And no {{Copied}} templates have been used till this point, so there aren't any to move.

Is this supposed to say to create (not "move") either a {{Merged-from}} (not "{{Merge-from}}") or {{Copied}} template? (And on that note, could it include a discussion of the differences between the two?) Languorrises (talk) 00:31, 4 February 2018 (UTC)

Great that this significant problem has been identified. I agree that this section, as currently written, doesn't make sense; agree that it should it read create (not "move") either a {{Merged-from}} or {{Copied}} template. Differentiating between the two would also be helpful. Klbrain (talk) 15:11, 4 February 2018 (UTC)

Post-AfD move review for Paradisus Judaeorum

Paradisus Judaeorum, renamed per Wikipedia:Articles for deletion/Heaven for the nobles, Purgatory for the townspeople, Hell for the peasants, and Paradise for the Jews is currently in discussion at Wikipedia:Move review/Log/2018 December, and may interest watchers here.Icewhiz (talk) 07:16, 11 December 2018 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Merging/Archive_2&oldid=1142664521"