Implicit merger

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search
Other languages: ru

Implicit merger is obtaining the aims of mergism without an actual merging of two or more pages. It may be intended or not. A number of articles does not decrease during implicit merger of an article: there was one, and the result is one article. But this resulting article may cover quite broader topic than original one, and may have another name.

There are three major forms of implicit merger:

Implicit merger.svg
  • Redirect-merger: making redirects to an existing article, which stops a wiki newbie or inobservant user from creating a new page;
  • Move-merger: renaming an article on a narrower topic to something broader, which is not written yet;
  • Silent merger: leaving the article with a narrow content (but broader name) on its current name. This includes both expanding an article instead of splitting or making a new one, and also an abstinence of renaming on splitting such an article with keeping its later expansion in mind.

Theoretically a fourth form is possible: merger by a too broad interwiki, when current article is underdeveloped compared to another languages. This may encourage some users to translate a text from that interwikis.

Advantages[edit]

Redirect-merger is a very efficient tool to deter small stubs about „the same thing”. An experienced user may cancel a redirect if he want to make an article proper.

Move-merger may serve as a quick and correct solution of some problems with low notability. It avoids troubles with a history and copyrights. Page history will like more natural rather when a new article was created and quickly merged with an old article.

Unwanted implicit mergers[edit]

In most cases silent mergers are unintended. It may lead to a good result, but it depends on context. For example, there was an article ru:Битовая карта (Russian: bitmap or bit array) originally about a bitmap structure in file systems. This article was expanded, as bit arrays have many application, not only file systems. It is good. But when an article ru:.EXE (with its actual content similar to en:DOS executable) chooses a way to be extended to something like en:EXE, it would eventually result in loss of definition, which would be unwanted for some users and at least controversial.

Also, rampant redirect-mergism could inhibit covering of some topics. Let „X1” has made a redirect to „X” when the article „X” was poor. Later, „X” became a large article without mentioning of X1 in it, and nobody is willing to describe X1 there, as this article is on X. And nobody needs to write an article „X1” because a blue link exists, which is not evidently points to „X” until browsing to it. That’s why some redirects which were useful on early stages, when some topic has too little content, have to be deleted (or replaced by stubs on sight) later.