Jump to content

Wikimedia site requests

From Wikitech

Wikimedia site requests are requests to configure a Wikimedia project. This page gives an overview of the process for volunteers handling them, and other concerned parties from operations side.

If you do not want to contribute technically, follow meta:Requesting wiki configuration changes instead.

If you want to contribute technically, then this is a good way to get familiar and start contributing to software changes. You need very basic knowledge of PHP and follow mw:Gerrit/Tutorial to create your first software change (a so-called "patch"). When you work on these types of tasks you can also look at previous similar software changes. Often you do not even have to have too much understanding of what is going on exactly. But still you can get familiar with code and especially processes!

Lifecycle of a request

A request generally follows this workflow:

  1. The local project discusses the matter in public, in the manner the most appropriated for this project.
  2. A task is filed on Phabricator, in the Wikimedia-Site-requests project (or Wikimedia-Extension-setup if the change is about enabling an extension). See meta:Requesting wiki configuration changes. Please check Limits to configuration changes before.
  3. A volunteer writes a software change (patch) to change the relevant files in the operations/mediawiki-config code repository, as we do not directly edit the code that is running live on the servers. Then the volunteer proposes this patch in Gerrit for review. (If the volunteers follow Gerrit/Commit message guidelines, then the Phabricator task will automatically get updated about their patch in Gerrit.)
  4. If no reviewer sees a problem with the patch, then the same volunteer - or if reluctant/absent/busy, another volunteer - schedules it in a backport window on the Deployments page.
  5. During that backport window
    • Important: The developer of the patch is expected to be available on #wikimedia-operations connect during the deployment window to help test the patch
    • If the deployer sees no problem with the software change (patch), it's merged by the deployer giving it a "Code-Review +2" review and deployed on the Wikimedia servers, usually within one week but sometimes also faster.
    • If the deployer finds a problem with the software change, they may ask for revision. Or the deployer may ask for someone to give additional review of this patch in Gerrit if they are unable to review the change.

After the backport window, everybody who visits a Wikimedia server will see / experience that change.

Prioritization

Requests are usually handled quickly. We can deploy (make the changes available on the servers) trivial changes three times per day between Monday and Thursday.

Priority on Phabricator Description
Unbreak now! The change fixes a problem that must be fixed immediately. You want a deployment right now or in the next hours. That also means you think that your request is more important and urgent than any other requests.
High The change is needed very soon, ideally in the next backport window, or if not possible, this week (Monday-Thursday).
Medium The change is helpful, we can do it this week or the next (so in max. 7-10 days). This is the priority assigned to most simple tasks.
Low The change isn't needed before two weeks or there is nothing actionable before a long time.

Common tasks

Disable throttling of account creations for an IP at events

Often requested by editors who are hosting an edit-a-thon, account creation throttle exception are one of the most common tasks which Wikimedia site requests deals with. Such requests should follow meta:Mass account creation#Requesting temporary lift of IP cap.

  • Make your changes in the file wmf-config/throttle.php in the repository operations/mediawiki-config
    • from UTC date/time of exception start
    • to UTC date/time of exception end
    • range IP range(s) the exception applies to
    • dbname wiki(s) this exception applies to
$wmgThrottlingExceptions[] = [ // T184579
	'from' => '2018-01-11T09:00 +5:30',
	'to' => '2018-01-11T18:00 +5:30',
	'range' => [ '103.8.192.54', '186.67.125.0/24' ],
	'dbname' => [ 'enwiki', 'mrwiki' ],
	'value' => 45 // 35 expected
];

If there is less than 72 hours before the event, you should run mwscript resetAuthenticationThrottle.php --wiki=metawiki --signup --ip 1.2.3.4 to purge the memcached key.

See Increasing account creation threshold.

Change the translation of a namespace

  • Namespace localization must happen in the extension that the namespace belongs to.
  • Namespace localization can require separate patches in some repositories. See e.g.
  • To deploy a custom namespace only on Wikimedia sites (and not in the MediaWiki software for everybody), the file to change is wmf-config/core-Namespaces.php in the repository operations/mediawiki-config. This file also allows you to change project namespace (wgMetaNamespace).

Change the linktrail

Update the interwiki cache

Change local group rights

  • Change/define the group's right under GroupOverrides in the file wmf-config/core-Permissions.php in the repository operations/mediawiki-config
  • Change who can grant the group using (Add|Remove)Groups(Self), otherwise, only the stewards will be able to grant/remove it.

Change user groups and restriction levels

Enable or disable extensions on a wiki

Change import sources

Convert digits (numbers) into a different script

Remove a namespace from being indexed by internet search engines

Change the default timezone for a wiki

Add additional letters to the special characters toolbar

Add a wiki to a dblist

See Configuration files#dblists.

Areas in the MediaWiki code base itself

These tasks are about the general MediaWiki code base itself, and not about the configuration of MediaWiki on Wikimedia servers like the tasks above.

Replacing deprecated functions

These functions could be found by phan checks or a good IDE with static analytic code checks.

Upgrading dev libraries

This is sometimes done by a bot, but that is not always and not everywhere the case.

Alphabetize stuff

Common tasks that need a maintenance script

This section is meant to document site requests that require a maintenance script to be executed shortly after deploying the patch, to ensure the configuration change takes the intended effect. See also Backport windows/Deployers#Maintenance_scripts.

Add a custom namespace

  • Add the new namespace under wgExtraNamespaces in the file wmf-config/core-Namespaces.php in the repository operations/mediawiki-config. In the namespace name, make sure to replace spaces ( ) with underscores (_).
  • Past examples: phab:T221697 and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/506134/
  • Script: After the change has been deployed (merged), run namespaceDupes.php to ensure no page will be left unaccessible.

See also: mw:Manual:Using custom namespaces

Change a namespace

  • Make your changes in the file wmf-config/core-Namespaces.php in the repository operations/mediawiki-config
  • If necessary, also alias old names under wgNamespaceAliases in the file wmf-config/InitialiseSettings.php in the repository operations/mediawiki-config
  • Past example: phab:T202347 and https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/454213/
  • Script: After config change is deployed, run namespaceDupes.php maintenance script to no page will be left unaccessible.

Change category collation

  • Make your changes in the file wmf-config/InitialiseSettings.php (under wgCategoryCollation) in the repository operations/mediawiki-config
  • Past example: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/889762 and phab:T329815.
  • Script: After config change, run mwscript updateCollation.php --wiki=xxwiki --previous-collation=uppercase to ensure the change takes effect.
    • NOTE: In most cases, the previous collation is uppercase, but double check that before running the script.

Change the logo of a Wikimedia wiki

Please follow the instructions in the logos directory of operations/mediawiki-config for converting a Commons SVG into the correctly compressed PNGs and updating the PHP files.

Read meta:Logo, especially the Temporary logo variants section.

You can test how a new logo will look at https://logo-test.toolforge.org/test?wiki=xyz.wikipedia.org&logo=File:FilenameOnCommonsOfTheNewLogo.svg&useskin=vector (replace xyz.wikipedia.org and FilenameOnCommonsOfTheNewLogo.svg accordingly)

Past examples: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/921610, https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/905544, https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/704996

Script: Run echo 'https://en.wikipedia.org/static/images/project-logos/XXwiki.png' | mwscript purgeList.php (the domain is always en.wikipedia.org, even for other wikis). The command needs to be executed for each HD version (-1.5x.png and -2x.png suffixes), or any other file changed in the /static folder. See also Backport windows/Deployers#Purging.

Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=Wikimedia_site_requests&oldid=2187936"