Readers/Web/Team/Pushing production code from beta to stable

The reading web team use Extension:BetaFeatures and the built in MobileFrontend beta mode ($wgMFEnableBeta = true;) to test, validate code against real users and gain feedback. When we are comfortable with a new change we push it from the beta to production environment.

Benefits

 * Via EventLogging get a sense of how a feature performs
 * Allow time for translators to translate a feature
 * Test features against real data / edge cases.

Developing features for beta

 * Keep code sandboxed from stable. Use ResourceLoader modules and the SkinMinervaBeta class for mobile (or hooks for desktop). This will minimise regressions to production code.
 * Feature flag features

Pushing to stable

 * Make sure when pushing code to stable that browser tests are in place
 * When replacing existing features be sure to remove old browser tests
 * Avoid changing any message keys or ResourceLoader module names to avoid hitting caching problems
 * Optimise for allowing reverts
 * When replacing existing features, keep old ResourceLoader modules in the repository. This allows reverting to happen if an unforeseen problem is found in the new feature.
 * Ideally new features should be feature flagged and pushing to stable should simply involve toggling a switch.
 * The Product manager, Quality assurance (if available) and designer should be engaged as soon as a feature is pushed to production. A card should be signed off in the current sprint before the close of play on Wednesday, the day before it rolls out to production for all users.

Signing off changes

 * Retain any old code for at least 2 weeks, to aid any necessary reverts, then remove from the repository.
 * Remove EventLogging within a month.
 * Ideally we should be able to collect all data we need within a month.