Chore results are available on Chores page. This page defines them.
- 1 Team norms
- 2 Checklist
- 2.1 Admin
- 2.2 Regressions
- 2.3 Triaging
- 2.4 Grooming
- 2.5 Performance
- 2.6 Other
- 3 Participants
- 4 Status Update
- 5 Links
- Send an email to
email@example.com you are finished doing chores, indicating that you have done chores, who is up next, and any high priority notes
- All team members agree to read the chores email
- Team members are not expected to look at the chores page aside from when they are doing chores
- Feel free to mention team members on the chores page, but know they will likely not see the mention until they are on chores duty
- You may remove any comment in a chores cell, unless the comment mentions a team member, in which case only that person can remove it
- If you encounter something during chores that needs immediate attention either ping the relevant people directly, or include a note in your chores email
The checklist can be considered to be in priority order. Do not worry if the whole checklist is not completed.
Who is on Chores next time?
- Look at the calendar for tomorrow ("Readers Web Team" calendar)
- Do this first in case you run out of time in your timebox, and because it's quick and easy.
Check if meetings are scheduled for days off in the current week.
- If so, notify the team so that they can adjust accordingly.
Check if browser tests are failing
- Are there any browser test failures?
- If so, has the issue recurred for at least 2 builds?
- If so, is there a bug open?
- Is the bug a deployment blocker?
- Note: If a branch cut is about to happen or happening (Monday/Tuesday) extra care is needed in this checklist item.
- Find "Blockers:" in https://wikitech.wikimedia.org/wiki/Deployments#Near-term to identify the Phabricator task for deployment blockers and add as a subtask if necessary.
- If so, has the issue recurred for at least 2 builds?
Check the logs (devs only)
- Take a look at the Logstash dashboard. Is there a log entry that's new and trending or indicative of a breakage?
- Maybe it's ok if there is just a couple timeouts?
- Query to use:
(message:MinervaNeue OR message:MobileFrontend OR message:Popups OR message:TextExtracts OR message:PageImages OR message:RelatedArticles OR message:QuickSurveys OR message:WikidataPageBanner) AND NOT type:scap AND NOT type:log4j AND NOT level:"INFO" AND NOT level:DEBUG AND NOT host:mwdebug1002 AND NOT host:mwdebug1001 AND NOT message:"Memcached error for key" AND NOT message:"SlowTimer" AND NOT message:"entire web request took longer than 60 seconds" AND NOT message:"User->saveSettings()" AND NOT message:"AuthManager::autoCreateUser" AND NOT message:"CSP report" AND NOT message:"LoadBalancer" AND NOT message:"TransactionProfiler"
Review the MobileFormatter lead paragraph transform on Wikimedia content (devs only)
We currently move lead paragraphs so they appear above infoboxes. On English Wikipedia we have logging in place to tell us when this is not working, which may be the result of editors adopting a new template. If time/interest allows check logstash (the query used is
message:"Found infobox wrapped with container on").
If the number of logged events has spiked comparatively to historic data (e.g. it was 10 per hour and now its 1000), this may be an issue with the templates or the code so flag it. One off issues shouldn't be a concern.
At time of writing, less than 120 events per day should be expected.
Review the EventLogging validation errors (devs only)
- Take a look at the following Kibana query.
- Note the daily rate of validation errors for now.
- Is any one EventLogging schema failing validation more frequently than all others?
- Note: Logstash has only been ingesting EventLogging validation errors since Tuesday, 27th November.
Review the Web Dashboard
- Are there tasks we are responsible for in the Triage section that need to be tagged with "Readers-Web-Backlog"?
- Are there tasks that need to be escalated to "Unbreak Now!" status and pulled into the sprint?
Sometimes users incorrectly tag our bugs...
- Are there any new tasks tagged mobile in the "needs triage" column?
- Tasks that are not Readers Web specific should be moved to triaged (tag with relevant teams if you know)
- Tasks that are Readers Web specific should be tagged with "Reading Web backlog" and relevant components.
Check if there are patches from volunteers
- Are there any patches from volunteers?
- Associate volunteer patch with task if one exists
- If task exists escalate to team code review etc. as necessary by adding the sprint tag.
- Leave a comment to explain the action.
Review the Reading Web Backlog
- Are there tasks in "Incoming" that need priorities and important enough to be moved to "Needs prioritisation"
- Are there any tasks out of the remit of the team in "Incoming" that can be moved to "Tracking"?
- Are there hidden Priority=Low/Lowest tasks in the "To Triage" column? (Tip: use the filter link on the lefthand menu of the board).
- Are there any stalled tasks that have been lost/forgotten?
- Are there tasks that haven't been poked (old) in a while? Poke them!
- Are there any stalled tasks that can have their status updated to open?
Review grafana dashboards (devs only)
- Take a look at the following dashboards:
- and consider:
- Any changes in beta opt-ins/opt-outs
- any changes in activity to schemas?
- Did a sampling rate change?
- Did the conditions change unexpectedly?
- Did the schema become inactive? Is there a task to remove the code?
- Is there anything suspicious about the beta cluster in comparison to production?
- If so, is WebPageTest acting up? Check out the sitespeed.io instance.
- Then is there a campaign active?
- Then does it correlate with other performance dashboards based on Real User Monitoring (RUM), e.g. https://grafana.wikimedia.org/dashboard/db/navigation-timing.
- Are there any obviously related entries in the Server Admin Log (alternate UI link)?
- Consider the differences between the beta and production Barack Obama articles
- The idea of these graphs is to get a sense of what the next train push will lead to e.g. will it increase bytes or decrease bytes?
- Have the HTML and image sizes deviated considerably? If so re-import the article from production.
- How do JS/CSS differ? These values should be very very close. If they are not, it probably warrants investigation.
- Is the next deploy likely to reduce bytes shipped, result in no change or increase them?
- If there is any difference between the values - debug.
- Have any new extensions been deployed or changed that might have led to an increase?
- Did we do any refactoring that may have led to a decrease?
- Did a new feature we've been working on it increase our payload?
- Is it possible MediaWiki.Mobile.js or MediaWiki.Mobile.css may need updating on the beta cluster?
- Consider investigating any CSS/JS differences in the history of http://wpt.wmftest.org/
- Do the same for the Page Previews Perf dashboard.
Is today the last working day of the month? If not, then skip the rest of the section. If yes, check if puppeteer has a newer version compared to the one being used in chromium-render-service. The latest version can be seen at npmjs.com. If not, then skip the rest of the section. Otherwise, if you're a maintainer of chromium-render-service, then upgrade puppeteer to the latest version. If you're not a maintainer, then send an email the reading-web-team list asking a maintainer to upgrade the package.
Reading web design backlog
- Does Alex need any help from developers or Olga?
- Do developers need input from Alex on any tasks?
Say something nice to a team member!
An optional opportunity to say something nice about some work a team member has been doing. It might be gratitude for their help on a task; or a general show of admiration. It's nice to celebrate.
- Jon R
We alternate on Fridays.
The team member responsible for their time frame should email their progress via the daily standup email threads.