Beta Features/Package

Beta Features help Wikimedia designers and engineers test out new features or significant changes to existing features.

Basic requirements
Projects added to Beta Features must meet the following requirements:
 * Not significantly degrade site performance;
 * Not noticeably degrade perceived performance of the site, or the user's system;
 * Not crash the user's browser;
 * Not cause data loss, or corruption; and
 * Contribute positively to the user's experience of the site, and be additive in nature. e.g. Beta Features cannot be used to remove site features or functionality without adding features meant to replace what was removed.
 * Pass basic interoperability with other Beta Features features (this is not to say that interoperability is a blocker. Interoperability issues need to be surfaced, and blocker-ness will be determined on a case-by-case basis).

To check that these requirements are met, be sure to test your new feature on the Beta Cluster for at least one week before deploying to production. This testing period is intended to catch any serious bugs before jeopardizing users on production.

Getting ready
What do I need to do to get my project ready for Beta Features?

We invite developers who want to test features through this project to post their submission on this queue for new Beta Features.

To that end, here are some tips on how to prepare your feature package for inclusion in Beta Features.

Feature name
Be brief, be descriptive, and if possible be fun, or at least don't talk like a robot.

Style: Use Title Case, don't use the word experiment, feature, or beta, in the name of your feature

Good = Bigger Pictures, Bad = Enlarged lightbox Image Experiment

Details: 30 characters max length, one line, no wrapping.

Feature description
Tell users what your feature does, why they would want to turn it on, and any major issues they may encounter.

Details: 255 character limit

Feature images
SVG, will be displayed at approximately 200 px wide by 100 px tall. RTL, and LTR versions if applicable.

File:BetaFeature Image template.svg is available.

Project page link
Provide a link to the MediaWiki.org project page for the feature: a simple, straightforward page written in the user's language, it may not be the same as the project page used internally for development.

Talk page link
Normally the project page's associated talk page. It can be localised for each wiki (e.g. pass Beta Features a message, so that the link can be translated and varies according to the user interface).

Browser and platform compatibility list
Provide a list of browsers or platforms with which the feature is incompatible.

Provide error string if for some reason the default error string "This Beta Feature is not yet compatible with your browser" isn't good enough.

Details: If providing alternate error text, please keep it brief and non technical.

Prerequisites
Provide the names of any other Beta Features that must be enabled for your Beta Feature to function correctly.

Post your submission
When your new Beta Feature is ready, please write a detailed description and post your submission on this New Features page. This will help WMF Engineering, Design and Product teams discuss your feature and coordinate its deployment with you.

Release requirements
See Review queue and Review queue for a complete/general guide.


 * 1) Make an extension
 * 2) Get preliminary design review
 * 3) Get preliminary security review
 * 4) Get preliminary performance review
 * 5) Make sure there is a wiki page on MediaWiki.org for it that is understandable to the general public
 * 6) Ensure that the talk page for the project is using Flow
 * 7) Make sure there is someone on point for feedback, acting as a product manager (either volunteer or WMF staff)
 * 8) Make a Phabricator project for the extension
 * 9) Enable the "final version" of the code on Beta Cluster at least a week before you want to go for production.
 * 10) Make gerrit change (do not merge) to the Beta Features whitelist in mediawiki configuration
 * 11) Deploy!

"Graduation" requirements

 * 1) Most people are happy with your feature/change
 * 2) It's agreed to be a good addition to the site, balancing features, design complexity and performance
 * 3) All major bugs and obviously missing features are fixed
 * 4) It passes a second design, security and performance review as per review queue
 * 5) You have run it as the Beta Feature in "final configuration" (with only the bits you intend to deploy, and no others) for at least two week before deployment.
 * 6) Get agreement from James/Greg
 * 7) Merge your code into an appropriate venue (usually MediaWiki core or an existing extension) behind a feature flag
 * 8) Deploy, removing your Beta Features code from the servers and the Beta Features whitelist entry from mediawiki configuration