Wikipedia talk:Merging/Archive 1

Archive 1

Archive 2

Archive 3

Archive 4

Contesting a merger

Help! I can't find any instruction anywhere about how to delete the proposed merge of two articles when it is clearly inappropriate (e.g. "3-D Film" keeps asking to be merged into "3D Display"). Can I simply delete the relevant marker in the article? —Preceding unsigned comment added by AlatarK (talk • contribs) 05:38, 20 January 2010 (UTC)

I would usually recommend that the discussion be given time to develop before removing the tags. However, I see that Talk:3D display#3D vs. 3-D has had no activity for a few months, so you can remove the template that's been bothering you. Flatscan (talk) 04:42, 21 January 2010 (UTC)

Comments requested

For anyone watching this page, I'd appreciate your comments on my tentative proposal at Wikipedia talk:Articles for deletion#Proposal: when !voting merge, add a notice at the proposed target.  Glenfarclas  (talk) 07:18, 4 February 2010 (UTC)

Refining the definition of "merger"

Please see Help talk:Merging#Refining the definition of "merger". -- Black Falcon ^(talk) 04:44, 3 March 2010 (UTC)

Comment requested

I seek guidance regarding the merge of Istanbul and Istanbul Province. The city has grown so much that now its boundaries are now legally the same as Istanbul Province. If both articles on these two geographical entities were to develop to their full potential, they would differ only in terms of their history and administration. Everything else, such as geography, culture, climate, economy, transportation etc. would be identical. I am inclined to combine these articles and have the merged article explain distinct and identical aspects of the two topics. However, it can be argued that the city and province are distinct subjects and need their own articles as do all cities and all provinces of Turkey. The guidelines given in the Merging page seem to give support to both points of view. --İnfoCan (talk) 16:35, 14 August 2010 (UTC)

Merge templates

Is there a template for {{merge underway}} or {{incomplete merge}} ? I've come across some pages that have been in the process of merging, so it would be good to have a tag for it, {{underconstruction}} seems wrong, since an expansion is not underway. While it is a reorganization, the data is being moved elsewhere. 65.93.15.125 (talk) 22:02, 22 February 2011 (UTC)

No separate templates, as far as I know. I think {{underconstruction}} works well enough for the destination page, and editing done at the source page will be mostly removals, which are faster. Flatscan (talk) 05:10, 22 March 2011 (UTC)

Section 3 performing the merger

