Review queue

This page documents the steps needed to get MediaWiki extensions through the review process before possibly being deployed to Wikimedia wikis. Anything that is deployed on the Wikimedia cluster needs to be reviewed for security and scalability issues. Where the word "extension" appears below, "skin" or "code" is synonymous.

Writing an extension for deployment can be a time-consuming project; any interested party is encouraged to start the process long before any deadline.

You can see the list of all extensions awaiting review.

Once an extension has made it through reviews, then the extension can be scheduled for deployment by the Wikimedia Foundation Release Manager.

General prerequisites and expectations
Follow the general guidelines and recommendations on writing extensions. Read Coding conventions, Pre-commit checklist, Performance guidelines, and Security for developers and make sure that your code follows these guidelines.

Once above steps are done, consider getting community support for your idea:
 * Documentation:
 * Create an  page in the Extension: namespace on mediawiki.org to document for developers and people who will install or configure the extension. Use Template:Extension for this.  You may use the field below to assist you with it.
 * Create a  page in the   namespace on mediawiki.org for your extension's end-user documentation. Cross-link it with the   page above. Also see Manual:Developing extensions. Example: Help:VisualEditor/User guide. Screencasts can be useful in explaining how things work.  You may use the field below to assist you with it.
 * Code hosting: Request a new Git/Gerrit repository to store the source code for your extension. Gerrit is where all code review will happen.
 * Issue tracking: Request a project in Phabricator to track bugs and feature requests for your extension. Get notified of new tasks reported in your project.
 * Localization: Your extension will need to be translated on translatewiki.net before it can be deployed anywhere. This requires your code to have proper i18n files etc.
 * Gating deployment and feature flags: The Wikimedia Foundation runs nearly a thousand wikis in hundreds of languages. When we deploy code on our cluster, we enable extensions on a wiki-by-wiki basis and often configure them differently for each one. Extensions should have feature flags (e.g., ) for turning particular behavior on and off or configuring some part of the extension, where that makes sense. When extensions are deployed, they will be gated behind a Wikimedia-specific global configuration variable such as  . This allows the extension to be deployed on a subset of wikis (for example, [//test.wikipedia.org test] and [//test2.wikipedia.org test2]) without affecting all wikis. You can search through the existing very large CommonSettings.php and InitialiseSettings.php for reference.
 * Unit testing: Be nice, prepare for sufficient automated testing. Various parts of the code needs different types of testing. In particular check out Manual:PHP unit testing and Manual:JavaScript unit testing.
 * Database schema: See Development policy. If your code requires a schema change (e.g. a new column on an existing table) either for core or an extension, keep in mind the schema change may happen only years later on the Wikimedia cluster. If at all possible, avoid schema changes.
 * Compatibility: Your extension must be compatible with all extensions deployed on the Wikimedia cluster. See below for specific issues.
 * Hosting a test version: Cloud VPS projects can be used to host test wikis with your extension installed for testing and demonstrations. See the Cloud Services Getting Started guide for more information.
 * Add your extension to Developers/Maintainers and indicate who the maintainers are.
 * Get initial code reviews: Try to get some trusted and established MediaWiki developers to follow your project in Gerrit and to look over your code and point out any flaws in it. If you do not have any particular developers in mind, ask in IRC or on the developers' mailing lists. Tell them you're following this guide so they can look for things that would block deployment.
 * Add your extension to Developers/Maintainers and indicate who the maintainers are.
 * Get initial code reviews: Try to get some trusted and established MediaWiki developers to follow your project in Gerrit and to look over your code and point out any flaws in it. If you do not have any particular developers in mind, ask in IRC or on the developers' mailing lists. Tell them you're following this guide so they can look for things that would block deployment.
 * Community support can be shown by having an active discussion on the need of the extension on a wiki and documenting the responses. If there is no active community support, support can be built through discussions and proposals.
 * Post your idea to the wikitech-l mailing list to get feedback from experienced developers and Wikimedians. People may point you to another extension that is already in use whose functionality duplicates what you want, or could be easily extended to do what you want. In that case, you should use Git to work on the extension that is already in use.
 * Communicate your ideas and plans to affected wikis to garner both support, suggestions, and other feedback.

If you have followed the advice above and the feedback given by early reviewers closely, you probably won't have too much of a problem with the next steps.

Preparing for deployment

 * 1) The production deployment tracking task:
 * 2) * Create a task in Phabricator (in the #Wikimedia-Extension-setup and #Wikimedia-Extension-Review-Queue projects) to get an extension into the review queue. This task should only concern deployment itself. Any issues which block deployment should be separate subtasks (listed under "Task Graph") that block this parent task.
 * 3) * Your deployment tracking bug should point to on-wiki community consensus (and/or community support/desire) for having the extension installed on a particular wiki, if applicable.
 * 4) Good practice: Make the below reviews easier and faster for the reviewers by creating a MW-Vagrant role for the extension.
 * 5) Request and incorporate feedback the needed reviews: (you can include these as a "checklist" in the tracking task's description, e.g. T190716)
 * 6) A security review: Open a security review task and mark it as a subtask of the main deployment task
 * 7) A product review, if applicable
 * 8) A design review, if applicable.
 * 9) A  beta feature review, if your extension adds a beta feature.
 * 10) If you have reasons to think that a database review is needed, create a request in Phabricator.
 * 11) Any serious issues identified in these reviews must be addressed before deploying your code.
 * 12) After the security review, request deployment to the Beta Cluster (this can aid the other reviews). See  below for more information.
 * 13) Make sure the extension is automatically branched by make-wmf-branch.
 * 14) *IMPORTANT: Do this early! Ideally, at least three weeks prior to your target deployment date, to ensure that your extension is present as a submodule in the required branches. (The extension submodule must be present in all branches currently running on the cluster, or the localization cache builder will fail.)
 * 15) Request a date/time for deployment in the deployment tracking task to get it added to the deployment calendar.
 * 16) * "You" (the person or persons driving/requesting this) will need to be online (on IRC in ) and available during the deployment to respond to any issues that might arise.

