Abstract Wikipedia team/Communication principles

This document is a set of commitments which we, the Abstract Wikipedia team, will uphold in our communication with each other. The commitments are structured around the four team trust statements which the team has collectively written and agreed on:

It is important for me that colleagues in my team:

• are honest and do not lie
• behave in a fair and reasonable way towards me
• feel comfortable and safe raising their ideas, concerns, and fears
• empathise with themselves, each other, and the people for whom we are building

The team's practices

We are a fully distributed team, spread out around the world. These are the different ways we interact with each other as part of our work:

• We interact in online meetings
• We work alone
• We use channels of asynchronous communication
• We work together, e.g. pair programming
• We review other people’s work, e.g. code review
• We communicate externally
  • with other teams at the Foundation
  • with communities
  • with the media
  • …
• We make decisions

In the commitments below, we will call attention to how our team values apply specifically to each of these seven work modalities.

Glossary

Applying the team's values to these seven work modalities revealed some common behavioural principles that can guide how we communicate with each other and work together. In the commitments below, we will refer frequently to these principles, so they are listed and defined here.

Don't shut others down

If we want to maintain psychological safety and effective communication, we must build a culture that makes those things easy to uphold. This means that we make as few assumptions as possible, and we do not shame others. Instead of assuming that our colleagues have certain knowledge/competency/context, we can acknowledge that they may not and help to provide these things as needed.

• build a culture that encourages good behaviour
• context - provide the necessary context; acknowledge people might not have it
• no shaming - no assuming knowledge/competency

It's okay not to know

Following from the above, we prefer to approach each other with vulnerability and curiosity. We acknowledge our own weaknesses. When in doubt, we prefer to ask questions rather than making assumptions or issuing demands.

• questions are better than demands, orders, assumptions
• change is good
• cooperation vs competition; our goals are shared (also, is this true?)
• be vulnerable; acknowledge your own weaknesses

We’re all human

We lead with empathy. We try our best, assume others are doing the same, and we give and receive feedback graciously in order to improve. We recognise that our words and delivery can affect others, so we consider others' feelings and time constraints as we decide how to communicate.

• empathy first
• assume best intent
• active requests for feedback/receipt
• feedback
• effective communication – respect for people’s time; to communicate as soon as possible
• messages can hurt/affect others; people have feelings

We’re all different

We recognise that we differ in many ways, including native language, culture, and time zone. We do not invoke "common sense". We strive to learn and respect our colleagues' communication preferences/coping mechanisms, and to signal our own.

• communication preferences/coping mechanisms of each other; do we infer these or do we explicitly ask for them?
• objectivity is a tyrant
• common sense is neither objective, nor universal
• work life balance; everyone has a life, and while you are working, your colleagues might be living

The team's values

It is important for me that colleagues in my team are honest and do not lie

We will nourish a team culture that makes honesty easy. We will not shame others, even and especially when they admit a mistake. We will lead with empathy to help ourselves recognise when a colleague has had to be vulnerable, and we will take all feasible measures to minimise their resulting distress.

We will try not to withhold information from our colleagues. We will provide as much information as we can, and as early as is feasible, so that we can effectively understand the full picture.

We are distant in time and space and we all lead different lives; that’s why our most common channel of communication is asynchronous and in written form. When we communicate asynchronously we understand that we are not communicating within a common context, and we need to work harder to provide that context within the message itself. Crafting the sufficient context to transmit a message is hard work, but it allows us to respect each others’ time and mental space.

Some communication channels allow for editing; for example, Slack. Editing a message can help you fix typos, links, or faulty information, but it can be misleading if the message has been already read and replied to. When editing a slack message, we understand which edits are harmless and which ones could alter the message, so we will add explicit context for our edits when we believe it could be misleading.

While asynchronously reviewing other people’s work we will communicate clearly but not brutally. We will distinguish in expression what we prefer from what we consider "objective facts." If we believe we are communicating facts, we will do so unpretentiously and with the goal of educating, not browbeating. We will provide references whenever possible.

When we have a chance to synchronously work together, we will do it from the acknowledgement that we are not perfect and from the desire to grow together, learn new things and share our knowledge. That’s why we are open to acknowledging our weaknesses, we communicate openly when we don’t know something and we openly and directly request help.

It is important for me that colleagues in my team behave in a fair and reasonable way towards me

We will treat each other with openness and compassion. We will not make assumptions about a person's knowledge or abilities (e.g. "I can't believe you don't know/can't do …"). We will not call each other out. We will express ourselves in the way that feels most comfortable and natural to us (provided that we are not infringing on the safety of others).

We will extend our generosity and compassion to those who are speaking in a language other than their mother tongue; especially during meetings and other spaces for synchronous communication. We will try to minimise the use of jargon or cultural references that people might not know, or provide context when they come up. We are responsible for building a space where everyone feels  comfortable to ask and provide for inter-cultural clarifications.

Because our communication is primarily asynchronous, we are sometimes overloaded with messages. We have different schedules, responsibilities and availability, so we acknowledge that not everyone goes through messages at the same time or the same speed. We won’t assume that the information is known by everyone. Instead, we will ask if people are aware, provide links and context, and generously repeat our messages if necessary. We understand that people need response and feedback; nobody likes talking alone! For that reason we will give feedback as soon as possible. Feedback can be a direct response or just a sign that the message has been received (like an emoji).

While reviewing other people’s work, we will raise issues as gently as possible.