For the third step in section 3 Performing the merger, an edit is needed for better clarity and the tag needs to be corrected.- {{Copied|from|from_oldid|to|diff|date} " should be {{Copied |from= |from_oldid= |to= |diff= |date= }} Also, there should be some sort of explanation as to how to fill in the parameters, or else a reference to Template:Copied for further explanation. Gmcbjames (talk) 23:52, 5 August 2011 (UTC)

Cruddy merge process

Hello. Only done a couple of mergers, but it's a pain in the ass even to do something simple and get it right. Is this even a question that should be asked of other editors, or is it a question for the Foundation? There's various legalese about requirements to preserve history, yadda, yadda, but the current, um, "process" seems almost designed to caused failures along the way. To sum up: doing a merger should not make me hate Wikipedia. --Hobbes Goodyear (talk) 04:26, 15 November 2011 (UTC)

The relevant guideline is WP:Copying within Wikipedia. The short answer is that the steps that provide attribution are required. I can help with those mergers if you need assistance. Flatscan (talk) 05:19, 15 November 2011 (UTC)

"a reasonable amount of time"

Our reason to merge (3) states: "If a page is very short and is unlikely to be expanded within a reasonable amount of time, it often makes sense to merge". I'd like to remove the "a reasonable amount of time" part, as it is ill-defined. What is reasonable? A week? A year? How can we determine when will a given article be expanded? If an article is unlikely to be ever expanded, and is not notable in its own right, it should be merged. Otherwise, it should remain for however long it takes for it to be developed. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 17:46, 23 November 2011 (UTC)

I see it as a balance between WP:TIND and WP:CRYSTAL. Keeping stubs separate and merging them are both valid approaches, and I prefer to leave that decision to the articles' editors. Flatscan (talk) 05:24, 25 November 2011 (UTC)

How long is too long?

Various usability studies suggest that people read only the first paragraphs of web pages, looking for links relevant to their needs, then choose a proper link and following the link. For a latest review of the subject, see [1]. If a page is more than a screen size, then we should encourage splitting it. This is also a recommendation by ISO 9241-151 on the usability of web sites. Stuff with substantial information is easier to read when isolated, and the association with the original topic may be implemented by bi-directional cross references.

Avi Harel (talk) 07:17, 29 November 2011 (UTC)

Proposed WikiProject

Hi, I have proposed a merge-related WikiProject at Wikipedia:WikiProject Council/Proposals/Merge mainly to see if we can reduce the backlog more. The way I see it, with a wikiproject, more people will be engaged with doing the otherwise unpalatable, especially if there are specific targets, for example, clear 2008 by X. An example of this kind of approach is WP:URBLP, which has successfully cleared the backlog of unreferenced BLPs. I hope people will comment on the proposals page above. Thanks, Quasihuman | Talk 15:27, 27 December 2011 (UTC)

Rule for stale merges

So to get the backlog down (at least a knotch), how about that if a merge proposal gets put up over a year ago, and no one supported or opposed, we merge the page as there was no one to say a problem that would happen. ~~Ebe123~~ → report on my contribs. 16:38, 20 December 2011 (UTC)

The problem is not in deciding whether to do the merge. The problem is in actually doing the merge (more or less properly). For the rule you propose, you don't need to bother waiting a year. You could wait 30 days. In fact, you could wait 30 minutes, if you think that it's highly likely to be uncontested. The only thing we actually need is a volunteer (you?) who will actually do the grunt work.

This reminds me of tax collection at the end of the Roman empire: the tax laws were written in gold on purple vellum. They were read out in great pomp and circumstance. Everyone agreed that it was a wonderful law, that yes, certainly, without a doubt, we have agreed that taxes should be collected like this. But nobody paid up.

Writing down a new law that says "You are permitted to merge pages under these circumstances" does not make any merges happen. It doesn't matter if you write that new law in gold ink on purple vellum. What gets the merges done is doing them, not telling non-existent people that they are permitted to do them. WhatamIdoing (talk) 01:58, 21 December 2011 (UTC)

Ede, be bold. If there's no discussion, it's totally up to you. You can simply delete the tags without comment. If you do the merge, please add the templates {{merged-to}} and {{merged-from}} to the top of each talk page involved as appropriate. WhatamIdoing, your slightly bitey response was not warranted. He was asking if he could do the merge, not requesting a change in policy. D O N D E groovily Talk to me 02:23, 21 December 2011 (UTC)

I agree whole-heartedly. It is best to state the fact that there is no discussion about the merge in the edit summary. -- Alan Liefting (talk) - 19:54, 10 January 2012 (UTC)

What is this sentence supposed to mean?

From the first paragraph: "Discretion should be exercised to make sure merging does not result in an article that is too long or drawn out, short articles that can be shown to be expanded, or if said short articles are of a discrete enough topic that merging is not possible." Maybe I reading this wrong, but this sentence makes no sense to me. --Paul_012 (talk) 11:50, 14 January 2012 (UTC)

• Maybe it should says this -
  • Don't merge: if the resulting article would be too long or if the source page is a distinct enough topic that it should be expanded instead.
• Is that the intention? D O N D E groovily Talk to me 03:39, 15 January 2012 (UTC)

The catastrophically failing merge process

• Note: I removed the transclusion to the VP because it was breaking section headers. Feel free to revert but I would much prefer to be able to actually edit individual sections. Consider WP:RFC instead. Protonk (talk) 00:33, 14 December 2011 (UTC)

• Acknowledged. Good enough. --lTopGunl (talk) 06:42, 14 December 2011 (UTC)

The merge process is a disaster. An unmitigated disaster. There are currently around 16,000 articles tagged with merge tags. Only about 5% have any discussion and only about 1% of the tags actually link to the discussion. Merges routinely languish for years, with several unresolved merges over three years old.

Summary:

• The process for placing tags and starting discussion is too complicated. As a experienced editor, the instructions are difficult for me, and I frequently struggle with getting the tags right when trying to place them.
• There is no process for the discussion, no process for involving enough editors to have a discussion, and no process for closing/ending discussions. Yes, there's a template, no, there is no indication of when to use it.
• Editors frequently don't understand what to do to complete a merge, even when consensus is clear. On talk pages, I've noticed that many think that it is a complicated process that they shouldn't even attempt.

My proposed new process would be similar to Wikipedia:Requested moves:

1. Create a simple new template. To propose a merge, a user copies it and pastes to a talk page and adds why they think it should be merged.
2. A bot would place it on a list of current merge discussions, as well as put notification tags on the involved pages.
3. There would be a seven day discussion period. Administrators would close them. A Don't merge or no-consensus would require no-action, while a redirect would be done as consensus indicated.
4. If the consensus is to merge, the closing admin would copy and paste the source into the destination. The admin would not be required to make any attempt to reorganize or combine the texts. A tag would be placed saying "The page was recently merged. Please review this page to reorganize its sections and remove duplicate material. If this has been done, you may remove this tag."
5. Either the bot or admin would remove tags announcing the discussion and announce the completed merge on the talk pages with {{merged-to}} and {{merged-from}}

The whole point of making step 4 as it is, would be that it gets the merges done. Editors are much more likely to jump in and cleanup a disorganized article than to do a merge because they saw the tag.

As far as the existing backlog:

1. Have a bot delete tags on any pages that has had more than 30 edits since the tag was placed.
2. Have a bot bring other pages to discussion, maybe 5 a day or so.

Please comment D O N D E groovily Talk to me 22:04, 7 December 2011 (UTC)

Seconded. I would make two minor modifications to the process.

1. we mark stale debates as such first and give watchers a few days (15?) to reach consensus.
2. the bot do at least six articles every hour, or one every 10 minutes. This would still take more than 100 days to go through all of the articles this way. Merges closed this way should obviously be marked as no consensus. --Walter Görlitz (talk) 22:29, 7 December 2011 (UTC)

• The reason for deleting tags after a certain number of edits is that by that time the article has changed so much that the original reasons for the merge no longer apply. Maybe that should be more than 30 edits, perhaps 100 or so. The bot would also close the merge if the source has become a redirect or has been deleted.
• For old merges, the bot would have two processes. First, automatically closing stale merges that have seen a lot of edits. For those that haven't, the bot would simply initiate a discussion, and a human would close it as noted. The bot should probably wait until the discussion page has enough of an audience that people know it's there. D O N D E groovily Talk to me 05:33, 8 December 2011 (UTC)

• Support: Merging needs to speed up. There are a lot of duplicates and forks that need to be handled. Incase a merge is not replied to by anyone other than the nominator, silent consensus should be assumed to make a bold merge. --lTopGunl (talk) 10:43, 8 December 2011 (UTC)

• Comment Silent consensus should not be assumed. --Walter Görlitz (talk) 14:44, 8 December 2011 (UTC)

Wikipedia:Merging#Performing_the_merger & WP:SILENCE say it can be done. --lTopGunl (talk) 14:49, 8 December 2011 (UTC)

You mean the phrase that reads "most others (as described above) need a rough consensus that support a merger" coupled with "Consensus can be presumed to exist until voiced disagreement becomes evident"? I think you missed the entire section labelled "Mergers as a result of deletion discussions" in Wikipedia:Merging. Since the procedure is not completely defined, it must be clearly stated in this article. It also assumes that a sufficiently long duration of time elapse before the merger proceeds. I could see this abused: "I waited an hour an no one responded". --Walter Görlitz (talk) 15:11, 8 December 2011 (UTC)

Top Gun is right. For now, we need to use silent consensus to solve these. We're not talking about waiting an hour, we're talking about waiting THREE YEARS. For many, on the other hand, it makes more sense to delete the tags without discussion, as often the articles have changed so much that the original reasons no longer apply. But I'm not talking about band-aiding what we have, I'm talking about creating an entirely new system that works. D O N D E groovily Talk to me 15:29, 8 December 2011 (UTC)

I didn't say TopGun was wrong. I just want to clarify the wait time. While we're talking about waits longer than one hour, unless we clearly identify a minimum wait period (even if it's relative) we run the risk I mentioned. --Walter Görlitz (talk) 15:57, 8 December 2011 (UTC)

Yes, when I quoted the policy it means that I read it and was including that part which you mentioned. But in the same way, you have to consider both sides. I never said or even assumed that the wait would be one hour. Infact, if you refer it as a 'support' to User:Dondegroovily's comment, you'll know that he has already specified a wait time of 7 days. So take my comment in context to the proposal. If there has been no comment other than the nominator the admin can mark it as a 'go', Hope I stand clear now. And as User:Dondegroovily said, on the old articles, we have already waited for years. --lTopGunl (talk) 16:39, 8 December 2011 (UTC)

I never put the words of one hour being an acceptable time into your mouth, rather into the mouth of some future editor who doesn't read the policies and simply infers from similar actions. --Walter Görlitz (talk) 17:09, 8 December 2011 (UTC)

My response was additionally to the opposite quotes you gave from the policy which I meant to stand by along with the supportive ones. Well, then we both stand clear. --lTopGunl (talk) 17:24, 8 December 2011 (UTC)

• Some time ago, I had suggested a process similar to AfD called AfM (Articles for merging). It turned out to be a failed proposal not because of a lack of consensus, but because of a lack of comment. It just wasn't advertised well enough. I believe we should revive a discussion on this. It could just be the solution. Many articles that go to AfD really belong on that type of discussion. Sebwite (talk) 22:56, 8 December 2011 (UTC)

A village pump this time? That load of to be merged articles will keep on increasing otherwise. --lTopGunl (talk) 22:30, 9 December 2011 (UTC)

Go for it. --Walter Görlitz (talk) 23:07, 9 December 2011 (UTC)

Very good proposal. Other than a discussion on the mechanics, how could anybody object? --Richhoncho (talk) 10:22, 11 December 2011 (UTC)

• The thing I would like to see is a more automated process for going through the steps of adding tags around the place and moving a complete page to the bottom of another page. The person doing it would still have the work of actually merging in the content but I have seldom managed to follow all the steps exactly and many merges are done without any reference to the original page or the necessity for keeping the talk page. The admin messing around notifying a merge, setting up a discussion at a suitable place and finally starting to do the actual merge is a burden that could be greatly cut down with some automation. Dmcq (talk) 11:23, 11 December 2011 (UTC)

The automation is one of the main aims of the proposal and would need some technical help. A bot as proposed. --lTopGunl (talk) 11:31, 11 December 2011 (UTC)

• Oppose. Kind of an odd spot for me to break an 18-month silence, but whatever. The reason the merge process is a failure is not due to a lack of automation, but rather to a lack of initiative on the part of editors. Unlike article deletion, merging takes writing grunt-work. If you believe one article should be merged into another, do it. If you believe one article should be merged into another but lack the personal impetus to do so, don't worry, it'll keep until someone does feel like doing it, and from a readability standpoint it'll be preferable to keep it as two separate topics than copy+paste one into the other.
  The only place where even a semi-formal merge process should be necessary is when the appropriateness of a merge is under actual dispute and outside comment is desired. --erachima talk 12:45, 11 December 2011 (UTC)

Don't know if you're referring to my business about automating a copy paste of the whole article but we're supposed to do something like that first for a full merge before doing the actual integration of the bits. At least that's my reading of WP:MERGE Dmcq (talk) 13:01, 11 December 2011 (UTC)

Comment In my view, completing the merge by copy/pasting with no requirement to reorganized the page is the most important part of this proposal. This ensures that the merge is promptly completed as soon as the merge is complete. Instead we have this, an article that HAD the consensus to merge over a year ago but hasn't been done due to how time-consuming and difficult it would be. Instead, we should copy/paste Effects of World War II to the end of Aftermath of World War II, place a tag indicating it needs reorganization (as I described in my original proposal), and it's done. It is more important that clear consensus is performed than having the perfect article in the end.

When I first saw this edit, I assumed it was the result of a copy/paste merge. Now I don't think it was, but it gives an idea of what a simple copy/paste merge might look like D O N D E groovily Talk to me 17:07, 11 December 2011 (UTC)

That you are, and it's precisely what I object to. You're arguing that we pretend to address the problem of merges taking too long to complete by redefining "complete". Keeping around two redundant articles is better than having one unreadable mess. Pages should be merged when someone is willing to actually merge them, and no sooner. --erachima talk 17:25, 11 December 2011 (UTC)

In that's your view, then we shouldn't have a merge process at all. Instead, people merge when they want, and revert when they don't like it, no tags, no process. After all, why bother reaching consensus if that consensus will never happen? All that does is wastes everyone's time. D O N D E groovily Talk to me 17:31, 11 December 2011 (UTC)

Precisely. As I just said, "The only place where even a semi-formal merge process should be necessary is when the appropriateness of a merge is under actual dispute and outside comment is desired." Merging articles can only be accomplished by putting in the time and actually refactoring content. The process is generally needless and in large part a stumbling block. --erachima talk 17:42, 11 December 2011 (UTC)

In that event, we would also need to explicitly not permit merge votes in AfD discussions. D O N D E groovily Talk to me 17:45, 11 December 2011 (UTC)

Why? Merge has always been a form of keep, at least in a non-BLP context, and we don't have issues with expediting those appropriately. --erachima talk 18:02, 11 December 2011 (UTC)

I refer you again to Effects of World War II, an Afd merge vote from over a year ago that still hasn't happened. If I had spent more time looking, I could have found ones from 2009, since I know they exist. So, yes, we do have a problem expediting those appropriately. D O N D E groovily Talk to me 18:43, 11 December 2011 (UTC)

I have a very hard time believing Effects of World War II is a pressing BLP issue. --erachima talk 18:48, 11 December 2011 (UTC)

You earlier said Merge has always been a form of keep, at least in a non-BLP context, and we don't have issues with expediting those appropriately., and this proves that we do have issues expediting merges. Or did you mean we don't have an issue expediting BLP merges? D O N D E groovily Talk to me 18:52, 11 December 2011 (UTC)

Yes, "those" meant BLP-based merges. --erachima talk 18:55, 11 December 2011 (UTC)

Another way of looking at Merge AfDs, is what if after voting delete, pages only sometimes got deleted? Sometimes immediate, sometimes in a couple weeks, sometimes years later? We would not consider that an effective system, and users would no longer even bother. That's why we should ban merge votes in AfDs until we have a way of ensuring the merges actually get done. D O N D E groovily Talk to me 02:17, 12 December 2011 (UTC)

• Oppose I agree that there is a huge merger backlog and that part of the solution is to perform them. This proposal elevates quantity far above quality.
  • Copying content between articles properly is not a simple process. Following WP:Merging#Performing the merger and WP:Copying within Wikipedia requires competence, and many experienced users make small mistakes. Having the closer do the merge (Item 4) would help with this, but it has other problems.
  • Seven days is too short to discuss most mergers. Those that could be cleared that quickly probably don't need any of this process.
  • Item 4, having the closer dump the source article into the destination, is a terrible idea. I think that forcibly redirecting the source could be considered, but I can't support deliberately making the destination article worse. Also, adding tasks for the closer may dissuade potential closers.

This proposal could use a WP:Requests for comment tag and other notifications per WP:Publicising discussions. Flatscan (talk) 05:24, 12 December 2011 (UTC)

• Oppose Largely per erachima. No top down policy change is going to eliminate the need for grunt work and discretion. Protonk (talk) 06:34, 12 December 2011 (UTC)

• Comment I don't think you understand what's being discussed. A top-down policy is not being proposed, a bot to help automate the process and getting rid of stale merge proposals is. Insert non-formatted text here

• I haven't commented on the refocused proposal but the proposal above still doesn't solve the problem. Creating a bot queue is fine. Asserting that admins can/should close merger discussions is also fine. That doesn't change the fact that actually performing the merger isn't something I want admins doing and isn't something admins want to be doing. Anything more complex than a redirect is something I am unwilling to do on an article unless I have a good understanding of the source and target. That's the primary reason why the RM backlog is perpetually enormous. Protonk (talk) 07:04, 12 December 2011 (UTC)

It atleast speeds up the future proposals and has a way of adding the old backlog to the que from time to time. Whether an admin should simply cut paste the content could still be debated as you have a valid reason but then (atleast for the future/new merge proposals) the nominator can do it and would probably fully complete the process and could be bugged by the bot a few times till he doesn't. The old ones can be treated in ways given below. --lTopGunl (talk) 07:29, 12 December 2011 (UTC)

• Comment (I have yet to read the full discussion but will do so later) I recently performed my first merge. I was already watching the article but then SuggestBot suggested the merger. Without that suggestion, I might never have plucked up the courage to do it. The instructions were quite clear (although could be clearer) and the merge seems to have gone well. It was a simple merge with few editorial or technical difficulties, so perhaps not a typical example. The point is: I have not performed other merges because of fear of being shouted at. I really think that may be a great disincentive in many cases. If merge discussions could be considered final, I think more editors might feel more comfortable taking the merges on. I think few editors enjoy arguing about and justifying everything they do, but when doing any work that can be considered large scale the chances are that someone will take umbrage and make one wish one hadn't bothered. There is currently a discussion about a possible new way for content discussions to be binding. This might help. Involving bots to assist is good thinking. Limiting the time it takes to make the decision is good, but (I saw above) 7 days is too short. 30 days seems more fair. Something else that could assist in getting the job done, is to suggest in the guidelines and templates that the proposed merge should be demonstrated at a sub page of the article to be merged (the from page, not the to page). So the proposer could create their proposed result to show involved editors. This could encourage immediate collaboration, and also make the eventual merge, editorially and technically much smoother. I'll come back and comment more after I've had a chance to read the rest of this discussion. fredgandt 08:37, 24 January 2012 (UTC)

Refocusing proposal

I think I can address the main concern by adding a layer into the process. The way I see it the bot would have three functions:

1. Check all newly created merges to verify that they're dated and that they have an appropriate talk. It would add dates if none are present and talk where none are present.
2. When discussion has gone stale (at least one month without any discussion in the merge section) the bot would tag the discussion as stale and encourage consensus to be reached and to perform the merge or decline the merge as necessary. The reminder would indicate that the bot would be back a month after discussion stopped to close the discussion.
3. A month after being tagged as stale the bot would close the discussion as no consensus. Assumption here is that after two months of inactivity and one notice of staleness, if the merge has not happened the interested parties cannot be brought to merge and so the merge is stale. The discussion would be closed and a rationale would be added that it was closed due to lack of interest and lack of consensus. That does not mean that another merge proposal could not be added in the future.

For merge proposals that are more than a year old, this is exceedingly important. It makes no sense to have a merge proposal around for that long particularly when it is malformed or a discussion is not happening. The reason for the warning in step two is that editors who watch the page may have forgotten about it and the warning would bring it back onto their radar as it were. We don't want this to be autocratic, but we don't want hundreds of merges to become zombies as they are now.

Caveats

1. We have to ensure that MiszaBot and other archiving bots don't archive merge discussions.
2. The bot would not automatically merge anything. That's not its job. Only a human can do a proper merge. The warnings it places would indicate that.
3. Editors could artificially keep a discussion alive by adding phantom edits to the merge section. Does anyone have any concerns about this potential problem?

I think this addresses all of the concerns. Comments? --Walter Görlitz (talk) 23:02, 11 December 2011 (UTC)

• Sounds reasonable. --erachima talk 00:38, 12 December 2011 (UTC)

One small change between steps 2 and 3 of the bot work. 3. would only happen if no discussion happened after the stale tag. If discussion happens after the stale tag, ideally by more than editor, the process would be reset. --Walter Görlitz (talk) 02:08, 12 December 2011 (UTC)

Maybe what I didn't make clear is that there are two issues here. First, we have the huge existing backlog. Second, we have all future merges. Walter's suggestion is a reasonable way of handling the existing backlog. However, for future merges, I would prefer something like I proposed originally, working similar to the requested move process. The key thing is having a defined discussion period (7 days, probably) and having a single list of current discussions, like move requests and AfDs have. This ensures that merges actually get discussed, and the defined discussion period ensures they actually get close and concluded (Neither is happening right now). Finally, remove the onus of reorganizing the article when the merge is done, ensuring the merge does get done promptly. D O N D E groovily Talk to me 02:17, 12 December 2011 (UTC)

That's not going to work. If a merge is to happen, the article must be organized, by a human being, and until that is done it should not be merged.
Again, merging is not an automable process. It's not a problem that can be solved at the policy level. It requires actual writing, actual reading, actual judgment and actual time investment by actual people.
Remember, merging is only a tool that exists to be used when it results in better articles. It has no intrinsic value. If you "remove the onus of reorganizing the article when the merge is done", you have done worse than nothing, because you've created a sense of false accomplishment for making articles less useful for our readers and encouraged bad organization. --erachima talk 02:35, 12 December 2011 (UTC)

Erachima, if you're gonna take that view, then the only real solution is to have a bot remove all 16,000 tags and take no further action. No point reopening discussions if the conclusion is never gonna happen. D O N D E groovily Talk to me 04:10, 12 December 2011 (UTC)

The conclusion happens when you make it happen. --erachima talk 04:14, 12 December 2011 (UTC)

Right, and industry won't pollute if we politely ask them not to, right? You can hope and pray all you want, but the 16,000 page backlog proves that it's not reality. The only way to change reality is to either give up on the whole concept of merging altogether or automating it somehow. D O N D E groovily Talk to me 04:16, 12 December 2011 (UTC)

That's a false dichotomy and a worse analogy; you don't need to give up on merging, you simply need to correct your perspective on what merging is. The key realization here is that merging is not a maintenance process. You can't treat it like AfD and expect it to go anywhere, because AfD is an attempt at assessing whether an article can be improved, while merging is a process of actually improving it. Those 16k pages are merely 16,000 suggestions for improvement, they're no more significant than "this article is a stub" in that respect. --erachima talk 05:01, 12 December 2011 (UTC)

This sounds like an endorsement of the status quo. Or am I mistaken? D O N D E groovily Talk to me 05:05, 12 December 2011 (UTC)

Merging is not something we can expect this tool to do. It should be left to an editor. Deletes operate the same way. An editor nominates it and if discussion is required it is discussed. If discussion concludes that delete should happen a deletion admin implements deletion, it's not left to a bot. Similarly, if an article is to be merged, someone must do so particularly since we don't want duplication of material and it's nearly impossible to program the logic of where the merged material should go into a bot. The only thing I see this bot being capable of doing is indicating that a discussion is stale and closing the discussion and removing the merge templates.

Part of the reason is that if a nominator is interested in the first art of the process, I would hope that the editor would be around for the final part as well. Sometimes all it really needs is a reminder from a bot to tweak the memory of the nominator to actually merge. --Walter Görlitz (talk) 05:33, 12 December 2011 (UTC)

It's not my intention that a bot does the merge itself. The bot would just help with the nomination/discussion process, such as move requests. An admin would copy/paste the pages together and could choose to integrate them himself or to leave it to another editor. If not that, at the very least, we need to distinguish between suggested merges and decided merges. With the exception of AfD, it is impossible for anyone to tell a simple suggested merge from one that consensus has already decided on without reading both talk pages. No matter what approach is taken, we do need a more managed discussion process. If merge wins the 7-day discussion, it goes from a suggested merge to a decided merge, perhaps. D O N D E groovily Talk to me 05:43, 12 December 2011 (UTC)

OK. If the merge is going to go ahead, how do you see the bot helping with that? I see that as a purely manual process and not possible for a bot to determine. --Walter Görlitz (talk) 05:51, 12 December 2011 (UTC)

My original intention (see the very top of this discussion) is that the closing admin copy/pastes it. The idea I'm playing with now is that the page is upgraded from a suggested merge to a decided merge. The admin would close the discussion and a bot could assist with placing or removing tags and the like if needed. For either concept, the main idea of the bot, tho, is to list all the future merge discussions on a single Articles for Merging page, and I see it working the same way as Requested Moves - where the Articles for Merging page links to the article talk pages. Having the merge discussions centralized would assure that they actually get comment (articles on obscure topics otherwise wouldn't). Having a defined 7-day discussion period ensures that these discussions actually get closed. Discussions aren't getting closed currently because no one knows they should do it, how to do it, and when to do it. Again, under no conception of my ideas would the bot do any merging, the bot would only list and tag. D O N D E groovily Talk to me 06:22, 12 December 2011 (UTC)

Pretty sure that the bot could assist with that. --Walter Görlitz (talk) 06:32, 12 December 2011 (UTC)

Just so we know what we're discussing

Here are two options as I see it for future merges. This subsection does not address the existing backlog, which is a different issue

Option A

• User initiate discussion by copying text to either talk page
• Bot lists the discussion on an Articles for Merging' page
• Merge is discussed. Discussion can be renewed if there isn't consensus yet
• Admin closes discussion (after seven days, usually)
• Admin does Quick Merge by copy/pasting and then redirecting
• Admin places tags announcing merge in appropriate places and removes discussion from Articles for Merging. A bot could help with this.

Option B

• This is the same as Option A, except no quick copy/paste merge.
• Instead, this would place the page on the list of decided merges, rather the suggested merges.
• There would be separate categories - all current merge tags would be suggested merges, while only those decided by merge or deletion discussions would be decided merges.

As far as the existing backlog, any user could start discussion by following the procedure shown in both options. D O N D E groovily Talk to me 15:54, 12 December 2011 (UTC)

right|thumb|Quick Merge complete! Why would we want to create an elaborate process similar to AfD/MfD/RfD so that we can spend some allotted period of time discussing merge proposals that – in all but the most miniscule fraction of cases – haven't been disputed? The outcome of Option B would be to change the tags on articles from 'proposed merge' to 'approved merge'....and that's it. Option A, meanwhile, is worse, for reasons already discussed, and which Dondegroovily needs to take on board. A copy-paste doesn't mean anything has been merged; it means that the target article has been broken by the addition of a chunk of undigested text. Calling it a "Quick Merge" is a deceptively pleasant name for a shoddy shortcut. We would be trading two articles which ought to be merged for one article that's badly deformed—none of the actual work of merging would have been done.

Either option would be a needlessly complicated exercise in tag management, rather than a genuine improvement in the project. It's possible that we could use a more formally defined process for making decisions in the small number of cases where there are active editors genuinely disputing the merits of a merge. (We sometimes see both AfD and RfC used for this, with varying degrees of success—but AfD isn't really built for it, and RfCs can often end up petering out after a month of 'no consensus'.) We don't need a scheme that adds paperwork to thousands of uncontroversial proposals.