Compatibility with other deployed extensions
As written above, your extension must be compatible with all extensions deployed on the Wikimedia cluster. Specific issues follow.


 * Renameuser and UserMerge
 * If your extension has a database table that stores usernames, it needs to respond to the  hook to add its tables. If your extension is storing user IDs or usernames, it needs to respond to one or both of the , and   hooks to update its tables accordingly. See hooks.txt.


 * Flow
 * If your extension makes edits to pages, you need to consider whether it should do this on Flow boards and Flow topics, and handle them specially. For example, the MassMessage extension can post a message on a Flow-enabled user talk page.

Deploy to Beta Cluster
Before enabling a new extension in production, it can be tested on the Beta Cluster. To do this:
 * 1) Add the new extension submodule to the git mediawiki/extensions repo if it's not already in it. Alternately, you can plan ahead and add your extension to make-wmf-branch/config.json and it will automatically pick up the submodule (when the train cycle begins) without you having to add it manually.
 * 2) Require and configure the new extension. Beta Cluster uses the same wmf-config directory in the  repository as production, but in addition Beta Cluster servers load   and   files so you can have settings that only apply to Beta Cluster. Read more about these config files). When testing on Beta Cluster before production, these can override , setting it to true on one or more Beta Cluster wikis. (Once your extension is in use in the production wiki(s) corresponding to Beta Cluster, you can probably remove the   overrides.)
 * 3) Here's the steps required to deploy a typical new extension to production (if your extension has more steps/dependencies, say Wikibase, make sure to check with someone before you deploy):
 * 4) Add your extension to  . See example.
 * 5) Add your extension config variable to   and set it to be default false. See example.
 * 6) Add your extension config variable (same as in previous step) to   and set it to be true on beta cluster wikis you want it to be on. You may want to turn it off for loginwiki (which doesn't have most extensions). See example.
 * 7) Load your extension in  . See example.

It is possible to deploy extensions that do not exist in production to the Beta Cluster. However, the Beta Cluster runs code only from the master branch in Git. You should merge code into the master branch early and often in order to exercise that code as fully as possible on the Beta Cluster before it goes out to the general public. If you have specific questions about using the Beta Cluster, you can e-mail the Quality Assurance mailing list or ask in on IRC.

Skins follow the same process (but in ) repository.