Readers/Web/How we work

The web team often works on code that affects multiple teams and products, and can at times unexpectedly have negative impacts on various interfaces and workflows (particularly gadgets). We recognize our work is high risk and often requires input from other teams. Because of this our approach to feature development is very guarded. This process is documented here for full transparency.

For requesting our help/input, please see Readers/Web/Working with us.

Input phase

Before we begin any project it is the responsibility of the designer and product owner of web to make sure teams are informed of the changes we are making.

Web team will meet with teams that we believe our impacted by our projects and share prototypes. When we share these prototypes, we hope that teams will scrutinize these prototypes and flag any concerns or potential problems early so we can accommodate this in our development. Often we will be able to flag where other team's require our input ourselves, but sometimes, particularly with complex products (for example VisualEditor) we may need to rely on other teams to help us spot potential negative consequences of the changes we're planning on making.

The web team's engineer is responsible for reviewing the proposed changes and identifying obvious blockers with other teams to help define a reasonable timeline. It's recommended that they make use of meetings with other tech-leads e.g. the new core experiences engineers sync to uncover team dependencies as early as possible.

Development phase

During development, we track all work in our Kanbanana board which is a milestone of the Readers-Web-Backlog Phabricator board. We encourage other teams to dip into this board every 2 weeks to get a sense of the work we do, however generally avoid the need to bother other team's unless blockers were identified in the input phase.

Sometimes new information is learnt during development that may involve input from other teams. We will reach out as we discover these potential blockers via Slack.

Importantly, the web team endeavors to feature flag any new change to MediaWiki. This means features are disabled by default and only accessible by a query string. There are occasional exceptions to the feature flag rule, for example we would not feature flag a small CSS modification such as a color change.

Unbreak nows and train blocking tasks

The web team considers any unbreak now task as something that needs to be fixed within the day (usually within a few hours in the morning). When we encounter one we will take it very seriously and drop everything to work on it.

To communicate with us tasks that block deploys, please set the priority as high and mark them as subtasks of the relevant #train_deployments card.

If the task blocks a train that is currently in the process of being deployed, or for which deployment will begin within the same day and meets the criteria set in wikitech:Deployments/Holding_the_train#Issues_that_hold_the_train please mark it as unbreak now per Phabricator/Project_management#Priority_levels.

Testing phase

We will test every individual patch on patchdemo and on the beta cluster using query string parameters. When development of the feature has judged to be at a sufficient level, we will enable the feature on the beta cluster. We do this to get more eyeballs on the feature - particularly from other teams who may have not been following closely during our development phase. Note, that the web team enabling on the beta cluster does not signal the web team deploying code via the train, it simply means we are inviting further testing and scrutiny.

Given teams use the beta cluster in different ways, in particular for testing, going forward when enabling features on the beta cluster, the engineering lead is responsible for leaving a note in #engineering-all and #humansoftheweb and pinging directly the engineering leads and product owners of Growth, Editing and any other teams we are explicitly looking for feedback from. The purpose of this is to inform those teams and identify areas we need to consult with those teams prior to deployment.

Deployment phase

Any feature that is deployed in production should have been on the beta cluster for an absolute minimum of 1 week and ideally 1 month. The purpose of this is to invite scrutiny and uncover issues. Whoever is deploying a configuration change is responsible as part of the deployment process for making sure a note in #engineering-all and #humansoftheweb as a courtesy.

Before deploying, our product owner is accountable for ensuring that their product owner peers are aware of the change and sign off on a deployment to production. Each product owner should check with their engineering lead for any potential blockers

When deploying, we will always deploy to a small group of wikis first. This maximizes our ability to catch issues before they are mainstream through use of the features by our community.

Whoever is deploying a configuration change is responsible as part of the deployment process for making sure a note in #engineering-all and #humansoftheweb as a courtesy. It should link to the associated Phabricator ticket and clarify the scope of the deploy.

Note: The web team will seldom let changes roll out on the train. The only time we will do this is if we are forced to technically e.g. caching concerns. When this happens, we will inform other teams on #engineering-all and #humansoftheweb, in case they raise any concerns that might block such a change.