Setting up an internal Wikimedia wiki

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

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎한국어 • ‎Lëtzebuergesch • ‎polski • ‎português do Brasil
Requests and proposals Setting up an internal Wikimedia wiki
This page describes the creation of internal wikis for Wikimedia activities, committees, and affiliates. See Requests for new languages for information on creating a Wikimedia project wiki in a new language, and Proposals for new projects for suggesting the creation of a new project wiki.

In additional to Wikimedia's core project wikis and additional project content wikis - the Wikimedia Foundation also supports a number of internal wikis. They include public, private, and fishbowl wikis and are used by Wikimedia affiliates, planning projects, committees, and project wiki support efforts.

If you plan on setting up an internal wiki, this page will give you a starting point based on how other internal wikis have been created and organized.

Basics[edit]

  1. Get consensus - is this wiki really needed? What will it be used for? Has the relevant community, arbcom, or WMF body, that is responsible for the wiki, agreed to its creation?
  2. Request a wiki be set up. The route for this is via a request through Bugzilla.
    1. File a bug in Wikimedia's bug tracker;
    2. Use "Wikimedia" for the product and "Site requests" for the component.
    3. Be sure that the bug includes a URL to the local on-wiki consensus, preferably using a permanent link (click the "Permanent link" link in the toolbox, which should make the URL end in &oldid=...); the page at this URL should also link to the main bug "description" box (comment 0);
    4. Also be sure to add the "shell" keyword to the bug;
    5. What abbreviation / subdomain (URL) will it have? Discuss with Bugzilla participants if needed.
      • The abbreviation should only be one level and must be a subdomain of an existing Wikimedia site, in almost all cases it should be .wikimedia.org. Hosting a new domain would require a new SSL certificate purchase and setup. Instead, it is recommended that you redirect any new web domains to the subdomain of an existing Wikimedia Foundation operated domain.
        • Examples: ex.wikimedia.org - ex-yz.wikimedia.org - exyz.wikimedia.org - ex.mediawiki.org
        • Not: ex.yz.wikimedia.org - exyzwikimedia.org
  3. If the wiki needs special configuration when it is set up, then request that at the same time. Examples:
    • Who can read it?
    • Who can edit it?
    • Is account creation by approval only, or by anybody clicking on "create an account"?
    • Is email notification to be switched on? (usually yes)
    • Should certain extensions like Translate or VisualEditor be switched on?
    • Are any special namespaces required? (For example, OTRS Wiki might have a namespace for "Response:" and "Response_talk:")
    • Are any custom settings for upload needed - for example is upload disabled, or unusual file types allowed?
    • (See also: Help:Configuration)
  4. After you submit your Bugzilla request, consider adding yourself to the CC list of email recipients of updates to the request, and be sure to follow the request on Bugzilla and help answer any questions that may come up during the discussion.

Your wiki will have at least one bureaucrat account, that can be used to create sysops and other bureaucrats. You will want to test that the basics of your wiki - log in; verify you have bureaucrat rights; verify the correct privacy setting and visibility exists; verify that upload works; verify that editing works. These all require setup at the server end, and once working will continue to work. (Initially some specialist formatting may not - see below.) You will also want to create accounts, and sysop/bureaucrat these as necessary.

Congratulations - once your request is reviewed in Bugzilla, discussed, and approved - you will have your wiki!

Wiki config[edit]

A new wiki is like a new house - walls, floors, doors, windows, nothing else. There are an infinite number of ways to set one up internally. Rather than reinventing the wheel, this page describes a setup that's been used before and works well. It contains markup you can cut/paste to create basic pages if needed. Feel free to customize it!

Note: Included in the attached information are instructions how to import the standard .js and .css configurations, to allow tables, and other customized wiki formatting you may be used to. Hence these are not repeated here. A number of variant pages for one very common use - internal arbcoms - are also described. Ignore these if they don't apply to you. The examples are geared to small, focussed wikis (arbcom, working groups, chapters, and the like). Last, if your wiki is not in English, you will need to translate any text you use.

Pages setup

See Sample pages for copy-and-paste markup.

The same page also contains markup for useful documentation pages covering import of js and css, sidebar and main page handling, and so on.

Specialist formatting (CSS, JS)

The import of table classes and formats, and common JS (script) to work with these, will need importing. The above page contains wiki-markup for a documentation page that explains how to do this.

Main Page privacy

The official Main Page can be seen by anyone, as can any transcluded information templates. You also cannot delete revisions from it. Accordingly if your wiki is private, you should make your main page a "public" page for passers-by that points those with accounts on the wiki to a secondary main page (i.e. Portal)

See also[edit]