If you want to handle the large number of unresolved or incomplete article merges, it strikes me that creating a WikiProject for likeminded individuals is far more likely to accomplish something constructive. The problem isn't that we don't know how to do article merges, nor (generally) is it that there is significant dispute of which articles are valid candidates for merging. Rather, we just don't have enough editors who make carrying out article merges a personal priority for their finite supply of editing time and effort. There probably is room for the creation of automated tools for identifying merge candidates of interest to individual editors. Some might want to deal with articles that have COI or spam flags; others might want to work on pages that are in Pokemon categories; still others might be curious about which articles are the target for the most proposed merges. The actual merging itself, however, isn't something that can be done by rote or handed off to a bot. TenOfAllTrades(talk) 16:20, 12 December 2011 (UTC)

I don't think the proposal aims to slow down the bold merges, see discussion in the main section. The idea is to assist and remind the nominator and other involved editors to either complete the merge or leave it. This way creation of a backlog is prevented. I think basic aim of proposal here was an anti-backlog process. The bold merges need not be brought to the proposed Afm. The ones with possible dispute can be put forward and the bot can inform recent or major contributors and on no response within seven days merger is to be completed and in case there is response and no consensus can be built, the default would be keep. It is not necessary to copy paste the text into the target article (which was one of the ideas shared here) and rather carry out normally with a defined helpful procedure. --lTopGunl (talk) 16:33, 12 December 2011 (UTC)

