Readers/Web/Team/Team norms

This page is intended to document norms adopted by the team. It is recommended to review these norms quarterly. Last reviewed as a team: 13 October 2022.

Last updated: 26 June 2023.

Be proactive about informing your teammates
If you have a conversation that affects or relies on others who weren’t present, don’t assume they will be informed on their own.
 * If you have a conversation about something, and not everyone who needs to know about that conversation was present, go tell them.
 * Document things to which others might need to refer.
 * Silence is not consent! It’s often a sign of disengagement. If you want consent, make sure you get consent explicitly.

Be proactive about staying informed
Your teammates are doing great work, and it can be expensive to do everything with everyone all the time, so take it upon yourself to see what’s happening.

The team uses the following tools to collaborate as a (mostly) asynchronous team:

Phabricator Sprint board aka the Kanbanana
 * Look for:
 * Any tasks on the sprint board, plus any tickets to which you are subscribed.
 * In-progress work that can be public.
 * Recommended approach:
 * The task description should always be the source of truth.
 * Update as needed.
 * Use comments to ping people, note that the description is updated with important changes.
 * When you contact people on Phabricator, it’s public! This is in line with our values, but also requires care, because you’re inherently showing your communications to more than the people to whom the message might be aimed.
 * Also see Reading/Web/Phabricator


 * Look for:
 * Columns that are red. This indicates that there are too many tasks in that column.
 * Tasks to the right of Doing that have not had an update in 3 days. The team should investigate why these are not moving.


 * Recommended approach:
 * Call out any questions or concerns during meeting board checks.

Slack Email Working hours / availability Wiki
 * Look for:
 * – private channel restricted to team members for updates, questions, occasional personal/fun stuff
 * – public channel shared with other Core Experiences teams for knowledge sharing, questions, requests
 * Recommended approach:
 * If something is on fire, make it obvious.
 * Share info with the team rather than DMing or setting up side conversations. To help reduce noice, identify who needs to pay attention to a message (everyone else is optional).
 * Slack is instant messaging, and one of the better ways to simulate togetherness. You’re not expected to be on here all the time (it can also be distracting, plus we all work different hours), but do your best.
 * When you Slack/chat someone, urgency is implied, because it is semi-synchronous and can’t be triaged the same way as email or Phabricator. It may also mean that your chat is lost, if someone is not readily available, and a slower but more sustainable approach (like email or Phab) might be prudent. Keep these things in mind when deciding if chat is the best way to ask someone to connect.
 * If a decision is made on Slack, it should be documented elsewhere (probably Phab).
 * Look for:
 * Proposals
 * Meeting summaries
 * Action items
 * Recordings
 * Requests/decisions/announcements
 * Recommended approach:
 * Email is essentially advanced triage, so set expectations!
 * When you email someone, there is an expectation that they will read it. What might not be clear is how quickly you might want a response, so you can help your teammates by saying what you expect and when you expect it. Subject line [TAGS] are useful. Tags make it easier to triage and limit context-switching, and also leverage automated filters.
 * How quickly do you need a response? e.g. [URGENT] or [NOT URGENT]
 * What are you asking? e.g. [ACTION REQUESTED] or [ACT]
 * Recommended approach:
 * Set your working hours on your personal calendar
 * If needed, put blocks for times when you are unavailable, e.g. focus time, childcare
 * Notify the team if you won't be available when you usually are
 * e.g. “I will be out for an appointment this afternoon, I’m working on X ticket” or “I can’t make it to standup, here’s my update”
 * Time off
 * Time off is usually requested 2 weeks in advance; notify the team when you make your request
 * Put it on your personal calendar. Using the "out of office" function is helpful as it auto-declines calendar invites.
 * If it's a full day or more, put it on the team calendar. (But for privacy reasons, please do not copy over personal events, as everyone on the team can see the event details.)
 * Put it in the planning meeting notes. This is our source of truth for who's out.
 * Look for:
 * Community feedback, inaccuracies in project pages, etc.
 * Recommended approach:
 * Chore Wheel

Assume others interpret differently
Say what you mean, and mean what you say.


 * Remote communication relies heavily on writing, and because of that being explicit about your tone is important. In person, and to some degree on video, these are things we take for granted.

Weekly release manager
Every Monday we will assign someone as "release manager". This person will be responsible for the existing chores page for the entire week as well as making sure our releases go smoothly.

We are going by alphabetical order (first name) with the only exception being where a person is out for all or some of the week - in which situation it will skip that person.

We hope this will give better accountability and predictability of who to contact when issues arise.

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)

Release manager responsibilities:


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


 * 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
 * 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!

Weekly
Monday: 50 min sprint planning, go over admin stuff (OOO, chore wheel duty, etc), data needs, tasks in process. Data analyst and CRS are required.
 * Purpose: Set up a plan for the week. Kick off or check in on current sprint.
 * Details: Have a pre-populated agenda in a doc, use this to record decisions and make sure support folks are informed. Also check on board status.

Tuesday: 30 min task sync, board check for blockers.


 * Purpose: Go over what everyone is working on and call out any blockers.
 * Details: Determine when tasks will be done and if they are blocked, what can be done to un-block. Also identify any deep-dive issues and break out into individual meetings as needed.

Wednesday: 50 min super-happy-dev-time (SHDT), engineering sync.
 * Purpose: In-depth discussion time for engineers.
 * Details: Engineers use this time to sync. There is an agenda defined by the engineers and topics vary and are as needed. Traditionally the time is used to sync on difficult sprint tasks, to talk about architecture for upcoming work, work on action items from retrospectives or requests from other teams, share work (sometimes external teams attend to share out). The meeting is mostly for Web team engineers but often attended by Web team alumni.

Thursday: 30 min task sync, board check for blockers.


 * Purpose: Go over what everyone is working on and call out any blockers.
 * Details: Determine when tasks will be done and if they are blocked, what can be done to un-block. Also identify any deep-dive issues and break out into individual meetings as needed.

Thursday: 60 min estimation and backlog grooming.


 * Purpose: Evaluate and discuss tasks for the upcoming sprint, triage and discuss incoming tasks, maintain the backlog.
 * Details: Use the Fibonacci sequence for points
 * 1 = 0.5 days
 * 2 = 1 day
 * 3 = 1.5 - 2 days
 * 5 = 2 - 3 days
 * 8 = 5 days
 * 13 = 1+ week

Every two weeks
Tuesday: 30 min social time, optional time for non-work-related conversation.


 * Purpose: Hang out with each other and have some fun.

Tuesday (alternating week from social time): 45 min product planning, PM, tech lead, designer, CRS, EM discuss high level/long term product plans that impact team roadmap.
 * Purpose: Stay ahead of present work and create phab tasks as needed.

Wednesday: 60 min retrospective, time for everyone to reflect together on team health, processes, workload, etc. CRS is optional.
 * Purpose: Celebrate wins, raise concerns, iterate on how we do things.

Wednesday (alternating week from retro): 45 min strategy time, longer-term / higher-level planning. CRS is invited.


 * Purpose: Future planning discussions.