Readers/Web/Team/Team norms

< Readers‎ | Web‎ | Team
The team is currently refactoring their norms page. Those with access can see progress here.

This page is intended to document norms adopted by the team.

Norms [Drafted 2020-05-27, Updated 2021-01-14]Edit

It is recommended to review these norms quarterly, perhaps as part of Team Time.


Be proactive about informing your teammatesEdit

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 informedEdit

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
      • Review frequency:
        • Daily, at least at the start of your day.
      • Look for:
        • Any tasks on the Kanbanana, plus any tickets to which you are subscribed.
        • In-progress work that can be public.
      • Recommended approach:
        • If a decision was made that affects the above type of tracking, it should be in Phab tasks.
        • 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.
    • Slack
      • Review frequency:
        • Daily, ideally at the start and end of your day, and at least once in between.
      • Look for:
        • Web team channel threads about work being done, as well as private messages and @mentions, or emergencies.
        • Also, dank memes.
      • Recommended approach:
        • If something is on fire, it’s probably obvious. If it’s not, it should be.
        • When you want someone’s attention, DM them or @mention them. They’ll do the same to you, so respond to those when you can.
        • You don’t have to read all the backscroll. Skim the top level threads and see if anyone has been trying to reach you.
        • 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 (at least traditionally), 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.
    • Email
      • Review frequency:
        • At least a couple times a week (commitments and summaries currently go out Mondays and Fridays).
          • Many people check a couple times a day. You’re not expected to respond at the same frequency.
        • Sometimes, if something is urgent, you might also be asked in another channel (e.g. chat) to review by a specific deadline.
      • Look for:
        • Proposals
        • Meeting summaries
        • Action items
        • Recordings
        • Requests/decisions/announcements
        • Dog gifs
      • 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]
            • Who is your audience?
              • E.g. [NOT WORK] or [ALL] or [ANYONE]
            • What is the level of engagement you expect?
              • E.g. [FYI]
            • Are you just documenting something?
              • E.g. [DECISION]
            • Can this be ignored?
              • E.g. [MAX]
    • Wiki
      • Review frequency:
        • As-needed (Product Owner and CommRel should be reviewing this more proactively)
      • Look for:
        • Community feedback, inaccuracies in project pages, etc.
      • Recommended approach:
        • Chore Wheel
        • Responding to PO and CommRel triage.
    • GSuite (Docs, Calendar, etc.)
      • Review this:
        • When requested
      • Look for:
        • Whatever was requested :)
      • Recommended approach:
        • RSVP for calendar invites at least a day in advance of a meeting, if possible.
        • Meetings are a scarce and expensive resource. Use them judiciously.
        • Write down the purpose of a meeting or document (in the event description, top of the document, etc)
        • Remember that Doc and Calendar changes sometimes send email notifications, for better or worse.
        • Try to avoid GChat. It’s redundant. :)
  • The team uses the following tools to collaborate synchronously:
    • Google Meet
      • Your teammates should take care to acknowledge who isn’t present when collaborating synchronously, and leverage meeting recording and note-taking, as possible. Watch those videos and read those notes!
  • If you are working, your teammates expect you to be online and, to simulate co-location, on Slack, specifically.[4]
  • If you are away from Slack for more than a break or food, put up an away status.[5]
  • Know that, when you contact someone, you’re inherently making a request.[6]

Assume others interpret differentlyEdit

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

Norms [OLD]Edit

If it didn't happen on the mailing list, then it never really happened.Edit

  • In other words, all decisions or things of substance must find their way onto the team's public mailing list. Since we're juggling communication between multiple teams, and many folks are remote, it's difficult to ensure that changes and decisions are communicated effectively - particularly when requirements/designs/etc change. It is not enough for these things to be communicated and known between two people, even if they appear to be the only two people working on something, as other folks 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. This is not to say that hallway conversations, IRC, and so on are not acceptable venues for discussions and decisions, it's just that we should capture these things and post them to the list (or the appropriate internal list for administrivia, standup status if missed standup, or internal confidential topics) to ensure everyone stays in the loop.
  • If something has permanence, put it on the appropriate wiki project page, with rationale and links to previous discussion if appropriate, and follow up on email.
  • When a private email is sent to team members, the team members should ask each other if it's something that could go to the public list, the task management system, an internal list, or somewhere else where the communication will be archived for multiple people.


  • Standup happens at the scheduled time, when it’s a hangout or otherwise (like email-standup). It’s OK to email a little early if you are in an affected timezone (like Europe), but the point of standup is to commit to one another and it’s hard to do that when the updates just come whenever.
  • Standup is about coordinating as a team and asking for help, as needed, not just a status update. Keep it focused on the sprint work and what you need to get that work through the flow.
  • If you are an engineer and you miss standup, send an email to the team with your answers to the standup questions and any other news you may have to share.
  • We reserve the right to address repeated tardiness or standup absenteeism.


  • The way we communicate with one another is critical, and has very big impacts on the health of the team. Remember that everyone has their own communication style and ways of thinking about things. As a result, be careful about taking things too personally or reading too deeply into someone's comments.
  • If there is ambiguity in someone's tone, or if it is putting you on the defensive, or making you feel any sort of discomfort, politely and explicitly share that with the person to whom you are speaking.
  • Always approach conversations by giving the other person the benefit of doubt, and with the same honesty, humility, respect, and trust that you expect (or desire) from them.