An article that ought to be merged doesn't stop needing to be merged just because time elapses, any more than an article tagged with {{npov}} will magically become neutral if we wait. The mergers still need to be done, even if no one gets around to them in the next seven days. TenOfAllTrades(talk) 16:48, 12 December 2011 (UTC)

(edit conflict) I don't want to get too combative but " The idea is to assist and remind the nominator and other involved editors to either complete the merge or leave it" is totally meaningless. Talk pages are full of reminders and warnings from bots or semi-automated processes. They don't do anything to reduce backlogs. The backlog isn't there because people discussing a merger forget that a merge needs to happen. It is there because merging is difficult content work and most editors inclined to perform difficult content work don't want to waste their time on an article they don't care about and a process that is going to invite complaints for minor errors. Protonk (talk) 16:51, 12 December 2011 (UTC)

Ofcourse that doesn't mean that the tags will be removed from the article as well. It will just be a different tag of advised merger as suggested. Protonk, I think you misinterpreted, they backlog will be prevented by the process that will complete the mergers and remind the nominators on their talkpages that they had to merge the article. Incase a merger isn't carried out due to unwillingness of the nominator himself (but as decided the article is supposed to be merged) - the tag can be replaced by the bot to advised one. The help the process will get here is that those who go to propose mergers will then be reminded and assisted by willing editors informed by the bot. I will let Dondegroovily clarify his point here too. I think atleast this will make the process faster for those willing to do the merge given that those unwilling won't do it anyway. --lTopGunl (talk) 17:02, 12 December 2011 (UTC)

Sorry to disagree. It does mean that the tags will be removed. The bot would, after appropriate reminders, remove the merge tags. My opinion is that this is not intended to do any moving but to get rid of stale move requests. --Walter Görlitz (talk) 18:31, 12 December 2011 (UTC)

If the aim would be to just remove stale requests, the editor above would be right to say that the articles have magically not become suitable to keep separate just because the requests are stale. --lTopGunl (talk) 18:36, 12 December 2011 (UTC)

All of these proposals look like efforts to cure the symptoms while letting the disease run rampant. It reminds me of the old treatment for plantar fascitis. The condition was diagnosed by X-ray, and the old-fashioned treatment was surgical removal of the spot visible on the X-ray image. The actual problem was that the patient couldn't stand or walk without severe pain, and after the surgery, the patient still couldn't walk or stand without severe pain—but the surgery sure did make that X-ray image look nicer!

Taking away the "backlog" of proposed mergers does nothing towards improving the encyclopedia's contents. It just makes the "X-ray image" (the category of proposed mergers) look nicer. If you want the backlog reduced, you need to roll up your sleeves and start doing the tedious and complex work of merging whichever articles appear to have no opposition to the merge. WhatamIdoing (talk) 00:01, 13 December 2011 (UTC)

Here's my clarification: One of the challenges of the merge backlog is the huge number of them that have never had any discussion; where editors unanimously opposed it but never deleted the tags; where the proposal doesn't make sense and it doesn't take a discussion to figure it out; where a simple redirect without merging is more appropriate. Those categories probably make up 75% of the merge backlog. Requiring the discussion first will keep these out of the backlog before they're even in the backlog. Quickmerge or not, this will help quite a bit. (Imagine 4,000 merge tags instead of 16,000). It's not about deleting the backlog just because, it's about keeping keeping the rejects out of the backlog. D O N D E groovily Talk to me 01:38, 13 December 2011 (UTC)

To repeat point already made several times:

1. Discussion of proposed merges is not required, so who cares if there's a huge number of them that have never had any discussion? If there is no discussion, and you personally believe the merge is reasonable, then you personally can WP:BOLDly merge the articles whenever you want. The community does not require you to obtain written permission in advance of merging articles. You don't even have to propose the merges in the first place. You could just merge them. Even if someone has gone to the (strictly speaking) unnecessary step of formally proposing the merge, that does not require anyone to leave a talk page comment about it. If nobody cares enough to oppose the merge, then you can do whatever you think produces the best outcome for those articles. (NB: "for those articles", not "for the proposed merge category".)
2. If there is a non-trivial amount of opposition, then you can BOLDly remove the tags. Use something like "removing template for failed merge proposal" in your edit summary, or leave a note on the talk page.
3. If a simple redirect is sufficient (and there is no opposition), then you can BOLDly redirect the article.

We don't need a special new process or a bot to do this. We just need people to roll up their sleeves and do it. WhatamIdoing (talk) 03:02, 13 December 2011 (UTC)

But that doesn't solve anything. People aren't doing it, so merely saying here that more people should won't make it happen. The Wikiproject Merging concept is the only thing I've heard that could solve it without changing the overall system. If you're gonna pull out the Nike argument (just do it), how about presenting ideas to make it more likely to happen or easier? D O N D E groovily Talk to me 04:22, 13 December 2011 (UTC)

I'm afraid that the problem is not similar to plantar fascitis. While at the root you're suggesting that it's simply a cosmetic fix, but that's what's needed. The merges exist on articles where no one is looking and is forgotten. So it's more like rotting potato that's fallen behind a stove. You can smell it, but you can't see it, until you move the stove. The problem is we need a tool to tell us where the problem is. The other problem is there are four or five of us here doing this. I have other things I would rather do than deal with the myriad of stale merge requests. Even on my best days, I could only close a dozen. This tool could remind a lot more editors to get involved in a single minute. The problem is that we have a mess that needs to be addressed and saying "leave it alone" won't get it done any more that saying "you do it" will. We need to mobilize interested parties. That's the goal for me anyhow. Even if we cut the list in half, we'll have achieved something more than just complaining about it or wringing our hands over it. I say that we ignore those of you who don't want to change the status quo and move forward. If it's waste of energy, I'll apologize here. If it's not, those who think it's a waste can apologize. I'm tired of inaction but can't offer any action to help impact the problem. --Walter Görlitz (talk) 04:49, 13 December 2011 (UTC)

If you plan to ignore opposition to the proposal on the basis that opposers aren't bringing up a solution to your liking then we can shut down this discussion right now, because that's never going to result in consensus. Protonk (talk) 04:52, 13 December 2011 (UTC)

In fact, I'll be more concrete. As of this moment there are 16,099 articles listed in Category:All articles to be merged. If the number goes down to fewer than 16,000 by this time tomorrow, I'll let the issue drop, if not, those who don't think we need to do anything about it can let it drop. Go. --Walter Görlitz (talk) 04:54, 13 December 2011 (UTC)

No. --erachima talk 05:13, 13 December 2011 (UTC)

The 16,099-member Category:All articles to be merged is one problem. The 16,099 articles are each their own problem. You're trying to solve the single cosmetic/navigational annoyance of the category being overgrown without addressing --and in fact worsening-- 99.993789% of the total concern. --erachima talk 05:13, 13 December 2011 (UTC)

How can you be so absolutely obtuse? I just looked through some of the old ones. They just need to be closed. That's the problem. Some don't have discussions so they can just be closed. Others have strong agreement to merge. They need a nudge to start. Stop being negative and let's see how we can fix the problem of stale merge discussions instead of trying to see the handful of problems in the whole. --Walter Görlitz (talk) 05:36, 13 December 2011 (UTC)

