We're a distributed, remote-only company where people work remotely without missing out. For this, we use asynchronous communication and are as open as we can be by communicating through public issues, chat channels, and placing an emphasis on ensuring that conclusions of offline conversations are written down. These communication guidelines are meant to facilitate smooth communication in an ever-growing remote-only company. Please keep in mind that you represent GitLab and our culture, also on Social Media. When commenting on posts please keep in mind: "Don't argue but represent."
Internal Communication
All written communication happens in English, even when sent one on one, because sometimes you need to forward an email or chat.
Use asynchronous communication when possible (issues and email instead of chat), issues are preferred over email, email is preferred over chat, announcements happen on the team call agenda, and people should be able to do their work without getting interrupted by chat. To use email instead of chat it is OK to send internal email that contain only a short message, similar as you would use it in chat. Save time by not including a salutation like 'Hi Emma,' and first write the subject the email which you copy paste into the body. You are not expected to be available all the time, it is perfectly fine to wait with responding to emails and chat mentions until your planned work hours.
Sometimes synchronous communication is the better option, but do not default to it. See the guidelines on video chats for more detail.
It is very OK to ask as many questions as you have, but ask them so many people can answer them and many people see the answer (so use issues or public chat channels instead of private messages or one-on-one emails) and make sure you try to document the answers.
If you mention something (a merge request, issue, commit, webpage, comment, etc.) please include a link to it.
All company data should be shareable by default. Don't use a local text file but leave comments on an issue.
Email
When using email, send one email per subject as multiple items in one email will cause delays (have to respond to everything) or misses (forgot one of the items).
Always reply to emails, even when no action is needed. This lets the other person know that you received it. A thread is done when there is a single word reply, such as OK, thanks, or done.
If you forward an email without other comments please add FYI (for your information) or FYA (for your action). If you forward an external request with FYA it doesn't mean that the company should do whatever is proposed, it just means the person who forwarded it will not follow up on the request themselves and expects you to do so instead.
Email forwarding rules are specified in the shared GitLab Email Forwarding Google Doc accessible only to people in the company. If you want to be added or removed from an internal alias (for example, "sales@gitlab.com"), change a rule, or add a forwarding email alias, please suggest an edit in the doc.
Emails are asynchronous, for example, if your manager emails you on a weekend it is fine to reply during the workweek.
If an email is or has become urgent feel free to ping people via chat referencing the subject of the email.
Chat
If you use chat please use a public channel whenever possible, mention the person you want to reach if it is urgent. This ensures it is easy for other people to chime in, and easy to involve other people, if needed.
In chat try to keep the use of keywords that mention the whole channel to a minimum. They should only be used for pings that are both urgent and important, not just important. By overusing channel mentions you make it harder to respond to personal mentions in a timely manner since people get pinged too frequently. If something is urgent and important:
Use @here to notify all currently active members in the room.
Use @channel to notify ALL members in the room, irrespective of away status.
If you agree in a chat to start a video call (typically by asking "Call?") the person that didn't leave the last comment starts the call. So either respond to the "Call?" request with a video link or say "Yes" and let the other person start it. Don't say "Yes" and start a call 5 seconds later since it is likely you'll both be creating a video call link at the same time.
The usage of ChatBots for integrations can sometimes depend upon the name of the chat room, you should consult the room about such integrations before changing the name of commonly used / popular rooms in order to avoid inadvertently breaking integrations.
Google Docs
Never use a Google Doc / Presentations for something non-confidential that has to end up on the website or the handbook. Work on these edits via commits to a merge request. Then link to the merge request or diff to present the change to people. This prevents a duplication of effort and/or an out of date handbook.
If you do need a Google Doc, create one with your company G Suite (formerly Google Apps) account. By default, share it with the whole company using the Anyone at GitLab can find and access link sharing permission and the Anyone within GitLab can edit access permission (preferred) or the Anyone within GitLab can comment access permission. Easily do this by creating Google Docs within a Shared Folder in Google Drive.
When referring to a Google Doc in the handbook, refrain from directly linking it. Instead, indicate the name of the doc. (In the past, linking a Google Doc has led to inadvertently opening the sharing settings beyond what was intended.) This also helps prevent spam from people outside GitLab requesting accessing to a doc when clicking its link.
If you are having trouble finding a shared Google Doc, make sure you Search <your domain> in Google Drive.
In our handbook, if you find yourself wondering whether it is better to provide a public link to a Google Doc vs. writing out the content on the website, use the following guideline: Is this document frequently adapted / customized? If yes, then provide a link, making sure that the document can be commented on by anyone with the link. For instance, this is how we share our employment contracts. If the document is rarely customized, then provide the content directly on the site and deprecate the Google Doc.
Video Chats
Use video calls if you find yourself going back and forth in an issue/via email or over chat. Rule of thumb: if you have gone back and forth 3 times, it's time for a video call.
Having pets, children, significant others, friends, and family visible during video chats is encouraged. If they are human, ask them to wave at your remote team member to say "Hi".
Say Thanks
Thank people that did a great job in our "Thanks" chat channel. If someone is a team member just @ mention them. If multiple people were working on something try mentioning each person by "@name". "Thanks everyone" does not say much.
To thank someone who is not a team member, mention your manager, our People Ops Coordinator, the name of the person, a quirky gift and link to their work. For example, "@manager, @peopleopscoordinator: Joe deserves a lawnmower for link". With your manager's blessing, the People Ops Coordinator will approach the person in question for their address saying we want to send some swag. We'll ship it in gift wrap with "Thanks for your great work on link, love from @gitlab".
Don't thank the CEO or other executives for something that the company paid for, thank GitLab instead.
Not sure where to go?
If there is something that you want to discuss, but you do not feel that it is a reasonable option to discuss with either your manager or CEO, then you can reach out to any of the other C-level GitLabbers or our board member Bruce Armstrong.
GitLab Workflow
Everything starts with an issue
Always create an issue for things you work on. If it is worth spending time on, it is worth creating an issue for it since that enables other people to learn and help. You can always edit the description or close it when the problem is something different or disappears.
If a user suggests an enhancement, try and find an existing issue that addresses their concern, or create a new one. Ask if they'd like to elaborate on their idea in one of these issues.
Double link issues to prevent internal confusion and us failing to report back to the reporters. For example, open an issue with a link to ZenDesk and close the issue with a copy of the response. Or add "Report: " lines to the description with links to relevant issues and feature requests and ensure they are closed and note this with a comment. If you are not responsible for reporting back please do not close an issue, instead re-assign it.
If two issues are related, crosslink them (a link from each issue to the other one). Put the link at the top of each issue's description with a short mention of the relationship (Report, etc.). If there are more than 2 issues, use one issue as the central one and crosslink all issues to this one. Please, also crosslink between ZenDesk and GitLab issues.
After a discussion about a feature update the issue body with the consensus or final conclusions. This makes it much easier to see the current state of an issue for everyone involved in the implementation and prevents confusion and discussion later on.
Submit the smallest item of work that makes sense. When creating an issue describe the smallest fix possible, put suggestions for enhancements in separate issues and link them. If you're new to GitLab and are writing documentation or instructions, submit your first merge request for at most 20 lines.
Do not leave issues open for a long time, issues should be actionable and realistic. If you are assigned to an issue but don't have time to work on it, assign it to someone else.
Make a conscious effort to prioritize your work. The priority of items depends on multiple factors: Is there a team member waiting for the answer? What is the impact if you delay it? How many people does it affect, etc.? This is detailed in Engineering Workflow.
Use the public issue trackers on GitLab.com for everything since we work out in the open. Issue trackers that can be found on the relevant page in the handbook and in the projects under the gitlab-com group.
We try not to assign issues to people but to have people pick issues in a milestone themselves.
Assign an issue to yourself as soon as you start to work on it, but not before that time. If you complete part of an issue and need someone else to take the next step, re-assign the issue to that person.
When re-assigning an issue, make sure that the issue body contains the latest information. The issue body should be the single source of truth.
When working on an issue, ask for feedback from your peers. For example, if you're a designer and you propose a design, ping a fellow designer to review your work. If they approve, you can move it to the next step. If they suggest changes, you get the opportunity to improve your design. This promotes collaboration and advances everyone's skills.
We keep our promises and do not make external promises without internal agreement.
When closing an issue leave a comment explaining why you are closing the issue.
Implement it with a merge request
Merge request guidelines for all contributors are described in our Contribution guide.
Code review guidelines for reviewers and maintainers are described in our Code Review Guidelines.
Following are additional guidelines for GitLab Inc. team members:
Even when something is not done, share it internally so people can comment early and prevent rework. Create a Work In Progress a merge request so it is not merged by accident.
If any followup actions are required on the issue after the merge request is merged (like reporting back to any customers or writing documentation), avoid auto closing it.
When you are done with your merge request, remove the "WIP" prefix and follow the Code Review Guidelines.
You can still make changes based on feedback of course, but by removing the "WIP" prefix it clarifies that the main body of work has been completed.
Team Call
Schedule
PST:
UTC:
:
APAC schedule
PST:
UTC:
:
Everyone at GitLab is invited to the team call.
We also have a team call for GitLabbers in the APAC region to share their weekend update. This call will also be recorded so the rest of the team can see what their colleagues have been up to! Everyone is encouraged to join this call as well, but it is not mandatory.
Every last Friday of the month we have an AMA to talk about anything our team is thinking about.
We use Zoom for the call since Google Hangouts is capped at 15 people (please be sure to mute your microphone). The link is in the calendar invite and also listed at the top of the team agenda Google Doc called Team Agenda.
The call is recorded automatically, and all calls are transferred every hour to a Google Drive folder called "GitLab Videos". There is a subfolder called "GitLab Team Call", which is accessible to all users with a GitLab.com e-mail account.
We start on time and will not wait for people.
The person who has the first item on the agenda starts the call.
If you are unable to attend just add your name to the team agenda as "Not attending".
We start by discussing the subjects that are on the agenda for today.
Everyone is free to add subjects. Please start with your name and be sure to link to an issue, merge request or commit if it is relevant.
When done with a point mention the subject of the next item and hand over to the next person.
When someone passes the call to you, no need to say, “Can you hear me?” Just begin talking. If we can’t hear you, we’ll let you know.
New team members should connect to their first team call 10 minutes before the call starts to make sure Zoom, your camera, and your microphone are all working properly. The new team member's manager will introduce them and ask the following questions: "Tell us about where you were before GitLab, why you wanted to join our team, and what you like to do in your spare time."
We ask 15-20 people per day to share updates about the most exciting thing from your past or upcoming week/weekend. If anyone has something they'd like to talk about, last person in the list will ask the group if they have anything else to share.
The team agenda lists who is meant to speak on which day; this can be altered daily if conflicts arise.
There is no need to excuse yourself with "I didn't do anything interesting", "I just watched television" or "That's all". It is not a competition. Instead share the most interesting detail, for example what television show you watched, book you are reading, video game you played or what recipe you cooked.
The sequence of asking people is in a random order where each team member is assigned a day. Since we are growing rapidly, GitLabbers share their weekend update every two weeks. Days are split into group A and group B, which alternates depending on the week. People Ops will denote on the agenda which group will share that day. New GitLabbers will share every week for the first three months on Wednesdays. If there are non-team page people in the call we end with those.
It is OK to talk over people or interrupt people to ask questions, cheer for them or show your compassion. This to encourage more conversation and feedback in the call.
Please look if the person you hand over to is present in the participant list so you don't hand over to someone who is not present.
The last person wishes everyone a good day.
Even if you cannot join the call, consider reviewing the recorded call or at minimum read through the team agenda and the links from there. We often use the team call to make announcements or discuss changes in processes, so make sure to catch up on the news if you have missed a team call (or more).
Release Retrospectives and Kickoffs
After GitLab releases a new version on the 22nd of each month, we have a 30-minute call on the next business day reflecting on what could have been better:
What went well this month?
What went wrong this month?
What could we have done better?
We spend the first part of the retrospective meeting reviewing the action items from the previous month.
After the retrospective meeting is done, we launch immediately into the kickoff meeting. The product team and other leads will have already have had some discussion in a meta issue on the GitLab.com CE tracker on what should be prioritized for each release. The purpose of this kickoff is to get everyone on the same page and to invite comments.
We will post the recordings of the kickoff and retrospective to YouTube and share the notes publicly.
Random Chat and Room
The #random chat channel is your go-to place to share random ideas, pictures, articles, and more. It's a great channel to check out when you need a mental break.
Come hang out any time in the random room, an open Google Hangout video chat where anyone with a GitLab email address can come and leave as they please. The link is in the description of the #random chat channel; consider bookmarking it. This room is open for all and should be distinct from the Coffee Break Calls, which are 1x1 conversations between teammates.
Scheduling Meetings
If you want to ask GitLabbers if they are available for an event please send a new calendar appointment from and to the company address. This makes it easier for people to check availability and to put on their calendar. It automatically shows up on calendars even when the email is not opened. It is easier to signal presence and to see the status of everyone. Please respond quickly to invites so people can make plans.
Every scheduled meeting should either have a Google Presentation (for example for functional updates that don't require participation) or a Google Doc (for most meetings) linked. If it is a Google Doc it should have an agenda, including any preparation materials (can be a presentation). Put the agenda in a Google Doc that has edits rights for all participants (including people not part of GitLab Inc.). Link the Google Doc from the meeting invite. Take notes of the points and todo's during the meeting. Nobody wants to write up a meeting after the fact and this helps to structure the thought process and everyone can contribute. Being able to structure conclusions and follow up actions in realtime makes a video call more effective than an in-person meeting. If it is important enough to schedule a meeting it is important enough to have a Doc linked. If we want to be on the same page we should be looking at that page.
If you want to check if a team member is available for an outside meeting, create a calendar appointment and invite the team member only, after they respond yes then invite outside people.
When scheduling a call with multiple people, invite them using a Google Calendar that is your own, or one specific to the people joining, so the calendar item doesn't unnecessarily appear on other people's calendars.
If you want to move a meeting just move the calendar appointment instead of reaching out via other channels, note the change at the top of the description.
If you want to schedule a meeting with a person not on the team please use Calendly.
When scheduling a meeting we value people's time and prefer the "speedy meetings" setting in our Google Calendar. This gives us meetings of, for example, 25 or 50 minutes leaving some time to write notes etc before continuing to our next call or meeting. (This setting can be found under the calendar Settings menu at "default event duration")
When creating a calendar event that will be used company wide, please place it on the GitLab Availability Calendar. That way the event is easily located by all individuals.
When you need to cancel a meeting, make sure to delete/decline the meeting and choose the option Delete & update guests to make sure everyone knows you can't attend and don't wait for you.
Video Calls
For smaller meetings we use Google Hangouts or Appear.in, for larger meetings we prefer Zoom (Google Hangouts technical limit is 15 for scheduled meetings).
For meetings that are scheduled via calendar there is automatically a Google Hangout URL added, this is the meeting place. Having a url in advance is much more reliable than trying to call via hangouts as the meeting start.
Google Calendar also has a Zoom plugin where you can easily add a Zoom link for a videocall to the invite
For meetings that are scheduled with Zoom, make sure to take out the Google Hangout link to avoid confusion.
If you need more privileges on Zoom (longer meeting times, more people in the meeting, etc.), please contact People Ops as described specifically for Zoom.
Note that if you select to record meetings to the cloud (setting within Zoom), they will be automatically placed in the GitLab Videos folder in Google Drive; on an hourly basis. You can find these videos in Google Drive by entering in the search bar: title:"GitLab Videos" source:domain.
Note also that after a meeting ends, Zoom may take some to process the recording before it is actually available. The sync to Google Drive happens on the hour mark, so if the recording is not available, it may take another hour to be transferred.
Use a headset with a microphone, Apple Earpods are great. Do not use computer speakers, they cause an echo. Do not use your computer microphone, it accentuates background noise. If you want to use your Bose headphones that is fine but please ensure the microphone is active.
Consider using a utility to easily mute/unmute yourself, see Shush in the tools section.
In video calls everyone should own camera and headset, even when they are in the same room. This helps to see the person that is talking clearly on the camera and their name in the list. It also allows people to easily talk and mute themselves. And using a headset prevents an echoing. You wouldn't share an office seat together, don't share your virtual seat at the table.
User Communication Guidelines
Keep conversations positive, friendly, real, and productive while adding value.
If you make a mistake, admit it. Be upfront and be quick with your correction. If you're posting to a blog, you may choose to modify an earlier post, just make it clear that you have done so.
There can be a fine line between healthy debate and incendiary reaction. Try to frame what you write to invite differing points of view without inflaming others. You don’t need to respond to every criticism or barb. Be careful and considerate.
Answer questions, thank people even if it’s just a few words. Make it a two way conversation.
When facing negative comment, respond patiently and treat every user as an individual, people with the strongest opinions can turn into the strongest supporters.
Writing Style Guidelines
At GitLab, we use American English as the standard written language.
Do not use rich text, it makes it hard to copy/paste. Use Markdown for things stored in git. In Google Docs use 'Normal text' using the style/heading/formatting dropdown and paste without formatting.
We use Unix style (lf) line endings, not Windows style (crlf), please ensure *.md text eol=lf is set in the repository's .gitattributes and run git config --global core.autocrlf input on your client.
Do not create links like "here" or "click here". All links should have relevant anchor text that describes what they link to, such as: "GitLab CI source installation documentation".
Always use ISO dates in all writing and legal documents, yyyy-mm-dd, e.g., 2015-04-13, and never 04-13-2015 or 13-04-2015
If you have multiple points in a comment or email, please number them to make replies easier.
When you reference an issue, merge request, comment, commit, page, doc, etc. and you have the URL available please paste that in.
In making URLs, always prefer hyphens to underscores, and always use lowercase.
The community include users, contributors, core team members, customers, people working for GitLab Inc., and friends of GitLab. If you want to refer to 'people not working for GitLab Inc.' just say that and don't use the word community. If you want to refer to people working for GitLab Inc. you can also use 'the GitLab Inc. team' but don't use the 'GitLab Inc. employees'.
When we refer to the GitLab community excluding GitLabbers please say 'wider community' instead of 'community'.
All people working for GitLab the company are the GitLab team, we also have the Core team that consists of volunteers.
Please always refer to GitLab Inc. people as GitLabbers, not employees.
Use inclusive and gender-neutral language in all writing. So for example, write "they, their" instead "he, his".
Always write GitLab with a capitalized G and L, even when writing GitLab.com.
Please refer to self-hosted installations as on-premises, not on-premise.
If you use headers properly format them (## in Markdown, "Heading 2" in Google docs), start at the second header level because header level 1 is for titles, do not end headers with a colon.
Always use an Oxford comma in lists of three or more terms.
Always use a single space between sentences rather than two.
Beamy is our company conference call robot. It lives in the San Francisco Howard St. office. Its main purpose is to allow those outside of the office a view into the space and people. When you call in to the beam your face will appear on the screen (so make sure your webcam works) and you can drive the robot around the office. It simulates being in the space without physically being there. It is really cool and everyone should try it and have fun with it.
You need an invite email to connect and to download a desktop client, please @mention Emily in the #general channel if you don't have the invite yet.
Beamy times: 8am until 6pm Pacific time. Please check the current time! on workdays and during all company events, for other times please @mention Sytse in the #valley channel to see if it is OK. It is on auto connect so you'll beam right in.
Once you are sent an invite you can beam in at any time and drive around our beam. Don’t forget to park it back on the charger when you are done. You can do so by driving up to the charger, when you see a green outline press AND HOLD 'p' until it's parked. Make sure it is charging, otherwise try again.
If you don't use headphones be careful about your volume and microphone placement, it might start singing, if so immediately mute your microphone and switch to headphones.
More info can be found at https://www.suitabletech.com/
Please report any questions or issues you have about the beam by @mentioning Emily in the #general channel.
Company phone number
If you need to provide the details of GitLab's contact information you can take the address of the office for reference; or the mailing address of the office in the Netherlands if that is more applicable.
If a phone number is required, leave this field empty by default. If that is not possible, then use the general number (+1-415-761-1791), but be aware that this number simply guides to a voice message that refers the caller back to contacting us via email.