This is particularly crucial with non-face-to-face communication, as tone becomes even more difficult to decipher.

Rule of 3Edit

The "Rule of 3": If there is a meeting happening that concerns more than one discipline, if decisions are being made, make sure that there is at least one representative from engineering, design, and product.

This helps ensure that three disciplines are represented in any decision making process, and are more likely to stay on the same page.

Working practicesEdit

  • If your laptop is on and you are working, you should be on IRC. This gives all team members, particularly remote ones, the ability to get in touch with you quickly in the event you are needed for something urgent.

Workflow practicesEdit

  • Projects tackled by the team must be documented on a wiki page in the Reading Web Projects page before it can be scheduled.
  • Tasks are stored in the backlog in Phabricator.
    • A task's higher priority assignments follow these guidelines:
      • Unbreak Now (UBN)
        • Something is broken and needs to be fixed immediately, setting anything else aside.
        • For things that need a SWAT.
        • For things that fall into Reading's SWAT policy's concept of criticality, even if it doesn't warrant a SWAT for whatever reason.
        • Deployment blockers.
      • High
        • Most regressions
  • Prioritize working on tasks in the current sprint. If a task is not in the current sprint, the team shouldn't work on it. If the team wants to work on that task, then it needs to be identified publicly and brought into the sprint, an action made visible to the whole team and the PO.
  • Be sure there is nothing you can help unblock (in the sprint) before pulling in new, non-urgent work.
  • Add tests when fixing regressions.
  • When pulling in sprintwork, take prioritized, estimated tasks from Sprint +1 on #reading-web-backlog (if available). Estimate with the team, if necessary. If there are no tasks available that are ready to be worked on, notify the team, preferably at standup.
  • If a card in ready for sign off meets the acceptance criteria but has a problem, it should be moved to done and bugs filed for any issues. If card does NOT meet acceptance criteria, it should be moved back to the appropriate workboard column for re-work. (per Retrospective_2014-01-21)
  • If a card is in ready for sign off and meets the acceptance criteria, it's time to put it on “resolved”. :)

Code reviewEdit

  • We strive to review submitted patches submitted by team members within 2 business days. Fast feedback is very important.
  • If linters on Jenkins jobs don't complain we do not get hung up on code styling. If we feel strongly we will +1 rather than +2 with comments.
  • We strive to only -2 in exceptional cases where discussion seems to have broken down and the involved parties are not being heard.
    • Dog piling and discouraging participation is not okay. Motivation is precious.


  • Reply to meeting invites with Yes/No/Maybe no later than 1 day in advance. This allows for rescheduling and setting expectations.
  • Sometimes when scheduling has to happen well in advance, the value of the meeting is lost, so when making a calendar invite, make an agenda with context from the get go so that it’s clear what the event is for.
  • Wait for retro commenter to be at retro before discussing “their” item. There might be exceptions for urgent things.

Working with othersEdit

  • If we have committed to a task, then we ask that the acceptance criteria are not edited without sign off from the team.
    • If the acceptance criteria of a task are changed, then the task should be moved back to needs analysis to ensure it doesn't derail work.
  • We strive to share our code as libraries (npm/composer packages), upstream code to core when it makes sense, and group functionality in specific Mediawiki extensions to keep our code focused and properly organized, avoiding monolithic software components.
  • We will only start the sprint with tasks that are well defined, with clear design specifications.
  • Teams needing our help should sync with the tech lead two weeks before they need a change, so we can coordinate the work and align on expectations.
  • PO signs off on everything, and indicates in ticket comments (@mentions) if they want someone else to sign off. Either the PO drives or directs traffic, but everyone has the same expectation for signoff.

Conflicts on technical discussionsEdit

  • Be aware of deadlock and stop to cool off and re-discuss later
  • Include tech lead on technical discussions that don't reach agreement
    • Tech lead to state rules of good design and specify trade-offs to help move the discussions forward
  • Ask for help from TPG to facilitate when conflicts come to a halt
  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 gives all team members, particularly remote ones, the ability to get in touch with you quickly in the event you are needed for something urgent.
  5. Your teammates still want you around and available, but if it isn’t possible for your teammates to expect your presence, set new expectations.
  6. The clearer your communications, the easier it is for others to participate. Pascal (and others) famously wrote "The present letter is a very long one, simply because I had no leisure to make it shorter." Our communications don't have to be perfect but they shouldn't be sloppy; communication is an art but an effortful one for readers and writers alike. Let's all strive to be great artists. Silence is not consent! It’s often a sign of disengagement. If you consent to something, make sure you give consent explicitly, especially when asked.
  7. 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.