Whoah, Walter Görlitz—dial back the personal attacks. That's no way to resolve an issue that, frankly, is going to take years of hard work (not days, weeks, or months) from interested, motivated editors to fix.

When you say "they just need to be closed", what does that mean? Does it mean that you reviewed the articles (both the proposed source and target), and based on your careful examination of their contents, sources, and context, you came to the conclusion that merging the two articles would be detrimental to the project? Or does it mean that you looked at them, saw that there wasn't an associated talk page discussion, and so you figured that they don't count as 'proper' merge requests?

In the former case, by all means remove the merge tags. In the latter case, respectfully, the merge process as it exists on Wikipedia doesn't work that way. Absent evidence to the contrary, an editor presumably looked at the articles in question, came to a conclusion that they ought to be merged, and tagged them as such. A merge request that doesn't have an associated discussion can be removed from an article if you have reviewed the article and determined that it is not a good candidate for merging. Like any other maintenance tag, it involves some judgement. A merge tag without an associated discussion shouldn't ever be removed just because you want to make the associated category smaller.

The lack of an associated discussion for a proposed merge is often – in and of itself – a relatively strong argument in favor of a merge. When two or more closely-related articles receive so little attention that no one can be bothered to comment (let alone act) on a merge proposal, it suggests that a merger could be beneficial simply because it would concentrate the limited supply of editor attention in that area on one article instead of two or three. TenOfAllTrades(talk) 15:01, 13 December 2011 (UTC)

Closed means closed. If the nominator hasn't bothered to follow-up on them after more than a year and without discussion it means it's not to be merged. The only action to take is terminate the merge discussion and remove the tags. Closed. And to say that Merge doesn't work that way is pretty silly. We're showing you that the current merge process doesn't work at all in at least 1000 cases. There were no personal attacks either simply a realization that some editors don't care what Wikipedia looks like or whether it is a functional location or not. --Walter Görlitz (talk) 15:28, 13 December 2011 (UTC)

Yes, I understand that "closed" means "closed". That's not really the question that I'm asking. You said that these merge proposals "need to be closed"—how does alerting an article's editors that its contents might better appear someplace else harm the project? As far as I can tell, you find the tags aesthetically unappealing, but that's part of communicating to our readers that we really are a work in progress.

The issue is that the underlying problem – that the article ought to be merged – isn't fixed by removing the tag. (And further, removing the tags makes it less likely that editors will be aware that there are related articles that might be merged in the future.) By the same token, we have more than six thousand articles in Category:NPOV disputes, most more than a year old and many more than four years old. We have more than thirteen thousand articles in Category:Articles with a promotional tone, most of which are years old. There are roughly four thousand articles in Category:Wikipedia articles needing copy edit. Like a merge, these are problems that are generally repaired through editing; they won't go away if the tag is taken off. Like a merge, if no one is editing these articles, then the issue never gets resolved—that isn't the fault of the tag, or of the person who placed the tag. Pretending that the problem is fixed by removing the tag doesn't actually improve the encyclopedia.

I fully agree with you that we "need" to resolve these merge suggestions, but we need to resolve them in the same way that we resolve the long list of articles in need of a copy edit—by waiting for (and recruiting, and cajoling, and persuading) editors who are willing to do the extensive editing required. Any proposal that is motivated primarily by a desire to remove tags instead of aiming to improve the encyclopedia is destined to fail.

I previously suggested that creating a Merger WikiProject could help to focus efforts and reduce the backlog. Perhaps such a project might coordinate the creation of a notification bot that tracked down editors who added merge tags to articles, and invite them (politely) to help out. Another bot task might be to identify 'unmatched' pairs of {{mergefrom}} and {{mergeto}} tags. (I just removed a 'mergefrom' tag from a target article, as the source had already been turned into a redirect.)

Finally, I've just had a look at Category:Articles to be merged. The information at the top of the page says that on 1 November 2007, there were 12520 articles in the category. As of right now, there are still sixteen thousand or so articles that are candidates for merging, but none of them are dated prior to 2008 (and only about 120 are before January 2009). What that says to me is that, remarkably, we are slowly churning through merge candidates. Some do take a while for an editor with appropriate interests and skills to come along, but they don't languish forever. TenOfAllTrades(talk) 16:34, 13 December 2011 (UTC)

The problem isn't as you state. The article ought not be merged. It's a suggestion. If one person thinks something that doesn't mean it's a fait accompli, it's a suggestion. Usually there is opposition and the issue needs to be acted on. That's all I'm asking this bot to do is to prod editors into resolving the issue. If they can't, then what's the harm in saying "you can't come to agreement, so we'll close the issue for now"? You seem to think that merges must happen just because they're tagged. They don't always. What that says to me is that you don't understand the issue. It's not slow churn, its no churn because they're not necessary. Please look at the list of outstanding merges.

We find coordinate space there, where three comments are made on the merge discussion. The first is from an opponent of the merge indicating that it appears to be self-interest that placed the tag on the articles. The next doesn't even address the merge and the final comment is essentially "let's get rid of this tag.

There are two different discussions at extrajudicial killings and forced disappearances in the Philippines and one is vehemently opposed to merging and suggests that the merge tag was place by a "deleted user" so should be revoked. The other is a simple comment that there is more information at the other article and so merging makes sense.

At the list of Babylon 5 characters, the two links to discuss the merge go nowhere. It was never discussed. It will never happen.

They go on and on like this. In short, if there's an article that has been tagged for over a year to be merged and the merge hasn't happened it's stale and should probably not be merged, but we let the editors decide, hence the bot prompts them to discuss. In the outside chance that we close a merge that is really quite obvious, the information is still on the talk page and when the next discussion starts on merging, they'll be prompted to not let it sit dormant for a year. And besides, if a merge is so obvious, it will likely be suggested again by someone. However leaving merges open for half a decade is an abuse of the merge process as much as closing a merge without adequate discussion after 1 hour would be. --Walter Görlitz (talk) 17:52, 13 December 2011 (UTC)

You seem to be ascribing reasoning and positions to me that I haven't taken. Two comments ago, I specifically stated that you should go ahead and remove merge tags from articles where you've taken the time to examine both the source and the target, and determined that a merge isn't appropriate for those articles. Where is it that I've declared that applying the tags represents an irrevocable fait accompli?

I'm concerned that you're looking at a very small subset of controversial or potentially-controversial merges and inappropriately generalizing their problems to the entire pool of unresolved merge requests. The vast majority of merge requests aren't the subject of a contentious discussion, they're just maintenance tags that suggest a particular article's content would be better cared for in the context of another, broader article. The former case – which usually involves a genuine dispute between active editors of an actively-edited article – requires a path to resolution (as I mentioned before, RfC sometimes is used in this situation). The latter case – a quiescent article with few or no active editors, where the merge is uncontroversial but just not acted on – doesn't require intervention and resolution; it just needs to wait for the attention of an editor who is willing to do the grunt work of performing the merge.

In the latter case, an article being tagged for a year isn't an abuse of process, it's just that no one has gotten around to it—in much the same way that somone can identify an article in need of copyediting, but not have the time or inclination to do it themselves. TenOfAllTrades(talk) 20:13, 13 December 2011 (UTC)

No, you're looking a a small subset of recent merges to take your position. I looked at cases that were three years old. They were the oldest three I could find. Those are the ones that are at issue, not those that have been around for two hours. Sorry if I talked past you or you didn't bother to look at the links to see what I was talking about. I have no problems with not touching uncontroversial merges and certainly not recent ones, but those that were suggested three years ago, why should they still be open? Even two years ago. Or even twelve months ago. If they've fallen off he radar we need to prompt discussion to resume. Please look at the backlog and then comment on why any of those added a year ago should be there. Be precise rather than abstract. --Walter Görlitz (talk) 21:52, 13 December 2011 (UTC)

