We're an all-remote company that allows people to work from almost anywhere in the world. We hire great people regardless of where they live, but with GitLab team members across more than 60 countries, it's important for us to practice clear communication in ways that help us stay connected and work more efficiently.
To accomplish this, we use asynchronous communication as a starting point and stay as open and transparent as we can by communicating through public issues, merge requests, and Slack channels.
We also place an emphasis on ensuring that conclusions of offline conversations are written down.
When we go back and forth three times, we jump on a synchronous video call.
We communicate respectfully and professionally at all times.
Effective & Responsible Communication Guidelines
Assume Positive Intent. Always being with a position of positivity and grace.
Kindness Matters. You are looking at a screen, but you are really talking to a person. If you wouldn't say it to a person's face, don't send it to them in a text message.
Express Your Thoughts. We live in different locations and often have very different perspectives. We want to know your thoughts, opinions, and feelings on things.
Own It. If you say it or type it, own it. If it hurts the company or an individual, even unintentionally, we encourage you to look at things from other points of view and apologize easily.
Feedback is Essential. It is difficult to know what is appropriate in every one of our team members 60+ countries. We encourage team members to give feedback and receive feedback in a considerate way.
Don't Underestimate a 1:1. Asynchronous communication (e.g., via text) is helpful and necessary. In some cases (e.g., to clarify misunderstandings) it can be much more effective to jump on a Zoom video call.
Embracing text communication and learning to use it effectively requires a mental shift. This can feel unusual or even uncomfortable for those who come from a colocated environment, where in-person meetings and vocalized communiques are the norm. Learn more about mastering the use of the written word in an all-remote setting.
Everyone is a Moderator
If you see something that concerns you in Slack, Issues, Merge Requests, Video, Emails or any other forum, we encourage you to respectfully say something directly to the individual in a 1:1 format. If you are not comfortable reaching out to the individual directly, please reach out to your direct manager or People Business Partner to discuss.
External communication
There are 8 key practices to consider during any meeting. They are the following:
Screenshare - If this is your first time meeting a customer/prospect/partner/etc., turn on your screenshare when you login to Zoom. This will help to make the customer/prospect feel more comfortable as they are certain your undivided attention is geared towards them.
Agenda - Always have an agenda prepped and ready to go. Share this with your audience. Make sure that everything on the agenda is accurate and ask if there’s anything missing that needs to be addressed during this call or for the future. When there is no agenda, it translates to you not caring.
70/30 Rule - Ask open ended questions that leave the audience talking 70% of the time, while you are talking 30% of the time. Please note that this varies based on the type of meeting that you are conducting. Be conscious of what questions needs to be asked and to capture those items.
Take Notes - Effective note-taking is a valuable skill that will help you retain and recall any important details. Be the person who remembers all the details of your audience's needs.
Adapt to Audience Tone - Before going into the business portion of your meeting, evaluate first the tone of the audience. Adapt your tone accordingly in order to appeal to various types of personalities.
Mid-call - Half-way through the meeting, check in with your audience. Ask them what their thoughts are on the progression of this meeting and if what you're presenting is on the right track. This helps both you and the audience by re-aligning expectations and making sure the meeting is going the right direction.
Pre-Close Summary - 10 Minutes (1-hour meetings) or 5 minutes (30 minute meetings) prior to ending the call, ask the audience to build out an agenda for the next step or meeting. This helps to secure next steps and to ensure there are no balls dropped.
Post Meeting Action - Immediately write down notes and next steps and input into proper directory (Google Drive, Salesforce, etc.).
Two Block Rule - For in person meetings with external parties you should wait until you're more than two blocks from the meeting before discussing the results of the meeting. Nobody wants to hear themselves being discussed in the bathroom.
It's best practice to start a discussion where possible with a Merge Request (MR) instead of an issue. An MR is associated with a specific change that is proposed and transparent for everyone to review and openly discuss. The nature of MRs facilitate discussions around a proposed solution to a problem that is actionable. An MR is actionable, while an issue will take longer to take action on.
Always open an MR for things you are suggesting and/or proposing. Whether something is not working right or we are iterating on new internal process, it is worth opening a merge request with the minimal viable change instead of opening an issue encouraging open feedback on the problem without proposing any specific change directly. Remember, an MR also invites discussion, but it's specific to the proposed change which facilitates focused decision.
Starting with a Merge Request is part of Handbook First and helps ensure the handbook is up-to-date when a decision is made.
Merge Requests, by default are non-confidential. However, for things that are not public by default please open a confidential issue with suggestions to specific changes that are you are proposing. The ability to create Confidential Merge Requests is also available. When possible, consider not including sensitive information so the wider community can contribute.
Not every solution will solve the problem at hand. Keep discussions focused by defining the problem first and explaining your rationale behind the Minimal Viable Change (MVC) proposed in the MR.
Be proactive and consistent with communication on discussions that have external stakeholders such as customers. It's important to keep communication flowing to keep everyone up to date. MRs can appear stale if there aren't recent discussions and no clear definition on when another update will be provided, based on feedback. This leaves those subscribed in the dark, causing unnecessary surprise if something ends up delayed and suddenly jumps to the next milestone. It is important that MRs are closed in a timely manner through approving or rejecting the open requests.
Have a bias for action and don't aim for consensus. Every MR is a proposal, if an MRs author isn't responsive take ownership of it and complete it. Some improvement is better than none.
Cross link issues or other MRs with related conversations. E.g. if there’s a ZenDesk ticket that caused you to create a GitLab.com MR, make sure to document the MR link in the ZenDesk ticket and vice versa. And when approving or rejecting the MR, include reason or response from ZenDesk. Put the link at the top of each MR's description with a short mention of the relationship (Report, Dependency, etc.) and use one as the central one and ideally close the alternate if duplicate.
If submitting a change for a feature, update the description with the final conclusions (Why an MR was rejected or why it was approved). 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 proposing a change, submit the smallest reasonable commit, put suggestions for other enhancements in separate issues/MRs 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 MRs open for a long time. MR's should be actionable – stakeholders should have a clear understanding of what changed and what they are ultimately approving or rejecting.
Make a conscious effort to prioritize your work. The priority of items depends on multiple factors: Is someone waiting for the answer? What is the impact if you delay it? How many people does it affect, etc.? This is detailed in Engineering Work flow.
When submitting a MVC, 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 suggest changes, you get the opportunity to improve your design and propose an alternative MR. This promotes collaboration and advances everyone's skills.
Respond to comments within a threaded discussion. If there isn't a discussion thread yet, you can use the Reply to comment button from the comments to create one. This will prevent comments from containing many interweaves discussions with responses that are hard to follow.
If your comment or answer contains separate topics, write separate comments for each, so others can address topics independently using the Reply to comment button.
For GitLab the product merge request guidelines are in the Contribution
guide and code review guidelines for reviewers and maintainers are described in our Code Review Guidelines.
Even when something is not done, share it internally so people can comment early and prevent rework.
Create a Work In Progress (WIP) merge request to prevent an accidental early merge. Only use WIP when merging it would make things worse, which should rarely be the case when contributing to the handbook. Most merge requests that are in progress don't make things worse, in this case don't use WIP, if someone merges it earlier than you expected just create a new merge request for additional items. Never ask someone to do a final review or merge something that still have WIP status, at that point you should be convinced it is good enough to go out.
If any follow up actions are required on the issue after the merge request is merged (like reporting back to any customers or writing documentation), avoid auto closing the issue.
If a project requires multiple approvals to accept your MR, feel free to assign multiple reviewers concurrently. This way the earliest available reviewer can start right away rather than being blocked by the preceding reviewer.
Issues
Issues are useful when there isn't a specific code change that is being proposed or needed. For example, you may want to start an issue for tracking progress or for project management purposes that do not pertain to code commits. This can be particularly useful when tracking team tasks and creating issue boards. However it is still important to maintain focus when opening issues by defining a single specific topic of discussion as well as defining the desired outcome that would result in the resolution of the issue. The point is to not keep issues open-ended and to prevent issues from going stale due to lack of resolution. For example, a team member may open an issue to track the progress of a blog post with associated to-do items that need to be completed by a certain date (e.g. first draft, peer review, publish). Once the specific items are completed, the issue can successfully be closed. Below are a few things to remember when creating issues:
When closing an issue leave a comment explaining why you are closing the issue and what the MVC outcome was of the discussion (if it was implemented or not).
We keep our promises and do not make external promises without internal agreement.
Be proactive and consistent with communication on discussions that have external stakeholders such as customers. It's important to keep communication flowing to keep everyone up to date. Issues can appear stale if there aren't recent discussions and no clear definition on when another update will be provided, based on feedback. This leaves those subscribed in the dark, causing unnecessary surprise if something ends up delayed and suddenly jumps to the next milestone. It is important that issues are closed in a timely manner. One way of doing this is having the current assignee set a due date for when they will provide another update. This can be days or weeks ahead depending on the situation, prioritization, and available capacity that we may have.
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 an issue to help define the first MVC via a subsequent MR.
Cross link issues or MRs with related conversations. Another example is to add "Report: " lines to the issue description with links to relevant issues and feature requests. When done, add a comment to relevant issues (and close them if you are responsible for reporting back, or re-assign if you are not). This prevents internal confusion and us failing to report back to the reporters.
Prioritize your work on issues in the current milestone.
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.
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.
Ensure the issue title states what the desired outcome should be. For instance, for bugs make sure the issue states the desired result, not the current behavior.
Regularly update the issue description with the latest information and its current status, especially when important decisions were made during the discussion. The issue description should be the single source of truth.
If you want someone to review an issue, do not assign them to it. Instead, @-mention them in an issue comment. Being assigned to an issue is a signal that the assignee should or intends to work on it. So you should not assign someone to an issue and mis-represent this with a false signal.
Do not close an issue until it is done. It's okay to explicitly ask if everyone is on board and in agreement on how to move forward, whether to iterate, close the open issue, or create a subsequent MR to implement a MVC.
Once a feature is done, update the description to add a link to the corresponding documentation. When using a Search Engine, issues often appear before documentation pages, which makes it harder to find the relevant information about the feature.
Write issues so that they exclude private information. This way, the issue can be public. Only use confidential issues, if the issue must contain non-public information.
Internal Communication
All written communication happens in English, even when sent one on one, because sometimes you need to forward an email or chat.
Discussion in issues or Merge Requests is preferred over everything else. If you need a response urgently, you can Slack someone with a link to your comment on an issue or merge request, asking them to respond there, however be aware that they still may not see it straight away. See Slack for more.
If you choose to email instead of chat it is OK to send an internal email that contains only a short message, similar as you would use in chat.
You are not expected to be available all the time. There is no expectation to respond to messages outside of your planned working hours.
Sometimes synchronous communication is the better option, but do not default to it. For example, a video call can clear things up quickly when you are blocked. See the guidelines on video chats for more detail.
It is very OK to ask as many questions as you have. Please ask them so many people can answer them and many people see the answer, so use issues or public chat channels (like #questions) instead of private messages or one-on-one emails. If someone sends you a handbook link they are proud that we have the answer documented, they don't mean that you should have found that yourself or that this is the complete answer, feel free to ask for clarification. If the answer to a question isn't documented yet please immediately make a merge request to add it to the handbook in a place you have looked for it. It is great for the person who answered the question to see you help to ensure they have to answer it only once. A merge request is the best way to say thanks for help.
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 rather leave comments on an issue.
When someone asks something, give back a deadline or that you did it. Answers like: 'will do', 'OK', 'it is on my todo list' are not helpful. If it is small it's better to spend 2 minutes and do the tasks so the other person can mentally forget about it. If it is large you need to figure out when you'll do it, by returning that information the other person might decide to solve it in another way if it takes too long.
It is OK to bring an issue to someone's attention with a CC ("cc @user"), but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.
Avoid creating private groups for internal discussions:
It's disturbing (all users in the group get notified for each message).
It's not searchable.
It's not shareable: there is no way to add people in the group (and this often leads to multiple groups creation).
They don't have a subject, so everyone has to remember the topic of each private group based on the participants, or open the group again to read the content.
History is lost when leaving the group.
It is perfectly fine to create a channel, even for a single customer meeting. These channels should be named "a_<customer-name>-internal" to indicate their "internal" nature (not shared with customers).
Use low-context communications by being explicit in your communications. We are a remote-only company, located all over the world. Provide as much context as possible to avoid confusion. For example, consider introducing yourself and your function when addressing the company during the company call, since not everyone may know who you are. Relatedly, we use ubiquitous language for communication efficiency.
Making a companywide announcement
"How do I make a companywide announcement?" is a common question for those new to GitLab. Common companywide announcements include (but are not limited to): policy iterations, requests to participate in a survey, unveiling the next GitLab Contribute location, codebase migrations, giveaways, and process improvements.
The following steps should be considered to ensure that a message is delivered to all in asynchronous fashion.
Select an upcoming Company Call that you'll be able to attend live, and add an agenda item to the Google Doc located in the calendar invite. Provide written context on the announcement, as well as a link to whatever is being announced or asked. This could be a GitLab Issue, Merge Request, Handbook page, survey, registration portal, etc. An example is shown below.
Immediately following the verbal announcement on the Company Call, copy the written text from the Company Call agenda Google Doc and paste it into the #company-announcements Slack channel. An example is shown below.
Optional: If desired and appropriate, offer a companywide Zoom call to host an AMA (Ask Me Anything). Oftentimes, questions can be managed within the Discussion tab of a GitLab Issue or Merge Request. For broad announcements, such as registration opening for GitLab Contribute, an AMA may be better suited for a large volume of inquiries. To schedule a companywide call, please make a request in the #peopleops Slack channel, and include a Google Doc in the invite for questions.
Top misused terms
Below are terms people frequently use when they should use another term.
The format is: misused term => correct term, reason why.
IPO => becoming a public company, because we might do a direct listing instead of an offering.
EE => subscribers or paid users, because EE is a distribution and not all people who use EE pay us.
Obviously => skip this word, since using things like "obvious/as we all know/clearly" discourages people who don't understand from asking for clarification.
They => Do not refer to other teams at GitLab externally as "they" (e.g., "Well, they haven't fixed that yet!"). There is no "they" or "headquarters" - there is only us as team members, and it's one team. You could instead say something like "The Product team is looking at that issue…". When used in the context of a pronoun, they is as valid as he, she, or any other pronoun someone decides to use.
Deprecate => delete or remove, since we usually mean we're removing a document or feature whereas deprecation is actually leaving the thing intact while discouraging its use. Unlike other terms on this list, there are times where "deprecate" is the right word, for example in formal product process.
Asking "is this known"
If something is behaving strangely on https://gitlab.com, it might be a bug.
It could also mean that something was changed intentionally.
Please search if the issue has already been reported.
If you are unsure whether the behavior you experience is a bug, you may ask in the Slack channel #is-this-known.
Make sure that no-one has experienced this issue before, by checking the channel for previous messages
If you know which stage of the DevOps lifecycle is affected, it is also okay to ask in #s_{stage}, for example #s_manage.
Describe the behavior you are experiencing, this makes it searchable and easier to understand.
Different people might look for different things in the same screenshots.
Asking in a single channel helps discoverability, duplicated efforts and reduces noise in other channels.
Please refrain from asking in general purpose channels like #frontend, #backend, #development or #questions.
Multimodal communication
Employ multimodal communication to broadcast important decisions. To reach our distributed organization, announce important decisions on the company call, email the appropriate team email lists, Slack the appropriate channels, and target 1:1s or other important meetings on the same day, with the same information.
When doing this, create and link to a single source of truth: ideally the handbook, otherwise an epic, issue, or Google Doc. The email or Slack message should not be the source of truth.
Security vulnerabilities are not public since it would allow attackers to compromise GitLab installations. We do make them public after we remediated a vulnerability. Issues that discuss how to improve upon the security posture of an implementation that is working as intended can be made public, and are often labeled as feature proposals. Security implementations that detect malicious activities cannot be made public because doing so would undermine our operations.
Financial information, including revenue and costs for the company, is confidential because we plan to be a public company and, as such, need to limit both the timing and content of financial information as investors will use and rely on it as they trade in GitLab stock. As a rule of thumb, if it is a first step to constructing a profit, we need to keep it confidential. Examples include:
Some information is kept confidential by the People Group to protect the privacy, safety, and security of team members and applicants, including applications, background check reports, reference checks, compensation, termination (voluntary and involuntary) details, demographic information, and home address. Whistleblower identity is confidential. People Group policies and processes are public, internally and externally. As examples, Job families and our Compensation Calculator are public.
Performance improvement plans, disciplinary actions, as well as individual feedback, are confidential as they contain private negative feedback and negative feedback is 1-1 between team members and managers.
Partnerships with other companies are not public since the partners are frequently not comfortable with that.
Acquisition offers for us are not public since informing people of an acquisition that might not happen can be very disruptive.
Acquisition offers we give are not public since the organization being acquired frequently prefers to have them stay private.
Customer information is not public since customers are not comfortable with that, and it would make it easier for competitors to approach our customers. If an issue needs to contain any specific information about a customer, including but not limited to company name, employee names, number of users, the issue should be made confidential. Try to avoid putting customer information in an issue by describing them instead of naming them and linking to their SalesForce account. When we discuss a customer by name that is not public unless we're sure the customer is OK with that. When we discuss a competitor (for example in a sales call) this can be public as our competitive advantages are public.
Competitive sales and marketing campaign planning is confidential since we want the minimize the time the competition has to respond to it.
Plans for reorganizations are not public and on a need-to-know basis within the organization. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team members informed whenever possible.
Discussions that involve decisions related to country of residence are not public as countries are a core part of people's identity and any communication should have complete context. The output of such decisions, such as country hiring guidelines will be public.
Numbering is for reference, not as a signal
When taking notes in an agenda, in the handbook, or on our OKRs, keep items numbered so we can refer to Item 3 or 4a.
The number is not a signal of the importance or rank of the subject unless explicitly stated to be such.
It is just for ease of reference.
Acknowledgement Receipts (ACK)
In order to effectively communicate an important change to hundreds of distributed employees, we occasionally use an ACK process:
To prevent overuse, this should only be used by a member of the exec team (but anyone may ask an exec to sponsor one).
As a guideline, we'd expect no more than one per quarter to be sent out (too many ACKs lose power).
Clone the form from this template and fill it out.
Link to MRs and Handbook pages instead of duplicating your content in the form. Why handbook first?
Ask PeopleOps to pull a spreadsheet of email addresses from BambooHR with the column headers First Name, Last Name, Job Title, Department, Manager, and Work Email. Double check it and turn the emails into a comma-delimited string with an excel formula like this: =TEXTJOIN(", ", true, Sheet1!E2:E432)
Send the form and expect to get 50% of the responses in the first 24 hours. To get the rest:
Promote in the company call.
Post in common Slack channels.
Add to staff meeting agendas.
Suggest to team managers to post to their team Slack channels, ask for explicit :ack: and pin to the channel until everyone responds.
Lastly, reach out 1-on-1 to stragglers while being respectful of vacation time.
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 by replying to all, 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're sending an email to a large group of people (or a distribution list), put those recipients in BCC (rather than in the "To" field) so that a reply all won't ping hundreds of people.
If you forward an email without other comments please add FYI (for your information), FYA (for your action), or FYC (for your consideration). If you forward an external request with FYC it just means the person who forwarded it will not follow up on the request and expects you to decide if you should follow up or not, the terms comes from movie promotion to voters.
Only G-Suite domain admins are allowed to provision Google Groups and email distributions.
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.
If you or your team needs to send an email to a group of team members, not grouped in a current Google email group, and specifically related to PII (location, state, country, etc) please contact a People Operations Analyst at compensation@domain who can create an email list from BambooHR data, with approval.
Slack
Slack is to be used for informal communication only. Only 90 days of activity will be retained. Accordingly, Slack should specifically NOT be used for:
obtaining approvals;
documenting decisions;
storing official company records or documents; or
sharing personal or sensitive information regarding any individuals
Avoid Private Messages
When using Slack for work-related purposes, please avoid private messages. Private messages discourage collaboration. You might actually be contacting the wrong person, and they cannot easily redirect you to the right person. If the person is unavailable at the moment, it is less efficient because other people cannot jump in and help. Use a public channel and mention the person or group you want to reach. This ensures it is easy for other people to chime in, involve other people if needed, and learn from whatever is discussed.
If someone sends you a work-related private message, it is okay to let them know you'd like to take the conversation to a public channel, linking to this section of the handbook. The process might look something like:
In the private message: Thanks for reaching out, that's a great question/idea I think the rest of the team could benefit from. I'm going to move this to #public-channel based on [our desire to avoid private messages](/handbook/communication/#avoid-private-messages)
In the appropriate public channel: @Person asked "question" in a DM, pulling that out here if anyone else has input.
Answer the question in a thread on that channel message, allowing others to benefit.
If you find yourself getting a lot of private messages that should go in a public channel, consider changing your Slack status to an attention grabbing emoji and set it to something like:
Please consider posting in a public channel before direct messaging
Why direct message me when you can post in a public channel?
If you must send a work-related private message, don't start a conversation with "Hi" or "Hey" as that interrupts their work without communicating anything. If you have a quick question, just ask the question directly, and the person will respond asynchronously. If you truly need to have a synchronous communication, then start by asking for that explicitly, while mentioning the subject. e.g., "I'm having trouble understanding issue #x, can we talk about it quickly?".
Do not use group private messages
Use private channels instead of group private messages. Group private messages are very hard to maintain, track and respond to. First, consider whether the conversation can take place in a public channel. If not, please use a private channel instead.
Why we track % of messages that are not DMs
For all the same reasons that we want to avoid private messages, use public channels, and be handbook-first, we track the % of messages that are not DMs.
As we grow headcount, we exponentially increase the lines of communication- 3 people have 3 communication lines, 4 have 6, and 41 have 820.
As a result, there is a natural tendency for people to prefer private channels of communication.
The intentions are good, as people are looking to reduce noise for others, but this can lead to the same problems as described elsewhere on this page, notably:
communication is siloed
as we grow, people may be reaching out to the wrong person
if you have a question, other people might have it too
Slack is our primary source of chat communication and is where many personal interactions happen.
We want to continue to encourage folks to build personal relationships with one another which will often happen over DMs.
We know that DMs will always exist.
We don't want to eliminate them.
We set a target of Slack DMs to consist of less than 50% of messages.
At the time that we set this target, it is about 80% of communications.
Everything at GitLab is a work in progress, so if we see a culture shift where Slack is not where work is occurring, thus inflating the amount of communication that is personal that is occurring, we can always change this KPI, but the steady growth of Slack messages paralleling the number of team members does not seem to suggest that is the case.
The previous KPI (% of messages sent in public channels) was about public channels but since some necessary parts of the business occur in private channels (discussions around comp, hiring, recruiting- and we do A LOT of hiring), this version of the KPI makes more sense.
Earlier in our history, 50% of all communication was in public channels.
Use Public Channels
If you use Slack and plan to message 3 or more people, we recommend a channel for customer/issue/project/problem/partnership.
If something is important but not urgent - like complimenting or encouraging the entire team - use email or post in the channel without @-mentioning the team.
It's not rude to leave a channel. When you've had your questions answered or are no longer interested, feel free to leave the channel so it won't distract you anymore.
The usage of ChatBots for integrations can sometimes depend upon the name of the channel. You should consult the channel about such integrations before changing the name of commonly used/popular channels to avoid inadvertently breaking integrations.
Be respectful of others' time
If you're only referring to someone, but don't actually need their attention, and want to spare them from getting notified, spell out their name normally without @ mentioning them.
Slack messages should be considered asynchronous communication, and you should not expect an instantaneous response; you have no idea what the other person is doing.
Because we work globally, you may receive Slack mentions at any time of day. Please consider enabling Slack's Do not disturb functionality so you don't get interrupted, for example, in your offtime.
Slack does not currently support automatically activating Do Not Disturb over weekends. Please bear this in mind if you choose to work over weekends, as your Slack message to someone may interrupt their time off. Consider using another form of communication instead.
Do not feel obligated to respond to Slack messages when you are not working.
Feel free to send a colleague a link to these guidelines if the communication in Slack should be done asynchronously.
Please avoid using @here or @channel unless this is about something urgent and important. 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 promptly since people get pinged too frequently. Additionally, if you are planning to @mention a specific team (Slack User Group), consider the size of the group you are mentioning (see group membership) and the impact of pinging all of these people for the particular situation. If something is urgent and important:
Use @here to notify all currently active members in the room. Please only use @here if the message is important and urgent.
Use @channel to notify ALL members in the room, irrespective of away status. Please only use @channel if the message is important and urgent.
If you are aware that your teammate is on vacation, avoid mentioning them in a high volume channel. It will be difficult to find the information or question when they return. If you need to ensure they refer back to the thread, ensure to send them a link to the relevant Slack message through a direct message.
General Guidelines
If the subject is of value to the wider community, consider commenting on an existing issue or opening a new issue instead.
Use the :white_check_mark: emoji or similar to indicate an inquiry has been answered. Anyone can add the emoji. If you're not sure, then feel free to leave it up to the person who asked. An emoji indicator is particularly helpful in channels where lots of questions are posted, such as #questions, and #git-help.
In general, you can think of emoji reactions as equivalent to body-language responses we use in real-life conversations, such as nodding your head as encouragement when a verbal (or in Slack, written) response might be too much.
In public channels, threads are valuable for keeping conversations together. If you want to respond to a question or comment in a channel, please start a thread instead of responding below them in the channel. This helps to keep the discussion in one place where it is easy to follow, and reduces noise as each message in a thread does not result in an unread message for everyone in the channel.
Unless you're in an active chat, don't break up a topic into multiple messages as each one will result in a notification which can be disruptive. Use threads if you want to provide extra info to the question/comment you posted.
If you are having a hard time keeping up with messages, you can update your preferences to have Slack email you all notifications. To change the setting, go to Preferences > Notifications > When I'm not active on desktop... and "send me email notifications."
If you agree in a message 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.
As an admin of the Slack workspace, if given the option to "Disable future attachments from this website" when removing an attachment from a message this will blacklist the link/domain from unfurling in the entire Slack workspace. Be careful and deliberate when choosing this option as it will impact every user in the workspace.
When referencing a Slack thread in a GitLab.com issue, don't only link to the thread. Not only will people outside of the GitLab organization be unable to access the content, but the link will expire after the Slack retention period expires. Instead:
Review the contents for confidentiality of users, customers, or any other sensitive information before posting.
Copy and paste the relevant parts of the thread into the issue using blockquote formatting.
Link to the Slack thread and include (internal) after the link. For example: https://gitlab.slack.com/archives/C0AR2KW4B/p1555347101079800 (internal)
Post a link to the issue note in the Slack thread to let others know that discussion has moved to the issue.
When selecting your Slack display name, please do not have your name in all capital letters as this is often associated as shouting in written communications.
Getting in touch with the e-group
To get in touch with the e-group on Slack, you can use the following channels. When in doubt, you can use the general #e-group channel to reach out to the entire group.
Member
Channel
CEO
#ceo
CFO
#finance
VP of Product
#product
VP of Product Strategy
#product-strategy
VP of Engineering
#vpe
CRO
#sales
CMO
#marketing
CPO
#peopleops
CLO
#legal
Key Slack channels
The alphabetically sorted starter list below spotlights a few of GitLab's many Slack channels in an effort to provide guidance to team members regarding the best places to ask specific questions and/or engage in discussion on a variety of topics. See Slack's Help Center for instructions on browsing all available channels.
Companywide updates and announcements; all GitLab team members are automatically added to this channel.
#diversityandinclusion
Stay up to date on GitLab’s latest Diversity and Inclusion initiatives and share feedback and thoughts about how we can make our environment even more inclusive.
#git-help
Specific questions about using Git in the terminal.
#intheparenthood
Cute kid photos, tips on getting your children ready for school, etc.
#is-this-known
Get help in finding existing issues for existing problems.
#it_help
Create a Help Request in this channel should you have any IT general questions or trouble with setup (e.g. 2FA, accounts, etc.).
#loc-specific channels
Search loc_insert your location to connect with GitLab team members in your location (e.g #loc_italy, #loc_chicagoland, #loc_mexico, etc.).
#mr-buddies
For any questions regarding merge requests.
#new_labbers
For new GitLab team members to introduce themselves to the company and for existing team members to share updates with new hires.
#office-today
GitLab is an all-remote organization. Where’s your office today? Share a photo or use words to describe it.
#payroll_expenses
For questions pertaining to payroll and expenses (e.g. ADP, Expensify, etc.).
For any general help with anything, really, and Git. If you have a question but you're not sure in which channel you should ask it, questions is always a great place!
#random
Anything and everything from photos, news, food, music, etc.
IMPORTANT: Once service is restored, go back to Slack.
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.
If you have content in a Google Doc that is later moved to the website or handbook, deprecate the Google Doc.
When referring to a Google Doc or folder on the Google Drive in the handbook, refrain from directly linking it. Instead, indicate the name of the doc. If you link the URL people from outside the organization can request access, creating workload and the potential for mistakes.
(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 access 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.
If you want to quickly find where a team member's cursor is in a Google Doc, click their icon at the top of the document and the app will jump you to the current location. This works in Sheets and Presentations as well.
You can set the notifications on a Google Doc so you only get emailed when someone tags you directly instead of getting emails for every comment. Click on "notifications" and select "Only yours". By the way, when you create the doc, it defaults to All, but when you are just shared with it, it defaults to Only yours. There is no global default.
.
You can find a template of the GitLab letterhead on the shared Google Drive. Please be sure to make a copy of the document to your Google Drive before customizing the template for your use.
If you want to have the Google Doc be readable to the public, do not change the sharing settings from 'Editable by Everyone at GitLab', publish the document instead.
In all cases, the sharing settings (who a document is shared with, if it is visible to the whole company, etc.) on a Google Doc should be the single source of truth for the confidentiality of the document.
How to publish a Google Doc
Under the 'File' menu, go to 'Publish to the web'.
A new pop-up 'Publish to the web' will appear, click 'Publish'.
A confirmation will appear on the top of the doc, click 'OK'.
Back in the pop-up 'Publish to the web', a link to share will appear.
Add the link to the top of the document after the text: "Publicly shared via"
Use this link to share to your audience.
How to deprecate a Google Doc
Add 'Deprecated: ' to the start of the title.
Remove the content you moved.
Add a link to the new location at the beginning of the doc/first slide/first tab.
Add a link to the merge request or commit that moved it (if applicable).
Presentations
All presentations are made in Google Slides using our templates.
Please allow anyone at GitLab to edit the presentation (preferred) or at least comment on the presentation.
If the content can be public use File > Publish to the web > Publish to get a URL and paste that in the speaker notes of the first slide (commonly the title slide).
The title of every slide should be the message you want the audience to take away, not the subject matter. So use 'Our revenue more than doubled' instead of 'Revenue growth'.
At the end of the presentation when you go to Q&A stop presenting in Zoom. This way the other people can see the person who is speaking much better.
Say Thanks
Thank people that did a great job in our "Thanks" Slack channel.
If someone is a team member just @ mention them, if multiple people were working on something try @ mentioning each person.
If possible please include a link with your thanks that points to the subject matter that you are giving thanks for, for example a link to a merge request.
Add emoji reactions to other peoples thank you messages. Use the value emojis when you see a thank you message ties to GitLab's values.
Please do not mention working outside of working hours, we want to minimize the pressure to do so.
Please do not celebrate GitLab contribution graphs that include working for uninterrupted weeklong cycles, as this does not foster healthy work/life harmony for all team members. While GitLab team members are free to time-shift and work weekends in place of weekdays, we discourage celebrating the absence of time away from work.
Don't thank the CEO or other executives for something that the company paid for, thank GitLab instead.
To thank someone who is not a team member please mention a Community Advocate, the name of the person, a quirky gift
and link to their work. For example, "@manager, @communityadvocate: Joe deserves a lawnmower for link". The Community Advocate 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".
Communicate directly
When working on a problem or issue, communicate directly with the people you need support from rather than working through reporting lines. Direct communication with the people you need to collaborate with is more efficient than working through your manager, their manager, or another intermediary.
Escalate to management if you are not getting the support you need. Remember that everyone is a manager of one and they might have to complete their own assignments and inform the reporting lines.
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 GitLab team members or our board member Bruce Armstrong.
Company Call
Company calls happen Monday to Thursday.
Every Friday we have an AMA with an executive to talk about anything the people at our company are thinking about.
Schedule
PT:
UTC:
:
APAC schedule
PT:
UTC:
:
Everyone at GitLab is invited to the company call.
We also have a company call for GitLab team members in the APAC region, which occurs every Tuesday 14:00 Australia/Sydney time.
This call will also be recorded so the rest of the company can see what their colleagues have been up to! Everyone is encouraged to join this call as well, but it is not mandatory.
We use Zoom, (please be sure to mute your microphone). If using the Zoom web app, you can go to settings and check always mute microphone when joining a meeting.
The link is in the calendar invite and also listed at the top of the company call agenda Google Doc called Company Call 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 Company Call", which is accessible to all users with a GitLab.com e-mail account.
We start on time and do not wait for people.
The person who has the first item on the agenda starts the call.
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.
After the general announcements we do a breakout call.
It is OK to talk over people or interrupt people to ask questions, cheer for them or show your compassion. This encourages more conversation and feedback in the call. Also see the interruption item in video calls.
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.
Even if you cannot join the call, consider reviewing the recorded call or at minimum read through the agenda and the links from there. We often use the company call to make announcements or discuss changes in processes, so make sure to catch up on the news if you have missed a company call (or more).
If you are scheduling a meeting, avoid scheduling during the company call so that meeting attendees do not need to choose between your meeting and the company call. As a remote workforce, the company call is an important part of our culture.
Breakout Room call
The last person on the agenda announces that we are transferring to Breakout calls and mentions that we will be be automatically allocated to random groups. We encourage everyone to make this announcement fun and ask that they read the discussion question for the day. Please note that nearly every day we have new team members joining the company. Please give the full instructions as there is likely new team members in the call.
We split into small groups of 8-10 people each, immediately at the end of the Company Call approximately after 5 minutes into the call.
The groups are randomly generated by the People Operations Specialist using the zoom breakout room feature. The number of groups is determined by attendance in the company call divided by 8-10 people per group.
Once the People Operations team has started the call, you will get a prompt to join a room, please click Join Breakout Room.
If you finish your Breakout Room group call earlier than 25 minutes after the hour, please leave the company call, no need to join back to the original group call.
Every call has a randomly generated Breakout room question. Everyone at GitLab can contribute to our questions list. Please add your questions as per the read.me on this this sheet. These questions are great icebreakers for new team members or if you don't have an update you want to share that day. You can talk about anything, as long as it isn't about results at work.
Breakout Room Hosts
Please stop the Company Call recording just before you assign team members to breakout rooms to keep the recording short.
Sometimes Zoom will leave a few people unassigned, please check top most of the breakout room list and assign any people in the unassigned category to random rooms with the least members.
The rooms should close 25 mins after the start of the company call, please send a broadcast message to all 2 minutes before closing all rooms alerting them of the remaining time.
At 25 mins after start of the company call, please close all rooms and end the company call.
Breakout Rooms Structure
These calls are unstructured to allow for natural interaction, but everyone should get a chance to share at least once.
It helps to pause slightly between talking about different topics to allow for discussion.
If you are unsure of who should start or speak next, follow the order listed in Zoom.
Prompts for things you might share:
Hobbies and interests.
What you've been up to recently.
Things you're looking forward to.
Sports and wellness.
Cooking, entertaining, and creative projects.
Travel, kids, family, and pets.
Music, books, TV & movies, and video/board games.
Archiving the Company Call Agenda
The company call agenda document is archived into monthly in the archive folder. As from 2019, the archives are in separate docs per month to prevent docs becoming too heavy and taking too long to open.
On the 8th of every month, People Operations Specialist or anyone else in the company can create a new document in the Company Call Agenda Archive - YYYY folder and create a new document titled Company Call Agenda Archive - Month.
Then copy the previous months agenda items from the current Company Call Adenda document to the newly created archive document.
A link to the archive can be found at the top of the company call agenda document.
Release Retrospectives and Kickoffs
After GitLab releases a new version on the 22nd of each month, we have a
30-minute call a few days later 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.
On the 8th of each month (or the next business day), we have a kickoff meeting
for the version that will be released in the following month. The product team and other leads will have already had
discussions on what should be prioritized for that release. The purpose of this kickoff is
to get everyone on the same page and to invite comments.
The #random Slack 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.
Scheduling Meetings
If you want to ask GitLab team members if they are available for an event please send a calendar invite with Google Calendar using your Google GitLab account to their Google GitLab account. When you add a GitLab team member as a “Guest” in Google Calendar, you can click the See Guest Availability button to check availability and find a time on their calendar. These calendar invites will automatically show up on all parties calendars even when the email is not opened. It is an easier way to ensure everyone has visibility to the meeting and member’s status. Please respond quickly to invites so people can make necessary 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 todos 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.
Please click 'Guests can modify event' so people can update the time in the calendar instead of having to reach out via other channels. You can configure this to be checked by default under Event Settings.)
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:
When scheduling a meeting, please try to have it start at :00 (hour) or :30 (mid-hour) to leave common start times available for other meetings on your attendees' calendars. Meetings should be for the time needed, so if you need 15 minutes just book that.
When creating a calendar event that will be used company wide, please place it on the GitLab Team Meetings 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.
If you want to schedule a meeting with a person not on the team please use Calendly. Use Google Calendar directly if scheduling with a GitLab team member.
Indicating Availability
Indicate your availability by updating your own calendar using Google's "out of office" feature and include the dates you plan to be away in your automated response. Note that this feature will automatically decline any meeting invitations during the time frame you select.
Put your planned away time including holidays, vacation, travel time, and other leave in your own calendar. Please see Communicating your time off for more.
Set your working hours in your Google Calendar settings.
Utilize PTO Ninja to keep other GitLab team members aware of your planned time away within Slack.
Video Calls
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.
Sometimes it's better to not have a video call. Consider these tradeoffs:
It is difficult (or impossible) to multi-task in a video call.
It may be more efficient to have an async conversation in an issue, depending on the topic.
A video call is limited in time: A conversation in an issue can start or stop at any time, whenever there's interest. It is async.
A video call is limited in people: You can invite anybody into an async conversation at any time in an issue. You don't have to know who are the relevant parties ahead of time. Everyone can contribute at any time. A video call is limited to invited attendees (and those who have accepted).
You can easily "promote" an async conversation from an issue to a video call, as needed. The reverse is harder. So there is lower risk to start with an async conversation.
For a newcomer to the conversation, it's easier and more efficient to parse an issue, than read a video transcript or watch it.
Conversations in issues are easily searchable. Video calls are not.
Try to have your video on at all times because it's much more engaging for participants
Don't worry if you can't pay attention at the meeting because you're doing something else, you are the manager of your attention. The flip-side of being the manager of your own attention is that others should not hesitate to request your attention when it is needed.
It's okay to eat on video if you're hungry (please turn your mic off)
However you are groomed when you meet a family member or close friend is fine for GitLab internal meetings (including if you just got back from a run)
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".
Do not feel forced to have your video on, use your best judgement
Additional points for video calls with customers or partners
Results come first. Your appearance, location and background is less important than making customers successful so don't wait for the perfect time / place when you can engage a customer right away.
Communicating that GitLab is an enterprise grade product and service provider is supported by the way you present yourself. Most of the time, if you would not wear something or present yourself in a certain way at a customer's office, candidate interview, or partner meeting in person then it's probably not the right choice on a video call with them either.
Green screens are a great background solution. It's great to work in your garage or basement! Just get a green screen behind you and put up a professional background image to present well externally and still use the rest of the room how you want!
Google Calendar also has a Zoom plugin where you can easily add a Zoom link for a video call to the invite
For meetings that are scheduled with Zoom:
If you need more privileges on Zoom (longer meeting times, more people in the meeting, etc.), please contact People Operations Specialist 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 via a scheduled pipeline. You can find these videos in Google Drive by entering in the search bar: title:"GitLab Videos" source:domain. The script for syncing the files is here.
Note also that after a meeting ends, Zoom may take some time 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.
As a remote company we are always striving to have the highest fidelity, collaborative conversations. Use of a headset with a microphone, is strongly suggested.
If other people are using headphones then no-headphones works fine. But if multiple people aren't using headphones you get distractions.
Reasons to use headphones:
Computer speakers can cause an echo and accentuate background noise.
Using headphones decreases the likelihood of talking over one another, enabling a more lively conversation.
Better sound quality, avoiding dynamic volume suppression due to echo cancellation.
Always be sure to advise participants to mute their mics if there is unnecessary background noise to ensure the speaker is able to be heard by all attendees.
We start on time and do not wait for people. People are expected to join no later than the scheduled minute of the meeting (before :01 if it is scheduled for :00). The question 'is everyone here' is not needed.
It feels rude in video calls to interrupt people. This is because the latency causes you to talk over the speaker for longer than during an in-person meeting. We should not be discouraged by this, the questions and context provided by interruptions are valuable.
This is a situation where we have to do something counter-intuitive to make all-remote meetings work. In GitLab, everyone is encouraged to interrupt the speaker in a video call to ask a question or offer context. We want everyone to contribute instead of a monologue.
Just like in-person meetings be cognizant of when, who, and how you interrupt, we don't want manterrupting.
We end on the scheduled time. It might feel rude to end a meeting, but you're actually allowing all attendees to be on time for their next meeting.
Do not use the chat of products like Zoom to communicate during the call, use the linked document instead. This allows everyone to contribute additional questions, answers, and links in the relevant place. It also makes it easier for people in conflicting timezones to contribute questions before the call and makes it easier to review questions and answers after the call, which can be before watching the recording.
Write down your questions in the agenda before vocalizing. Always ask people to vocalize their questions to provide the most detailed context and for any people that only use audio, for example listening to a recording of the call later while running.
You do not need to remind other people to vocalize their questions. Just say their name and a keyword of the question. 'Jay about credit-cards'
If there isn’t a note taker listed in the document at the start of the meeting, people should self-note-take. Consider asking other people to write down the answers in real-time to allow the person who asked the question to focus on the answer. The person asking the question can touch up the answer when the conversation has moved on to something less relevant to them.
Every comment is document worthy, even small support comments such as +1 or Very Cool!.
It is unusual to smoke in an open office or video conference, vaping is associated with this. For this reason we ask that you don't vape during calls, and if you absolutely have to, kindly switch your camera off.
Speak up when you notice something is not working. If you notice someone's microphone, web cam or latency is causing issues for them it is good to speak up. On a video call it can be harder for the speaker to notice that they aren't being understood compared to a face to face conversation. As such you will be doing them a favour by speaking up early to let them know that they are having a problem. Also see Hear nothing say something for further explanation.
You are the manager of your attention
You are the manager of your attention, and you decide when you do or don't pay attention in a meeting.
You will always have more work than time in your life.
If you get invited to a meeting you don't think you should go to, you should decline the meeting.
It is better to cancel than to show up and not pay attention.
On the other hand, not every part of a meeting is relevant, but it can sometimes be helpful to have more people in a call.
If you only have one discussion point, if possible, try to reorder the meeting agenda to have your point first and then drop from the call.
If you get asked a question when you're not paying attention, it is an okay use of time to repeat a question every now and then.
You should take pride in being the first person to add a question to a
meeting agenda, however unlike the First post
meme we do want the first post to be
more than just "First!". The meeting DRI will be happy to see there is a
question ready before to kick off the meeting. The Meeting DRI should remember
to thank the person for asking the first question.
Hybrid calls are horrible
In calls that have remote participants everyone should use have their own equipment (camera, headset, screen).
When multiple people share equipment the following problems arise for remote participants:
Can't hear the sharing people well.
Background noise since the microphone of the sharing people on all the time.
Can't clearly see facial expressions since each face takes up only a small part of the screen.
Can't easily see who is talking since the screen shows multiple people.
Hard getting a word in since their delay is longer than for the sharing people.
The people sharing equipment also have problems because they don't have their own equipment:
Can't easily screen share something themselves.
Trouble seeing details in screen sharing since the screen is further away from them.
Can't scroll through a slide deck at their own pace.
Sharing people can't easily participate (view or type) in a shared document with the agenda and meeting notes.
The disadvantages for remote people are much greater than for the sharing people and hard to notice for the sharing people.
The disadvantages cause previously remote participants to travel to the meeting to be in person for a better experience.
The extra travel is inefficient since it is time consuming, expensive, bad for the environment, and unhealthy.
Theoretically you can have multiple people in a room with their own equipment but in practice it is much better to be in separate rooms:
It is annoying to first hear someone talk in the room and then hear it over audio with a delay.
It is hard to consistently mute yourself when not talking to prevent someone else's voice coming through your microphone as well.
Google Calendar
We recommend you set your Google Calendar access permissions to 'Make available for GitLab - See all event details'. Consider marking the following appointments as 'Private':
Personal appointments.
Confidential & sensitive meetings with third-parties outside of GitLab.
1-1 performance or evaluation meetings.
Meetings on organizational changes.
There are several benefits and reasons to sharing your calendar with everyone at GitLab:
Transparency is one of our values and sharing what you work on is in line with our message of "be open about as many things as possible".
Due to our timezone differences, there are small windows of time where our availabilities overlap. If other members need to schedule a new meeting, seeing the details of recurring meetings (such as 1-1s) will allow for more flexibility in scheduling without needing to wait for a confirmation from the team member. This speaks to our value to be more efficient.
If you add blocks of time spent on recurring tasks to your Google Calendar to remind yourself to do things (e.g. "Check Google Analytics"), consider marking yourself "Free" for those events so that coworkers know they may schedule a meeting during that time if they can't find another convenient time.
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.
Assume positive intent and explicitly state the strongest plausible interpretation of what someone says before you respond, not a weaker one that's easier to criticize. Rapoport's Rules also implores you to list points of agreement and mention anything you learned.
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.
By default, discussions in issues and MRs are public and could include participation of wider community members. It is important to make the wider community members feel welcome participating in discussions and sharing their view. Wider community members also submit MRs to help improve our website/handbook and this is often their first contribution to GitLab. We want to make sure that we are responsive to their contributions and thank them for helping improve GitLab.
Adhere to the Code of Conduct in all communication. Similarly, expect users to adhere to the same code when communicating with the GitLab team and the rest of the GitLab community. No one should accept being mistreated.
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 to format text that is stored in a Git repository. 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.
Always write a paragraph on a single line. Use soft breaks ("word wrap") for readability. Don't put in a hard return at a certain character limit (e.g., 80 characters) and don't set your IDE to automatically insert hard breaks. Merge requests for the blog and handbook are very difficult to edit when hard breaks are inserted.
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". Using meaningful links is important to both search engine crawlers (SEO) and people with accessibility issues.
This guidance should be followed in all places links are provided, whether in the handbook, website, GoogleDocs, or any other content.
Avoid writing GoogleDocs content which states - Zoom Link [Link].
Rather, paste the full link directly following the word Zoom.
This makes the link more prominent and makes it easier to follow while viewing the document.
Always use ISO dates in all writing and legal documents since other formats lead to online confusion. Use yyyy-mm-dd, for example 2015-04-13, and never 04-13-2015, 13-04-2015, 2015/04/13, nor April 13, 2015. Even if you use an unambiguous alternative format it is still harder to search for a date, sort on a date, and for other team members to know we use the ISO standard. For months use yyyy-mm, so 2018-01 for January. Refer to a year with CY18 (never with 2018) and a quarter with CY18-Q1 to prevent confusion with fiscal years and quarters.
GitLab operates on a Fiscal Year offset from the calendar year. When referring to a fiscal year or quarter, please use the following abbreviations:
"FY20" is the preferred format and means: Fiscal Year 2020, the period running from February 1, 2019 through January 31, 2020
"Q1" = the first quarter of the current Fiscal Year, so on Feb 1, 2020, "Q1" is the period from Feb. 1, 2020 through April 30, 2020. Note that Epics in GitLab follow Calendar Years and Quarters.
When referring to a quarter in a future or past year, combine the two above: "FY21-Q1"
Remember that not everyone is working in the same timezone; what may be morning for you is evening for someone else. Try to say 3 hours ago or 4 hours from now, or use a timestamp, including a timezone reference.
We use UTC as the timezone for engineering (for example production postmortems) and all cross-functional activities related to the monthly release. We use Pacific Time (PT) for all other uses since we are a San Francisco-based company. Please refer to time as "9:00 Pacific" or 9:00 PT. It isn't often necessary to specify whether a timezone is currently observing Daylight Saving Time, and such references are often incorrect, so prefer "PT" to "PDT" or "PST" unless you have a specific need to differentiate between PDT and PST.
Although we're a San Francisco based company we're also an internationally diverse one. Please do not refer to team members outside the US as international, instead use non-US. Please also avoid the use of offshore/overseas to refer to non-American continents.
If you have multiple points in a comment or email, please number them. Numbered lists are easier to reference during a discussion over bulleted lists.
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 includes 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 GitLab team members 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 GitLab team members, not employees.
Always write "GitLab" with "G" and "L" capitalized, even when writing "GitLab.com", except within URLs. When "gitlab.com" is part of a URL it should be lowercase.
Write a group name as "Stage:Group" when you want to include the stage name for extra context.
Do not use a hyphen when writing the term "open source" except where doing so eliminates ambiguity or clumsiness.
Monetary amounts shouldn't have one digit, so prefer $19.90 to $19.9.
If an email needs a response, write the answer at the top of it.
Use the future version of words, just like we don't write internet with a capital letter anymore. We write frontend and webhook without a hyphen or space.
Our homepage is https://about.gitlab.com/ (with the about. and with https).
Refer to environments that are installed and run "on-premises" by the end-user as "self-managed."
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 a serial comma (a.k.a. an "Oxford comma") before the coordinating conjunction in a list of three, four, or more items.
Always use a single space between sentences rather than two.
Do not use acronyms when you can avoid them. Acronyms have the effect of excluding people from the conversation if they are not familiar with a particular term. Example: instead of MR, write merge request (MR).
If acronyms are used, expand them at least once in the conversation or document. Alternatively, link to the definition.
Many times an explanation can be aided by a visual.
Whenever presenting a diagram, we should still allow everyone to contribute.
Where possible, take advantage of the handbook's support for Mermaid. If you are new to using Mermaid or need help troubleshooting errors in your Mermaid code, the Mermaid Live Editor can be a helpful tool.
Where taking advantage of Mermaid isn't possible, link to the original in our Google Drive so that the diagram can be edited by anyone.
Mandel Communications refers to SCIPAB at the "surefire, six-step method for starting any conversation or presentation." When you only have a few minutes to present your case or grab your listener's attention, this six-step process can help you communicate better and faster.
Situation - Expresses the current state for discussion.
Complication - Summarizes the critical issues, challenges, or opportunities.
Implication - Provides insight into the consequences that will be a result of if the Complications are not addressed.
Position - Notes the presenter's opinion on the necessary changes which should be made.
Action - Defines the expectations of the target audience/listeners.
Benefit - Clearly concludes how the Position and Action sections will address the Complications.
This method can be used in presentations, emails, and everyday conversations.
Example - The Management team asking for time to resolve a problem
S - The failure rate last year for product X1 was an acceptable 1.5%.
C - Because of supply shortages in the current fiscal year we are forced to change the material of a key component.
I - Unfortunately, that resulted in the failure rate doubling this year.
P - It is critical we address this problem immediately.
A - Please approve the team 5 days to investigate the specific causes of the increase and establish the necessary next steps.
B - By doing this we will reduce the failure rate to an acceptable level and develop guidelines for preventing such problems in the future.
If you need to provide the details of GitLab's contact information you can take the address from the visiting page 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.
Organization code names
Listed in Google Sheet under 'Organization code names'
To make it easier to recognize code names we base them on classic car models.
There are two types of code names:
Don't mention publicly We can use code names anywhere we regularly share items in that medium with people outside the company: issue trackers, Group Conversations, etc. For these we don't have to use code names in things that are never published: SalesForce, Zuora, Zendesk, and verbal conversations.
Don't write down there are organizations that we shouldn't write down anywhere.
This is defined in Domain-driven design as: "A language structured around the domain model and used by all team members to connect all the activities of the team with the software."
We use it for activities in GitLab, even ones not implemented in software.
By having ubiquitous words to identify concepts we prevent confusion over what is meant, for example we refer to parts of our organization as a function, department, or group depending on exactly what is meant.
Make sure that domains don't overlap, for example organization size and deal size don't reuse words to prevent overlap.
If a term is ambiguous don't use it, for example our hiring definitions have roles and vacancies but avoid the ambiguous word job.
Make sure that people can infer as much as possible from the word, for example our subscription options allow you to know if someone if using self-managed or GitLab.com.
Make sure terms don't overlap without clearly defining how and why, for example see our tier definitions.
Keep terms to one or at most two words to prevent people from introducing ambiguity by shortening a term. When using two words make the first word unique because people tend to drop the second word more often.
MECEFU terms
MECEFU is an acronym for Mutually Exclusive Collectively Exhaustive Few words Ubiquitous-language.
You pronounce it: MessiFu. Think of the great soccer player Lionel Messi and his kung fu or soccer fu skills.
We want to use MECEFU terms to describe a domain to ensure efficient communication. MECEFU terms have 4 characteristics that help with efficiency:
Mutually Exclusive: nothing is referenced by more than one term
Collectively Exhaustive: everything is covered by one of the terms
Few words: the longer terms are the more likely it is people will not use all of them and cause confusion, avoid acronyms because they are hard to remember (we're open to a few words to replace MECEFU as an acronyms :)
Mutually Exclusive: There is no overlap between the numbers and there is a single dimension.
Collectively Exhaustive: Everything for 0 to infinite employees is covered.
Few words: Mid-market is a natural combination and SMB is abbreviated.
Ubiquitous language: We're not using the word 'Enterprise' which already can refer to our Enterprise Edition distribution.
One nit-pick is that the Medium of SMB and Mid of Mid-Market sound very similar.
Posting or Streaming to YouTube
See the Youtube page for options and instructions for posting recordings and live streaming to YouTube.
Deep Dives
As GitLab continues to grow, sharing knowledge across the community becomes even more important.
The Deep Dives page describes initiatives we are trying to encourage this.
This aligns with how we work since everything at GitLab is public by default.
.
