All the necessary merges (and in a few cases, deletions) have been performed. Now there is the task of updating the documentation. It should not be a problem, now that there are fewer templates to worry about. @harej 06:27, 3 September 2009 (UTC)[reply]

Awesome job. Help:Merging is the main page that needs updating. --NickPenguin_(contribs) 06:52, 3 September 2009 (UTC)[reply]

That's the page I was working on while you were telling me to update Help:Merging. :D In any case, I did a massive revamp of Help:Merging and not only should the directions be up-to-date, it should be in well-written English prose, too. Well, I did the best I could with writing, anyway. I am pretty tired from all this template stuff. @harej 07:10, 3 September 2009 (UTC)[reply]

I wasn't trying to tell you what to do, I was more hoping that someone would take up the torch while the rest of us got some sleep. Nice job tho. --NickPenguin_(contribs) 18:12, 3 September 2009 (UTC)[reply]

The onus was still on me to update the documentation, since I knew the most about the templates. @harej 19:03, 3 September 2009 (UTC)[reply]

SwiftBot (talk · contribs) has just updated all the transclusions to point to where the deprecated templates redirected to. I've removed their mention from Help:Merging#List_of_merger_templates and Template:Template messages. I think we're now done with these. They're not really in the way, but I guess they could also just be deleted. --Swift (talk) 00:29, 13 January 2010 (UTC)[reply]

I am very content to hear this. Here's to a streamlined Wikipedia! @harej 01:40, 13 January 2010 (UTC)[reply]

The documentation for the merge templates also makes note of the split templates. Since splitting is merging in the opposite direction, would it be a good idea for the bot to note proposed article splits as well? If so, should we rename the page Wikipedia:Proposed mergers and splits? We can steal the shortcut WP:PMS from an inactive project. @harej 23:31, 31 August 2009 (UTC)[reply]

These editing actions are definitely related, but I'm not sure that splits need listings. My impression is that splits are more easily done BOLDly due to the creation of the split article, which has no active editors or content to incorporate. I think that more discussion should precede splits to avoid forking and attribution issues created by repeated splitting/merging, but I doubt there is consensus for it. Flatscan (talk) 04:20, 1 September 2009 (UTC)[reply]

If others agreed, then there would be a consensus. @harej 06:58, 1 September 2009 (UTC)[reply]

I dunno, I'm not sure I see a good reason to keep the two seperate, and perhaps expanding the scope of this page slightly would attract more attention. --NickPenguin_(contribs) 13:49, 1 September 2009 (UTC)[reply]

I agree that there are common considerations. My concern is that we will form a local consensus here supporting combined listings, then face WP:NOTBUREAUCRACY pushback after rolling it out. Flatscan (talk) 04:11, 8 September 2009 (UTC)[reply]

I don't see what this has to do with bureaucracy. We're expanding the scope of a page so we can do more things on it, without introducing middlemen or procedures. @harej 10:54, 8 September 2009 (UTC)[reply]

I realized that my point is mooted by the bot: since it handles all the listing work, no one is likely to oppose over extra effort involved. Flatscan (talk) 05:14, 9 September 2009 (UTC)[reply]

I agree that splits and merges are a lot alike. Both involve concerns about article scope and size, both require moving existing content over articles and preserving the link to the source article. However, I think we should see how the merging thing works out with the bot first, and then think about what else to include. In my opinion, AfD merges could be included on this page as well (see pages that transclude {{afd-mergeto}}). Currently, when an AfD is closed as "merge", the article is only tagged with the template by the closing admin, and will stay as is until the heat death of the universe unless someone comes and actually performs the merger. It would be great to have a subsection for listing those mergers - they're pretty straightforward since there's already a consensus to perform them, but people just need to know that they exist. Jafeluv (talk) 11:19, 2 September 2009 (UTC)[reply]

That sounds reasonable. The AfD merges should get a special list, because those are a little more important than regular merges in terms of community necessity. AfD discussions should be carried through as quick as they can. --NickPenguin_(contribs) 18:05, 2 September 2009 (UTC)[reply]

I can make a separate list for them, or make them stand out somehow. @harej 18:39, 2 September 2009 (UTC)[reply]

