Reading/Web/Chore list

From MediaWiki.org
< Reading‎ | Web
Jump to navigation Jump to search

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

Team norms[edit]

Chores Email[edit]

  • Send an email to reading-web-team@lists.wikimedia.org when you are finished doing chores, indicating that you have done chores, who is up next, and any high priority notes All updates happen on the wiki page now.
  • All team members agree to read the chores email

Chores Norms[edit]

  • 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[edit]

The checklist can be considered to be in priority order. Do not worry if the whole checklist is not completed.

Admin[edit]

Who is on Chores next time?[edit]

  • 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[edit]

Check if meetings are scheduled for days off in the current week.

  • If so, notify the team so that they can adjust accordingly.

Regressions[edit]

Check if browser tests are failing[edit]

  • 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)[edit]

  • 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)[edit]

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)[edit]

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

Triaging[edit]

Review the Web Dashboard[edit]

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"?
  • Are there tasks that need to be escalated to "Unbreak Now!" status and pulled into the sprint?

Readers Web dashboard.png

Review #mobile[edit]

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 if there are patches from volunteers[edit]

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

Grooming[edit]

Review the Reading Web Backlog[edit]

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?

Performance[edit]

Review grafana dashboards (devs only)[edit]

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

Other[edit]

Check talk pages[edit]

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.

Puppeteer[edit]

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[edit]

  • 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![edit]

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[edit]

  1. Stephen
  2. Sam
  3. Olga
  4. Jan
  5. Jon R
  6. Nick R
  7. Alex
  8. Quiddity

We alternate on Fridays.

Status Update[edit]

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

Links[edit]