Reading/Web/Release manager

Team responsibilities
Designers/PMs: Please bug the release manager about anything deployment related. If there is a bug in production that needs fixing this is your point person. Note the check talk pages chore is no longer occurring, so please make other arrangements for that if necessary.

Developers: Please let the release manager know about any issues you foresee with the upcoming release. This should include Pixel UI regressions that are intended, as well as letting them know about any bugs which need to be fixed before the train rolls out.

Engineering manager: Please check in with the release manager when problems do occur to identify reasons (the idea here is not to blame but look for ways we can improve our releases)

All week

 * If there is an e-mail alert, you are responsible for investigating it promptly (ideally within an hour) (or delegating to someone to investigate it) and taking appropriate action (e.g. changing the alert/blocking the train/arranging a backport).
 * Any backports that are needed during the week are your responsibility.
 * Please communicate any deployment blockers to the release engineering team that should delay the train as they occur. For example if on Wednesday an UBN is discovered, it's your duty to make sure that doesn't get onto English Wikipedia on Thursday. For example 1.41.0-wmf.14 deployment blockers task is: https://phabricator.wikimedia.org/T337528
 * Chores (you can do these daily but MUST do them on the days as detailed below) The chores page has been reflected with suggested dates @ https://www.mediawiki.org/wiki/Reading/Web/Chores

Monday

 * Please let the release engineering team if there are any risky changes they should know about during the train deployment. If you are not sure if there are risky changes, check the board and/or ask your team mates.
 * Chore: Visual regressions
 * Check Pixel and browser tests
 * Pixel should show 0 regressions by the end of Monday either by tagging expected regressions or fixing/reverting unexpected regressions. Consider instigating a code-freeze if the error rate is high.
 * To tag expected regressions you must ssh into the Pixel box and update the command like so:

ssh pixel.reading-web-staging.eqiad1.wikimedia.cloud sudo vi /srv/pixel.sh
 * 1) update the line reference="-b latest-release"  to be reference="-b latest-release -c "

Wednesday, Thursday, Friday

 * Chore: Logstash Check logstash errors, with a focus on group 0 and 1 wikis. Anything abnormally high would indicate a regression for Thursday. If so, create a ticket and consider making it a deployment blocker or preparing for a Thursday deployment. Check validation errors if any tests are being run.,
 * Chore: Review dashboard - Check the triage board for any bugs that may have been filed against the current train and make sure all tasks are in the backlog in preparation for the Thursday grooming session.
 * Make sure any UBN tasks have been deployed and that logstash is in a healthy space.
 * Check performance / web dashboards for any regressions that may have occurred during the course of the week creating tasks

Friday
Leave everything in a good state for the next release manager. For example, if there are visual regressions, don't leave them to have to do everything on Monday!