Readers/Web/Team/Team norms

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

Last updated: 07 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
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.