Should AfD mergers be considered differently from other mergers where consensus has been determined? I think 1 list for mergers where consensus has been determined, with some sort of highlight for AfDs. There are a few comments on completed discussions at #When to remove tags? below. Flatscan (talk) 04:11, 8 September 2009 (UTC)[reply]

Yeah, I don't know what happened either. @harej 01:00, 4 September 2009 (UTC)[reply]

It looks like it worked for the most part, but there are some glitches that are just nuts. Obviously, this is just the first version of the bot. @harej 01:02, 4 September 2009 (UTC)[reply]

I like the format. Looks like all the merge targets are trying to be listed in the Wikipedia namespace. Some of the categories are a little hilarious. But yeah, not really that bad. --NickPenguin_(contribs) 01:39, 4 September 2009 (UTC)[reply]

That has to do with the {{pagelist}} template I'm using. Anyways, I will probably end up rewriting most of it, because it takes like an hour to run (because it has to load 15,000+ pages over the API). @harej 04:45, 4 September 2009 (UTC)[reply]

I've re-wrote major parts (takes a lot less time now) and I've deleted most of the glitch pages. Special:PrefixIndex/Wikipedia:Proposed mergers/Log/ continues to be the best reference for the current proposed mergers, and is technically a usable list. For reference, here are the glitch pages that have since been deleted:

• Wikipedia:Proposed mergers/Log/date this was posted
• Wikipedia:Proposed mergers/Log/January 1984
• Wikipedia:Proposed mergers/Log/august 2009
• Wikipedia:Proposed mergers/Log/July 27 2009
• Wikipedia:Proposed mergers/Log/January 1337
• Wikipedia:Proposed mergers/Log/may 2008
• Wikipedia:Proposed mergers/Log/Date=September 2009
• Wikipedia:Proposed mergers/Log/2 April 2009
• Wikipedia:Proposed mergers/Log/2009
• Wikipedia:Proposed mergers/Log/February $3
• Wikipedia:Proposed mergers/Log/Sept 2009

Wikipedia:Proposed mergers/Log/January 2008 is opposed by a large majority is being kept around because its title is just too awesome. In any case, the lists are being restricted to article space mergers (for many reasons). While the lists might like good, here's what I still plan on doing before this goes live:

• Prevent the "other half" of a merge request from getting listed (e.g. if X-with-Y is listed, don't list Y-with-X)
• Figure out how to not have merge-to get in on the lists (I tried doing that, but that did not work out). It's one or the other, and merge-from is superior.
• Incorporate proposed splits
• Bold the page names
• Bring back two newlines between entries
• Have the bot generate a list of month logs.

What else is on my plate? @harej 11:30, 4 September 2009 (UTC)[reply]

That sounds like it about sums it up. The only ones that need to be listsed are merge and mergefrom, but adding in splits would nicely round things out in three. The other factors are minor, the only thing I see would be in integrate this into the proposed mergers page and let things run. How many requests are being listsed on each month page? Perhaps a notice should be left at the top of each month page saying this this is a random auto generated list of X number. --NickPenguin_(contribs) 19:37, 4 September 2009 (UTC)[reply]

The log pages are limited to 100 entries per month. I would not say they are randomly selected, but rather, 100 in a given month is where the bot is cut off from loading more pages. @harej 22:07, 4 September 2009 (UTC)[reply]

Oh, so it loads the first 100 alphabetically? Is there any way that it could load a different set of articles? Or maybe when the bot refreshes the list, it takes the last entry in the current list, and then displays the next one hundred items following that entry in the category? My worry is that these lists will basically display the same articles until the month category is cleared. Also, is it possible to eliminate duplicate entries? For example, in Wikipedia:Proposed_mergers/Log/April_2008, there's a request for merging CLEC1B with CLEC2B, and below it, CLEC2B with CLEC1B. There's another example in that log, with Casualty 1906 and Casualty 1907. --NickPenguin_(contribs) 06:11, 5 September 2009 (UTC)[reply]

It loads the first one hundred something; if it looks alphabetically-sorted, we can do with that. I don't know if I can make it load different articles (I don't even know if the articles that get loaded will be consistent from run to run), but I could make the lists longer if you did not mind. Removing duplicate entries is possible but I have not found the best way to do it yet. @harej 12:37, 5 September 2009 (UTC)[reply]

