Reading/Web/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: 26 February 2024.

Last updated: 26 February 2024.

Meeting Management

European Time workers should not be expected to attend Pacific Time afternoon meetings. All team meetings need to be scheduled between 17:00-19:00 UTC (9am pacific to 11am pacific and 6pm cet to 8pm cet).
Everyone respects time zone differences in scheduling meetings. No one schedules outside of someone’s working hours without checking in first.
The steering committee checks in every quarter to audit each meeting’s frequency and usefulness.

Work Organization

All work involving two or more people within the team should be documented on the board in Phabricator and reflected on a sprint board.
Technical work should function as enabler work, leveling up to the annual plan, either as part of OKR work or as part of essential work. All technical work should be documented in Phabricator as a sub-task of a OKR or essential work epic or user story.
The team has a recurring Phabricator deep clean scheduled at the beginning of each quarter.

Experimentation and Decision Making

New feature experiments–in this instance, projects where the team builds a new feature to test a hypothesis–should be clearly defined in a central document that is easily accessible to all individuals and updated routinely.
Before initiating any work related to an experiment, folks mentally acknowledge, "I am writing code/designing/collecting data for an experiment," ensuring they are cognizant of the experiment's purpose and hypothesis, particularly in relation to its intended impact on users.
The team has a culture of experimentation and is comfortable with imperfection.
Experiments are broken down into smaller components for better understanding and management.
The use of disposable code for experimentation purposes is commonplace.

Communications

Releases

For medium to large releases (often pre-planned config deploys, backports, or central notices), ensure that PM, design, and eng are all aware of exactly what is going out and when. If the change is user-facing, be sure to also engage Comms. Additionally, releases should never happen on a WMF holiday, including country-specific holidays where applicable

Slack threads

The team avoids long Slack threads whenever possible. Before these threads become confusing (which can create unnecessary work for others), folks should hop on a call and record and document the conversation in Google Drive and attach it to any related documentation. As a team we should be mindful of when this is happening and suggest it where appropriate. In addition, we should document the outcomes of longer slack threads and avoid making decisions on Slack.
In our interactions with other teams, we uphold a culture of respect and curiosity. Recognizing that they may possess insights and expertise beyond our own, we approach these interactions with openness and a willingness to learn.

Task Estimation

Drivers of bodies of work will ensure tasks for the next sprint are estimated async in Slack. We will use separate threads for each task in Slack to separate out discussion. Engineers will react with the :eyes: emoji to indicate they have seen the task.
The sprint leader will provide daily updates on the status of the sprint and estimation.

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.^[1]
Document things to which others might need to refer.^[2]
Silence is not consent! It’s often a sign of disengagement. If you want consent, make sure you get consent explicitly.^[3]

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

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

Sprint board aka the Kanbanana

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

Look for:
- #web-team – private channel restricted to team members for updates, questions, occasional personal/fun stuff
- #core-experiences – 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).

Email

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]

Working hours / availability

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.

Wiki

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.^[4]

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)

Please check Release manager responsibilities

Meetings

Weekly

Monday: 50 min sprint planning, go over admin stuff (OOO, chore wheel duty, etc), data needs, tasks in process. Data analyst and MoveComms 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, MoveComms, 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. MoveComms 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. MoveComms is invited.
Purpose: Future planning discussions.

References

↑ When a team is co-located, conversations happen in many places where not everyone is present, such as hallways, cafeterias, watercoolers, etc. When that happens great work can emerge, and it’s satisfying to do! It also may result in a lack of shared understanding about what was discussed, because not everyone who might need to know is present. This dynamic also occurs virtually, in the form of private emails, Slack conversations buried in a channel, private messaging, etc. Use your better judgement about the best tool to inform others: an email (which can be triaged, privately), Slack message (which facilitates faster back-and-forth, privately), or Phab (which is the team’s one-source-of-truth about work state and priorities, in public). Videochat works, too, but it is not persistent (unless you record).
↑ Since we're often juggling communication between multiple teams, and we’re a distributed team, it can be a challenge to ensure that changes and decisions are communicated effectively – particularly when requirements/designs/etc change. Documenting helps other folks who may wind up continuing with the same work, or there may be implications to the changes that are only known to someone else on one of the teams. If it can be public, it probably should be on Phab. This is not only in line with our values, but it also puts at ease those people who want to know how and why decisions were made. Doing it upfront mitigates context-switching to do it later, too. If you have a meeting without everyone present, record the meeting and/or take notes, and then send that to the people who need to see it.
↑ “If you disagree, speak up” is OK as an expectation (i.e. that people will engage), but not for making a decision. “Say whether you agree or disagree” is better.
↑ This can be especially important when communicating with people outside the team (such as volunteers, or colleagues on other teams), as a representative of the team. Even when using a format that isn’t written, such as videochat, take care to express yourself explicitly, and acknowledge the expressions of others. This can mean facial expressions, gestures, etc. Set expectations about the urgency of your requests, especially in email. Examples. If there is ambiguity in someone's tone, or you feel defensive or any sort of discomfort, politely and explicitly share your experience with the person with whom you are speaking. Give your teammates the benefit of doubt, and with the same honesty, humility, respect, and trust that you expect (or desire) from them. We're a tiny, minuscule team that faces big challenges and has the privilege to work together for a long time together. Our work together should often feel quite different than working across teams. The relationships here are much stronger and closer by necessity. Part of our jobs is helping each other get things done. Talking to each other is a big aspect of that.

[1] When a team is co-located, conversations happen in many places where not everyone is present, such as hallways, cafeterias, watercoolers, etc. When that happens great work can emerge, and it’s satisfying to do! It also may result in a lack of shared understanding about what was discussed, because not everyone who might need to know is present. This dynamic also occurs virtually, in the form of private emails, Slack conversations buried in a channel, private messaging, etc. Use your better judgement about the best tool to inform others: an email (which can be triaged, privately), Slack message (which facilitates faster back-and-forth, privately), or Phab (which is the team’s one-source-of-truth about work state and priorities, in public). Videochat works, too, but it is not persistent (unless you record).

[2] Since we're often juggling communication between multiple teams, and we’re a distributed team, it can be a challenge to ensure that changes and decisions are communicated effectively – particularly when requirements/designs/etc change. Documenting helps other folks who may wind up continuing with the same work, or there may be implications to the changes that are only known to someone else on one of the teams. If it can be public, it probably should be on Phab. This is not only in line with our values, but it also puts at ease those people who want to know how and why decisions were made. Doing it upfront mitigates context-switching to do it later, too. If you have a meeting without everyone present, record the meeting and/or take notes, and then send that to the people who need to see it.

[3] “If you disagree, speak up” is OK as an expectation (i.e. that people will engage), but not for making a decision. “Say whether you agree or disagree” is better.

[4] This can be especially important when communicating with people outside the team (such as volunteers, or colleagues on other teams), as a representative of the team. Even when using a format that isn’t written, such as videochat, take care to express yourself explicitly, and acknowledge the expressions of others. This can mean facial expressions, gestures, etc. Set expectations about the urgency of your requests, especially in email. Examples. If there is ambiguity in someone's tone, or you feel defensive or any sort of discomfort, politely and explicitly share your experience with the person with whom you are speaking. Give your teammates the benefit of doubt, and with the same honesty, humility, respect, and trust that you expect (or desire) from them. We're a tiny, minuscule team that faces big challenges and has the privilege to work together for a long time together. Our work together should often feel quite different than working across teams. The relationships here are much stronger and closer by necessity. Part of our jobs is helping each other get things done. Talking to each other is a big aspect of that.

[1]

[2]

[3]

[4]