Whether a merge was suggested 30 seconds, 30 days, or 3 years ago is of little relevance to whether it's a good idea. Pulling the tags off of merges that aren't good ideas can be great, but a bot can't judge that. As for your demand for examples, I coincidentally merged a page today after 9 months with no discussion, simply because I happened to read the page and felt like doing the job, but I wouldn't have noticed if the tags weren't there. q.e.d. blindly removing the old tags for inactivity would have concretely resulted in less good.
Calling people "ideologues" is also not helping the matter. --erachima talk 22:11, 13 December 2011 (UTC)

I completely disagree with Walter's assertion that the absence of discussion proves the articles shouldn't be merged. The absence of discussion could just as equally prove that the benefits of merging the articles is so obvious that nobody thought it worth commenting on.

I furthermore do not agree that having 16,000 articles listed in the merge category is hurting the encyclopedia. I do, however, believe that mindlessly losing these good-faith and often supported suggestions would be harmful. WP:There is no deadline, not even for getting around to a merge on two trivial, low-traffic articles. WhatamIdoing (talk) 20:58, 13 December 2011 (UTC)

Your point has been made before but it is irrlevant. There is no codified deadline for deleting articles (which is what your link is to), merges are time-sensitive. We are not talking about mindless activity, other than perhaps by those who oppose the proposal. We are hoping to prompt editors to get off their hands and start merging or at least close the merge discussions. That is the first part of the proposal.

Contrary to WhatamIdoing's suggetion, all that would be lost if the later parts of the suggestion are implimented, is a tag that is no longer valid. The request's history would be maintained for all to see. There is no need to keep a merge tag added over three years ago when there is neither any interest to actually merge the articles nor to say that the merge is necessary. --Walter Görlitz (talk) 21:44, 13 December 2011 (UTC)

Merges are not time sensitive. A merge suggestion tag is no different than a stub tag in this respect. It may be incorrect, or resolved, but it never "outdates". --erachima talk 21:50, 13 December 2011 (UTC)

Merges are definitely not time-sensitive, and the fact that nobody has bothered to merge Huntsman Cancer Hospital into the article about its parent organization, Huntsman Cancer Institute, does not mean that the merge shouldn't be done. That merge obviously should be done, the merge was discussed and supported without opposition, and the only step needing to be taken is someone actually merging the pages. That will happen whenever one of our WP:VOLUNTEERs decides that this trivial merge is a higher priority over other tasks. Removing the tags from these articles would serve no purpose beyond making the clean-up category falsely state the number of bona fide proposals that need to be dealt with, and making it hard for any interested volunteer to find articles that need to be merged. WhatamIdoing (talk) 22:22, 13 December 2011 (UTC)

Thanks for finally citing an example. The Huntsman pages are an uncontested move. We tell the bot to simply prod editors to merge those. It's an easy fix. Why hasn't anyone merged them in two years? Not becuase volunteers didn't decide that the merge wasn't worthwhile but that they simply haven't done it. That's where the reminder is required. What about the other 16,000 merges that are in a state like this? Just leave them? Why don't I take 16,000 nails and hammer them into the body of your car and let them sit for three years. Yeah, that looks professional. This needs to be resolved. Exceptions can be made, but we have to start promting editors to complete the merges or as editors to close the merge requests. If only there was a bot that could do this for us. --Walter Görlitz (talk) 23:05, 13 December 2011 (UTC)

That's a rather poorly chosen example, since there's nothing to merge from Huntsman Cancer Hospital because the page has no content. It just needs a redirect to the institute page. --erachima talk 23:10, 13 December 2011 (UTC)

Find a better one then. I'm sure there are. However the point is, you may think everything is fine, but there are a few of us who think that we have a catastrophically failing merge process. Telling us we're wrong doesn't change the fact that we know it isn't working. So rather than trying to convince us, why not fix what we see are the problems.

Counter proposal

Let's create a bot to prompt on pages that the merge discussion is stale. This is based on the idea that reminding editors will bring about action and hopefully some resolve to merge or just to close it. The bot would hit articles with no merge discussion every few weeks (seven?) and remind editors that the discussion is stale. After a certain number we would have it add a category tag to indicate that the merge is stale and then editors could address those. If you don't think that promting editors to revisit merge discussions will solve anything then you have to agree that there's no need to have the merge tag there either since no one is watching the article. This bot would not close discussions. This bot would not remove merge tags from stale discussions. --Walter Görlitz (talk) 00:02, 14 December 2011 (UTC)

• I'm fine with something beyond this. A merge proposal template puts the article in a hidden queue and if the talk page of either the destination or the other page hasn't been edited in X weeks simply remove the templates from both pages. I don't think we need to get in a fight over whether or not "no comments" means assent or lack of support for the merger. In my mind no comments (combined with no merger) means that nobody really cares. Tags get taken off, articles don't get merged. But they don't stay on the backlog as well. It won't actually solve the merger problem and it may piss people off who supported the merger (meaning they edited either talk page in support) but no one else commented and no one performed the merge, but if they can't be bothered to perform the merge then I don't see why we should be worried they will be upset if it doesn't happen. Protonk (talk) 00:27, 14 December 2011 (UTC)

  And if we assume that the community's goal is to "actually solve the merger problem", i.e., by merging pages that clearly need to be merged rather than sticking our heads in the sand and pretending that nobody ever noticed the need for the merge, then you would solve the real problem how exactly? WhatamIdoing (talk) 00:30, 14 December 2011 (UTC)

  It doesn't. Read my comments in the thread above. the process isn't (as I see it) fixable by some minor change to function or structure. We could just as easily fix the problem that not all wikipedia articles are featured as we can fix the problem that not all requested merges are executed. Protonk (talk) 00:35, 14 December 2011 (UTC)

If the bot is ignored, it doesn't prove that no one is watching the article. It only proves that no volunteer thought that dealing with that merge was the best use of his or her time at the moment. A one-time message might be acceptable, but repeated nagging is definitely not. And fundamentally, if it's not worth your own time to go deal with these merges, then you don't have much standing to say that other people ought to resolve these merges right now, because you think it looks bad. If you closed just ten easy ones a day (like formally declaring failure on strongly opposed merges or doing simple redirect-and-you're-done merges), you could single-handedly resolve almost a quarter of the proposals during the next year.

From your comments about what "looks professional", I'm guessing that you are unhappy that the merge proposals are visible to readers. I don't happen to care if the readers see these tags. I even hope (as appears to happen on occasion) that the presence of such highly visible tags will encourage some of them to become editors. WhatamIdoing (talk) 00:30, 14 December 2011 (UTC)

I just don't see the value to leaving a merge tag on an article for >6 months with no talk page discussion. I'm not worried about the appearance of the page but long stale merge discussions that haven't resulted in a merger simply eliminate the informative function of a merge tag. With 16,000 articles in RM, how am I to know (as an editor) that any given page I am on actually has a meaningful proposal to merge it with another? Protonk (talk) 00:37, 14 December 2011 (UTC)

In most cases, I'm not sure what purpose a discussion would serve. The editor applying the merge tag(s) presumably believes that the article's content would best be incorporated into another, broader article—a lot the time, there just isn't any more to say than that. In such cases, the only reason that a discussion might take place is if another editor disagreed with the notion that a merge is appropriate. The presence of a merge tag without an associated discussion is, if anything, tacit approval for the merge. TenOfAllTrades(talk) 01:24, 14 December 2011 (UTC)

Maybe. In most cases silence implies consent. And maybe even in this case. But let's look at an article w/ a merge tag placed there by a user who presumably supports the merge. She puts the tag on, waits for discussion and none happens. Then maybe she moves on or forgets or leaves wikipedia (or maybe she waits patiently for discussion and doesn't act). Neither talk page is edited for 6 months. After a certain point the question of which side has the impetus becomes academic. the merge tags become meaningless because there is neither a discussion nor a merger in progress. An editor attempting to navigate the proposed merger category would have to manually filter all of these discussions in order to find on which is remotely interesting or actionable. Now. Removing that tag doesn't fix the underlying problem that mergers are hard work and basically won't get done unless someone wants to do them. But no technical process will change that. What removing those tags may do is marginally reduce the uselessness of those tags to readers. We could argue that a 6 month old tag is just as informative as a 1 day old tag (and indeed some have in this thread). But I'm inclined to believe that if readers and editors can't be assed to make a merger happen then there is little reason in prompting them to discuss it every time they load up the page. Protonk (talk) 01:33, 14 December 2011 (UTC)

A technical process can help a lot. By providing a structured discussion mechanism, about 75-80% of proposals will be to redirect or to not merge. This eliminates undiscussed merges and removes failed merge proposals from the backlog. Again, under the current system, 75-80% of tagged articles shouldn't be merged. If only merges that won consensus had the tag, the backlog would be a lot more manageable, and the tags would be a lot more useful. D O N D E groovily Talk to me 01:46, 14 December 2011 (UTC)

I should clarify. The only position I support so far (besides the status quo) is a bot which would remove tags from extremely stale merger requests. Right now adding a merge tag isn't a required prerequisite to merging an article (neither is discussion) so I'm very skeptical as to the benefits of a more structured discussion process. As TenOfAllTrades, WhatamIdoing and I have said in this thread, discussion isn't the primary barrier to these mergers. Protonk (talk) 01:52, 14 December 2011 (UTC)

I'm not sure that that approach makes sense, unless one reads a merge tag as a request for permission, instead of a recommended course of action. Perhaps it's a philosophical difference, but in most circumstances I see the {{mergeto}} as being like a {{copyedit}} or {{moresources}}. We don't require a tag in place or a prior discussion for editors to copy edit a page or add sources to an article, but we nevertheless have tags to indicate where it would be useful to perform these jobs. Like many editing tasks, it's often possible for a Wikipedia editor to determine that a merge should probably take place, even if they don't have the time, skills, or specialized knowledge required to perform it themselves.

Let's face it—most of the very old merge requests are associated with our most unloved, unmaintained articles. If there were editors regularly watching, editing, and updating them, then someone probably would have already done something about the merge suggestion. Most of these articles likely aren't very good, and probably duplicate material already in other, broader, better-known articles. Stripping the merge tags from these orphans just means that they'll be even less likely to get the maintenance and attention that they need. TenOfAllTrades(talk) 02:22, 14 December 2011 (UTC)

I'm not saying this to be combative but that second paragraph is not convincing at all. If I have to choose between a marginally more tractable merger candidate category and some article receiving less attention because it is no longer in a completely untractable category, I'm going with the former every time. As for the first paragraph, I don't think we disagree too much except on the utility of the tag. Sure, an editor without the interest or skill can tag an article for merger. That's good. But if that merger discussion doesn't receive any attention then why would the tag still be there? Maybe she was wrong? Unlike a citation needed tag, the merger is much less of a maintenance request. It is that, but it is also a claim about the connection between two concepts and an explicit call for discussion. To pick an analogy (which may be inapt in many ways), look at what the FAC process does for nominations with limited interest. They remove them and allow discussion to be focused on newer nominations. Protonk (talk) 02:36, 14 December 2011 (UTC)

The reason it's failing that no one has mentioned

Yesterday the merge backlog was at around 16,090. Today it's 16,100. So, for those arguing we don't have a problem, I point out that we are not even clearing merge tags as quickly as they are being created. When I took a two-month break from them, the number went from 15,000 to 17,000. Around 200 new ones are added every month. How can anyone say this system is working when no one is able to keep up with it? D O N D E groovily Talk to me 01:54, 14 December 2011 (UTC)

• as I keep saying, it isn't "the system" that is broken. Article mergers are a time and attention intensive task for which there is little reward. People just don't do the work. We could point to a much larger backlog of citation needed tags. It wouldn't make a lick of sense to say "the system is broken" because 200,000 some articles have citation needed tags. People aren't adding citations and removing the tags because doing so is hard. There isn't a centralized fix for that which removes the actual difficult part of the process. Protonk (talk) 02:38, 14 December 2011 (UTC)

(ec) What's the turnover? And how far back is the bulk of the backlog? And is it a good idea to base your argument on statistical noise? (Don't forget that there were 16551 unmerged articles in September 2010, and we're still below that threshold.)

In November 2007, there were 12520 unresolved merge requests. Today, there are zero merge requests from November 2007 or any date before—that means that somehow those twelve thousand requests were handled. They might not all have been handled quickly, but we got through them—and it didn't take a bot to do it for us.

There are pending:

• 0 requests from 2007;
• 122 requests from 2008;
• 3661 requests from 2009;
• 5372 requests from 2010 (but this includes a massive number of bot-created stubs in User:Polbot's userspace, padding the April 2010 count by about 700 articles); and
• 6875 requests from 2011.

Or, looked at another way, there are

• 877 requests from November of this year;
• about 700 requests from each of August, September, and October;
• about 600 requests from June and July; and
• about 450 remaining in each of the first five months of this year.

Since I'm pretty sure that editors from last month weren't twice as likely to propose merges as editors from March, it's clear that we do chip away at the list. We keep adding new stuff to the back of the queue, but we steadily work away at the front of it—and low-traffic articles still occasionally get picked off from the middle. TenOfAllTrades(talk) 02:49, 14 December 2011 (UTC)

Thanks for the stats. While we work at the oldest items in the queue, it would be better to work through the queue faster and reminders will help with that. --Walter Görlitz (talk) 06:35, 14 December 2011 (UTC)

I've recently been inan AfD where the result was merge but the target was unsuitable, it fact the whole business was done wrong in my estimate. So then the crowd pushing the AfD found where they said to merge to was unsuitable and then someone goes and tries pushing the stuff into an even more unsuitable place in a different article with the comment 'Well, then, name, specifically, where you think it fits better, remembering we have a mandate to merge that we cannot simply ignore'. To which I replied "It is perfectly possible for a person to ignore something like that. No-one has compelled me to stick stuff into inappropriate articles. Don't include me in your 'we'". If a merge is not completed there may be quite good reasons. Like that it was a silly idea in the first place. If a merge decision was put in as a result of editors pushing through an AfD instead of a proper consensus discussion it quite easily possible for decisions like that to emerge. Merging is not an automatable process but some of its steps could well do with some automation. That case again the person shoving the stuff elsewhere hasn't done any of the business about sticking something on the talk pages about the merge or doing a clean copy first with the summary line noting the original article. At least that bit could be automated even if the merge is inappropriate. Dmcq (talk) 11:36, 14 December 2011 (UTC)

There may be perfectly good reasons not to merge, but none of them are insurmountable. This was not a merge discussion that took a year was it? Not even two. It was likely finished in less than a month and the bot I'm suggesting wouldn't even care about it, particularly if discussion were ongoing. So while the campfire is going, do you have any other stories to tell or can we get down to the business of prompting editors to resolve merges that are stale? --Walter Görlitz (talk) 05:18, 15 December 2011 (UTC)

Similar issues come up occasionally, but the problems with WP:Articles for deletion/Climate change alarmism (2nd nomination) have more to do with the contentious topic area than either AfD or the merger process. Flatscan (talk) 05:25, 15 December 2011 (UTC)

Tagging request

I noticed that a number of participants here are working on the merger tag backlog. Thank you for that. In a few cases, post-merger tags, such as {{R from merge}}, {{merged-to}}/{{merged-from}}, and {{Copied}}, seemed to be both necessary and missing. Please check the articles' histories for previously implemented mergers and tag appropriately. Flatscan (talk) 05:21, 15 December 2011 (UTC)

How about getting a bot to help in this process. We can atleast make the job of merging a bit less tedious for those who are doing the already lengthy work of merging two articles. Something like placing a tag in edit summary, on the bot's page or on a dedicated list from which the bot can place the post merger tags and link them properly? There are many editors who want to merge certain articles and there's no objection to the merger but the merges are still hanging (those include me). This is because attribution and tags and the whole procedure, which I have finally learnt (although I still have to keep Wikipedia:Merging open as a cheat sheet), makes the process long and the merging itself would already be a task to do. --lTopGunl (talk) 11:55, 16 December 2011 (UTC)