The intro on the project page says:

"After articles are merged (or a consensus that the articles should not be merged is reached), please remove them from the list below." And I assume that the time to remove the tags at the top of the page is similar. At Communist genocide there has been a proposal to merge with Genocides in history for almost a month, and it is clear from the discussion page that there will never be consensus to merge (but you couldn't say that there is a consensus not to merge).

There was a request for deletion that had a similar result (no consensus) about 6 weeks ago. The editing is rather passionate and POV - one side wants to deny that there is such a thing as a "Communist genocide" and the other has presented evidence and citations that there is (although sometimes it is called "Soviet genocide" or "Red terror")

If the rule is "Don't remove the merge tags until a consensus has been reached" the tags will stay there forever. When should the tags be removed? Smallbones (talk) 14:47, 4 September 2009 (UTC)[reply]

No-consensus-not-to-move does not exactly matter. The onus is on the challengers of the status quo to demonstrate the need for change and to attain a consensus. If they fail to do so, the status quo is maintained. @harej 14:53, 4 September 2009 (UTC)[reply]

I can see that being the case with some merges, but there are others, like say Animal language and Animal communication, which have been tagged for almost two years, and almost certainly should be merged. Having a time limit of removing merge tags can be tricky, because there are cases where a merge should be completed, but because it is complicated it just hasn't been done yet. Other times, when there is a significant amount of controversy involved, the merge tag shouldn't remain for even a month, such as a recently proposed merge between China and People's Republic of China. --NickPenguin_(contribs) 19:42, 4 September 2009 (UTC)[reply]

A thread was started by another editor at WP:ANI and I've requested there that an uninvolved administrator close the discussion. I'd guess that ANI is the best place to continue the discussion on when to close. Smallbones (talk) 21:28, 4 September 2009 (UTC)[reply]

I think if there's a clear consensus to merge, the proposal could be moved to another section to await merging, and the bot-updated list would only contain proposals where the discussion is still ongoing. If the merge discussion has been going on for over a month without a consensus, it's probably best to just remove the merge tags and remove the request from the list. Jafeluv (talk) 14:19, 7 September 2009 (UTC)[reply]

How does one distinguish between a merge for which there is consensus and one for which there isn't, and how do you factor in consensus by silence? @harej 15:11, 7 September 2009 (UTC)[reply]

Well, judging consensus could be done the same way it's done over at RM: after a specified amount of time (say, a month), someone uninvolved comes over and closes the discussion if there's enough participance to determine the preferred course of action. Proposals that lack participants could be left open until someone comes over and either decides to perform the merger, or argues against it. The problem with the current system is that merge tags are added to the articles, a discussion goes on for a week or two, and then the article stays in the same state for six months because there's no uninvolved party determining what the result was. Or sometimes everyone agrees that the articles should be merged, but nobody wants to be the one who does it (for an extreme example, see this proposal). Jafeluv (talk) 20:26, 7 September 2009 (UTC)[reply]

There is something to be said about making the merge process more like WP:RM, which is one of the most efficient Wikipedia bureaucracies in my opinion. However, a merge isn't like a page-move; it is a lot more intricate than hitting the move button. @harej 00:33, 8 September 2009 (UTC)[reply]

Yep, a merger requires actually reading the text and understanding it, which is why it would be best that regular contributors to the articles were the ones that performed the merger (as they often are). However, if none of the regular contributors wants to take a shot at it, it's up to the few PM regulars to look whether there's consensus and perform the merger if appropriate. Someone is going to have to decide what the result was in a reasonable amount of time if none of the participants are willing to act on it. Jafeluv (talk) 05:48, 8 September 2009 (UTC)[reply]

There's a discussion about deletion and merge processes here: Wikipedia talk:Articles for deletion#Less process.2C more constructive discussion. Fences&Windows 22:51, 5 December 2009 (UTC)[reply]

The section was renamed to WT:Articles for deletion#Consolidation. Flatscan (talk) 05:51, 16 December 2009 (UTC)[reply]