Especially during code review, we will focus on functionality and maintainability first, as these issues impact the code base holistically; we will address readability and style secondarily. We will not cling to our way of doing things, and will accept that there are diverse ways to solve a problem, none of them uniquely "correct." When we are the one writing code, we will recognise the limitations of the medium and endeavour not to interpret conciseness as meanness. On the other hand, where a review culture is abusive or unempathetic, we will not adapt to it but resist it and maintain our own standards. We will keep patches small and easily digestible wherever possible. We will perform our own review first in order to catch simple mistakes and reduce our reviewers' workload.

In either case, we will not prize our egos. We will recognise that work is a collective activity; that code is a tool, not a masterpiece, and we will let the small stuff go.

When we work synchronously on something together, we will make sure that everyone understands what we are doing: a session must have a clear definition and a clear goal so that everyone can follow and offer or receive suggestions.

When we work on code together, authorship will only fall on one (the writer); but pair programming is a shared effort and it needs acknowledgement and recognition. That’s why we treat our colleagues with kindness, we share our collective progress and we are grateful for the help.

When working alone we will leave shared resources in as good a condition as we found them in, if not better. We will follow best practices for the work we are doing. We will ensure that shared documents are well-organised and readable, that resources are discoverable, and that code is healthy (readable, maintainable, well-tested, etc.). We will endeavour to document our processes and products, and dedicate time to that maintenance.

For situations not otherwise addressed, our own "common sense" will supply a first approximation of what's reasonable, but we will recognise the limitations of our own understanding. We will acknowledge that fairness is continuously negotiated, and is subject to cultural norms and personal needs. As we learn more about our colleagues, we will be mindful of their specific communicative preferences and clearly communicate our own preferences.

It is important for me that colleagues in my team feel comfortable raising ideas, concerns, and fears they might have about the team’s work and impacts on it [without repercussions]

We don’t own knowledge: we create it together. With this in mind, we will build a culture that promotes safe conflict and does not punish authentic expression.

We will not shame people for changing their opinion. In discussion and conflict, our goal is not to "win" but to create collectively. We will recognise that people learn and views change. We will embrace this kind of growth and will not dismiss it as a "contradiction."

When conflict arises, we will express our ideas/concerns/fears openly and listen intently when others do the same. When the team must choose between a psychologically safe decision and an efficient one, we will prioritise psychological safety. We will recognise that we are working toward a common goal even if we disagree about the details. We will criticise ideas but not people, and when we criticise, we will do so constructively.

Sometimes we are wrong; something we are ill-informed; something we have incomplete information. Communicating asynchronously means that we are creating a persisted record of what we say. This might be intimidating, but for the sake of our collective growth, we will feel comfortable sharing our ideas and being open to them being wrong or incomplete.

When we assess each other's work, we will be humble; we will be unassuming, and we will not shut down discussion. We will ask questions rather than making demands. We will treat code review and other assessment venues as a discussion and negotiation, not a platform for the exercise of authority. We will especially make space for colleagues whose voices are in danger of going unheard to express their views.

When we pair-program or otherwise work together asynchronously, we do so to learn from each other; we understand that our knowledge is incomplete. Therefore, we will not shame our colleagues’ knowledge gaps or make assumptions about what things should be known. We avoid using expressions that are judgemental or can make other people feel inadequate.

It is important to me that colleagues on my team empathise with themselves, each other, and the people we are creating stuff for

We will always look for the human.

We ourselves, our teammates, and the communities who interact with our products are all intelligent, active participants. We will put empathy first in all our dealings. We will actively combat discourse or behaviour that fails to demonstrate empathy for any person or group.

When interacting in meetings, asynchronous discussion, code review, or group work, we will act in good faith and assume good faith on others' parts. We will ask questions rather than making demands or accusations. We will be curious instead of defensive.

When we are working together synchronously, we will be conscious of differences in power, confidence, and experience level. We will understand and share each other’s comfort and energy level, and keep an eye on engagement. When we lead, we are also responsible for making sure that everyone is following us. When we join a work session as an observer, it is our responsibility to keep up and make ourselves present, by suggesting and helping, or by making sure we ask questions and use the session for our benefit.

Pair programming in particular can be hard at first, because we are exposed to everyone’s observations and may feel vulnerable or judged. This activity can be extremely helpful for everyone involved, both writer and the observer(s), but it can also be one-voiced, confusing and overwhelming when participants have very uneven skill levels. Therefore, we will not shame each other. It is all of our responsibility to create a comfortable environment where trial and error, failure, and not knowing are expected and embraced.

When we are engaging in code review or otherwise assessing others' work, we will constructively criticise the work itself; we will not attack the person behind it.

But we will not only criticise. We will also express encouragement and gratitude. We might imagine our colleague physically in front of us, accomplishing some good work or doing us some favour: that is the spirit in which we will offer both praise and criticism.

We will recognise that doing our work and receiving feedback on it are both energetically taxing activities. We will not overwhelm the recipients of our review with excessive comments, but give them manageable amounts of feedback.

Code review in particular is a conventionally blunt, negative medium. We will endeavour to avoid this. We will hold our code review process to the same standards of empathy as all our communicative practices.

We will tend to our own well-being. We will endeavour to gain clarity around our needs and how best we can set boundaries.

And when we struggle to show empathy, we will be forgiving to ourselves and to others. We will correct each other gently and with compassion.