Why creating new wikis is a bad idea

(English) This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.

See also: Not my wiki

In addition to the project-specific wikis (e.g. Wikipedia), and Meta (this wiki), a number of new wikis have been set up for specific activities. These include the Outreach, Usability and 10th birthday wikis: see Wikimedia wikis for a full list.

Content forking

Creating a new wiki can be considered synonym of content forking, on which see separatism. Content forking is a situation where a topic is worked on in two (or more) different places instead of working on a single shared version all together.

MeatBall:ViewPoint is the original proposal (~2003) of a wiki where every opinion would have its own version of a page. The conclusion was that «ViewPoint is nothing like a wiki». Clifford Adams summarised this option as Community be damned: «a wiki [...] forces the community to deal with disagreements about content».

MediaWiki is a wiki where collaboration is made automatic by a technology solution: one topic, one title, one page; meaning everyone is forced to work on the same topic in a single place. This is a built-in push towards DefendAgainstPassion, required for Neutral point of view («I for one am passionate about presenting truth neutrally. -- TimStarling»).

Negative effects

Creating such wikis is a bad idea because:

• It segregates the wiki's activity from the Wikimedia community (which will be most active on their home wiki or, if they are interested in multi-wiki activities, meta). This will reduce the capacity and effectiveness of the given activity, as well as excluding community members from that activity.
• Individual wikis may be blocked by schools and businesses (due to being "uncategorized" by web-filtering services, such as http://www.websense.com/, which currently blocks outreach and tenwiki), reducing their accessibility.
• It reduces/dilutes the community presence on Meta, splitting it up into various different silos of activities. This will overall degrade the quality and breadth of the discussion on Meta, and generally about the meta topics about Wikimedia.
• It requires new users to set up their preferences, import their javascript/css options, etc. again (and then maintain them). This presents an unnecessary obstacle to participating in the conversations happening on the new wikis.
• It requires new users to start another watchlist, which they may not keep track of as easily as a watchlist on meta or their home project. This reduces the likelihood that new users will be continuing to use a given wiki.
• It creates 'ghettos' when the wikis stop being used, but are still publicly viewable and editable. Similarly to separatism, this can lead to problems with vandalism, or eccentric editors, as well as unnecessarily degrading the external views of Wikimedia projects.
• It creates organisation-owned wikis, similar to factionalism; e.g. the Usability Wiki is very much a Wikimedia Foundation wiki rather than a community wiki. This can discourage people from contributing to that wiki, where those people come from a community and/or chapter background.

This is not to say that creating new project wikis, which might attract new contributors to the Wikimedia project, is a bad idea - just that creating new 'meta' wikis where a central wiki already exists is not a good idea. It is also not an argument against chapter wikis nor the wmf:Wikimedia Foundation wiki, which are needed to represent individual organisations.

Merging wikis

Merging wikis is relatively simple if there are no access control issues, although many merges are partial. For instance, the Toolserver wiki has been merged to MediaWiki.org in 2015; previously, labsconsolewiki has been merged into wikitechwiki.

Private wikis could be merged as well, with some security precautions and a bit of MediaWiki development: see Grants:IdeaLab/A place to work together.

What is a separate wiki

What is really a separate wiki? What is a split or new wiki? It makes sense to challenge a split only if the alternative (a merge) exists.

Language subdomains

The elephant in the room is language. Per-language subdomains of most Wikimedia projects mean each topic has a separate and parallel life on each language version, though with frequent cross-semination (via translation and imitation). In contrast, the Translate extension is made to keep language versions in sync.

Language subdomains are not really a split insofar a merge is not possible: language barrier and culture barrier mean that it's physically impossible to merge the views of all languages and cultures in a single text. Only if a single global culture existed, then monoculturalism would be possible. Instead, Wikimedia projects maintain language and culture biodiversity technologically (by default), while favouring cross-pollution socially (after the fact).

It is controversial whether Wikisource has a comparable need of a language split, given that the community doesn't need to agree on the single page (text), which is defined by the original author. See w:Wikisource#Language subdomains for the history.

The identity of a wiki is a frontend concept

Tim Starling explored the concept in 2015 and said: splitting a wiki is by definition user-visible, since the identity of a wiki is a frontend concept. When you edit a wiki, your changes are immediately visible to everyone else: that's the definition of a wiki.

Wikipedias in multiple writing systems offer an instructive case. There are close language pairs, and there are distant language pairs. In MediaWiki terminology they are called variants and languages respectively. Ultimately it is for the community to decide what category they are in. The Chinese Wikipedia community have made their preference clear by inventing the concept of close language pairs in MediaWiki and spending months of volunteer effort writing the relevant supporting software. This is a community decision (sanctioned by the language committee), not a technology decision.

If you edit in one variant and then your changes are immediately visible in the other variant, then you have one wiki. If your changes go into a translation work queue and then (possibly months later) someone accepts the suggested machine translation and thus makes it visible in the other variant, then you have two wikis. The Chinese Wikipedia decided to be one wiki in this sense. At least it is a point of competitive differentiation compared to the other online Chinese encyclopedias. According to one blog post, variant support is the main reason we are winning in Hong Kong.

Users commonly understand only one variant, and therefore simultaneous editing of both variants is difficult. This is a problem the community has knowingly entered into, and technology can support them in that choice.

If we accept that machine translations will be published without user review, as an essential part of what gives a variant wiki an integrated identity, then it makes sense to work on improving the machine translation, for example by improving word segmentation.