The Mozilla Webcompat team has always been an internationally distributed team from the start (7+ years). I have been working this way for the last 20 years with episodes of in-office life.

Priorities Of Scope

When sending messages to talk about something, always choose the most open forum first.

Why?

It's always easier to restrict a part of a message to a more private discussion. Once a discussion starts in private, making its content available to a larger sphere extends the intimacy, privacy, secrecy. It becomes increasingly harder to know if we can share it more broadly.

Everything you say, write, think might be interesting for someone out there in another Mozilla team, someone in Mozilla contributors community, someone out there in the world. I can't count the number of times I have been happy to learn through people discussing in the open, sharing what they do internally. It's inspiring. It extends your community. It solidifies the existence of your organization.

When the scope is broad, the information becomes more resilient. More people know the information. You probably had to use a publishing system involving the persistence of the information.

Information Broadly Accessible

Give it a URI, so it exists! or in the famous words of Descartes: "URI, ergo sum".

Why?

URI is this thing which starts with http or https that you are currently using to read this content. Once you gave a URI to a piece of content, you access to plenty of features:

1. You can share through different medium (messages, mails, etc.)
2. You make the information easily searchable
3. You make the information more resilient with regards to time. Imagine someone joining your team later on. Or you have left and your email account which was cointaining all the interesting information is gone.

You may want to create a URI persistence policy at the organization level.

Messages How?

Context is everything!

This applies to basically all messaging style (chat, email, etc.)

Why?

If you send a message addressing someone, think about this:

1. Who? Use the person handle in a shared chat.
2. What? The topic you would like to discuss with enough context to make it possible for the person to answer. Share URIs to online documents.
3. When? If there is a deadline, give it. It's a lot easier to reply at the appropriate time and remove the stress on both ends of the message.

note: I have written, a long time ago, a special guide for working with emails in French and it has been translated in English

Mozilla is a distributed community with a lot of different cultures (social, country, education, beliefs) and across all timezones. At Flickr, Heather Champ had a good reminder for the community: "Don't be a creep."

You may (will probably) do terrible blunders with regards to someone else. Address them right away when the person is making a comment about them. And if necessary, apologize in the same context, you made the mistake. When you are on the receiving part of the offensive message, address them with the person who made them right away in private. Seek for clarification and explain how it can have been hurtful. If it repeats, bring it up to the hierarchy ladder and/or follow the community guidelines.

Chat (Matrix, IRC, Slack, …)

1. Prefer Public or Team channels over one to one messages.
2. Choose Matrix over Slack.
3. Reply in threads.

Why?

When sending messages to share things about your work at Mozilla, use matrix over slack. It will be more accessible to the community and it will allow more participation.

That said be mindful. These systems do not have built-in web archives. That's a strength and a weakness. The strength part is that it allows a more casual tone on discussing stuff without realizing that you are saying today could become embarassing in 10 years. The weakness part is that there is valuable work discussions going on sometimes in chat. So if you think a discussion on chat was important enough that it deserves a permanent record, publish it in a more permanent and open space. (Exactly this blog post which started by a discussion on slack about someone inquiring about Team communications at Mozilla.)

Reading Emails

Read Only Emails Sent To You.

Why?

Ah emails… the most loved hating subject. I understand that mail clients can be infuriating, but mails are really an easy task. Probably the issue with emails is not that much the emails themselves, but the way we treat them. Again see my guide for working with emails.

I end up all my working days with all messages marked as read. I don't understand what INBOX 0 means. So here my recipes:

1. Deactivate mail notifications from all services except if you intent to keep these notifications as archived helping you to work with (example: github issue messages are my offline database that I can search.)
2. Put all my mail for a month in a monthly folder. This month all my mails are going to /2021/03 mailbox.
3. Create virtual/smart mailboxes for each context where you need to access the emails. The benefit? The same email is then accessible from different contexts. Quick Tip to make the mailbox more performant, limit it to the last 6 weeks. smart mailboxes are easy to create, easy to destroy with changing contexts. Currently in Mail.app, I have around 50 to 100 smart mailboxes.
4. Create a virtual mailbox which catches the messages where you are in To: or Cc:. This is your real inbox. You will discover that you do not receive that many emails in fact. This is the thing you should reply to. Mark as read everything else.
5. Do not read the emails which are not directly addressed to you. This is difficult to understand for many people. But that's the good way of handling the volume. Think about your email as an archive of content which is searchable and the smart mailboxes as filter on what you might be interested in.
6. Use an online archived mailing-list. Do not send emails to a group of people with giant list of Cc:. This is bad. It encourages top replies to keep context. There is always someone missing who needs to be added later. It doesn't resist time at all. Information belongs to the organization/context you are working on, not the people. You will be leaving one day the organization. New people will join. The information needs to be accessible.

With these, you will greatly reduce your burden. And one last thing, probably which is conter-intuitive. For work, do not use emails on your mobile phone. Mail clients on mobile are not practical. Typing on a virtual keyboard on a small screen for emails is useless. Mails require space.

Meetings Organizations

Meetings are for discussions

Why?

If it's about information sharing, there are many ways of doing it in a better way. Publish a blog post, write it on a wiki, send it to the mailing-list of the context of your information. But do not create a meeting to just have one person talking all the time. Meetings are here for the interactions and picking ideas.

Here some recommendations for good meetings:

1. Have a regular non mandatory meeting time. What does it mean? The time is blocked, but if there is no agenda, there is no meeting.
2. Have a published agenda at a regular URI where people can contribute to the agenda. On the Webcompat team, everyone can add an agenda item to our public agenda, even contributors. Try to have the agenda, at least 24h before the time of the meeting.
3. Have a scribe and a chair. The chair is the person who will be charge of animating the discussion during the meeting. The scribe will be the person taking notes of what is being said. The minutes are being taken live on the system and everyone can see what is being taken, hence can fix them. We rotate scribes and chairs at every meeting.
4. Publish the meeting minutes online. This is important. it gives a regular URL that you can refer to in the future, that you can revisit or share with someone else in a different context. Webcompat has an archive of all minuted meetings on Mozilla wiki. Example: Minutes of March 2, 2021
5. Break out big groups. When there is a meeting with a lot of people in one room and a couple of people online, the meeting is unbalanced and the body language (we social beings) take over and people online may become excluded. Separate the big local group in smaller groups or really as individuals so that everyone is like a remote person.
6. Allow for people to participate once the meeting has finished. There are bug trackers, minutes, mailing-lists, etc. Give a deadline for commenting.

Meeting Times

In a distributed team, the shape of Earth comes to crash into the fixed time reality of a meeting. You will not be able to satisfy everyone, but there are things to avoid the usual grumpiness, frustrations.

1. If you organize a meeting from the US West Coast time, Fridays are forbidden. It's already Saturday in Asia-Pacific
2. If you organize a meeting from Asia-Pacific time, Mondays are forbidden. The US West Coast is still on Sunday.
3. Create a doodle to understand the distribution of time of people who can participate. Some people do not necessary work along the 9 to 5 schedule, some like to participate at night, some prefer very early meetings
4. If you can't fit everyone in one meeting because of time zones. Create two meetings or rotate the burden of meeting time.
5. Minutes the meeting, this will become handy for people who can't attend.

Wiki, Google Documents, Blog Post

Publish Online with a wide accessible scope if possible.

Why?

First rule at the start. If you create a Google docs, do not forget to set the viewing and sharing rights for the document. Think long term. For example, the wiki at Mozilla has been here for a longer time than Google Docs. Mozilla controls the URI space of the wiki, but not so much the one of Google Docs.

Having an URI for your information is key as said above.

Comments

If you have more questions, things I may have missed, different take on them. Feel free to comment…. Be mindful.

Otsukare!

https://www.otsukare.info/2021/03/16/working-tips-remote-team