Reading/Web/Chore list

Chore results are available on Chores page. This page defines them.

Chores Norms

 * 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 email the team list.
 * If it's your chore day but you'll be away, don't worry about it. Someone will pick up chores the next day on rotation.
 * If you'll be away for a long time (weeks and weeks, e.g. sabbatical or health reasons), talk to the team about it. A train day might also be relevant.
 * Chores are timeboxed to an hour! Don't overdo it. Use your better judgement if you must do longer than this, but let the team know when that happens so we can catch outliers. This also helps inform the team if Chores need changing.
 * Specialists can feel free to focus on their specialty first. For instance, we don't expect our designer to look at logstash, but rather focus on design stuff.
 * On the other hand, don't skip the board-grooming type stuff if you can help it. We're all in this together, where possible. :)
 * Since chores are timeboxed, the chores are also in priority order.
 * You're generally expected to start from the top and work your way down. If the stuff at the bottom doesn't get attention for a while, that's theoretically OK, since it was not a high priority. If that stuff really does need attention (i.e. there are more high priority items than time) we should review chores and see how to resolve that.
 * In practice, we are often selective in the chores we do, and it has been fine. Please be judicious when you do this. Remember: a chore you don't do is one someone else must instead.The priority-order approach is designed to mitigate the emotional labor everyone must do to determine importance of chores.
 * Feel free to suggest adding or removing chores on the team list.

Checklist
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.

Meetings
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.

Check the logs (devs only)

 * Take a look at the Logstash dashboard and follow the instructions in the chore row where it states to create a ticket if there is an error > 100 occurrences per 12 hours.

Review the EventLogging validation errors (devs only)

 * Take a look at the following logstash dashboard.
 * Is any one EventLogging schema failing validation much more frequently than all others? If so, file a ticket.

Review the Web Dashboard
https://phabricator.wikimedia.org/dashboard/view/125/
 * Are there tasks we are responsible for in the Triage section that need to be tagged with "Readers-Web-Backlog"? If so, please tag them readers web backlog
 * Are there tasks that need to be escalated to "Unbreak Now!" status and pulled into the sprint?

Review #mobile
https://phabricator.wikimedia.org/tag/mobile/

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 the Gerrit dashboard
Using the gerrit query on the chores page
 * Is anything listed that doesn't have an assignee?
 * Are there any patches from volunteers?
 * Is that patch useful given current priorities and team bandwidth?
 * If not, add the hash tag "priority:low" to the patch with a comment explaining we don't have bandwidth right now
 * Add team hash tags if it's outside the team's reviewing responsibilities:
 * the hash tag "team:wikimedia-de" if Wikimedia Germany will take care of review
 * the hash tag "team:growth" for Growth team
 * the hash tag team:editing" for editing team
 * If it is, check in the team channel if somebody can be assigned to the task
 * 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
https://phabricator.wikimedia.org/tag/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:
 * generic dashboard
 * mobile performance dashboard
 * beta dashboard
 * search performance dashboard
 * and consider:
 * 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/d/000000143/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.
 * Also examine the Vue vs. Legacy search performance dashboard for any alarming deviations

Check talk pages
Review any recent changes on Special:RecentChangesLinked/Reading/Web/Pages to watch. Are there any unanswered questions on talk pages that should be directed to people? Identify people that can answer the questions being raised and either ping them on the talk page or start a Slack/email thread linking to the topic.

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.

Participants

 * 1) Olga
 * 2) Nick
 * 3) Jon
 * 4) Jan
 * 5) Clare
 * 6) Bernard
 * 7) Moh'd

Status Update
The team member responsible for their time frame should update their progress via the wiki page.

Links

 * Markdown editor template (Prettifies links to phab tasks and gerrit patches)
 * How to update this link 👆
 * Chore wheel Google Sheets template

Updating Slack reminders
We try to distribute chore duty evenly among the team which works out to average around 1-2 times every 3 weeks per individual (see rotation list on the Chores page). This fluctuates with changes in team members and occasionally we need to update the Slack reminders accordingly.

To see the reminders list:

To delete a specific reminder, click "Delete" next to the specific reminder upon viewing the reminder list.

To add a new reminder: