Introduction

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 that helps us stay connected and get things done. For this, we use asynchronous communication as a start and are as open as we can be by communicating through public issues, merge requests, and Slack channels, and placing 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 Communciation Guidelines

  1. Assume Positive Intent. Always being with a position of positivity and grace.
  2. Kindness Matters. You are looking at a screen, but you are really talking to a person. If you wouldn’t say to to a person’s face, don’t send it to them in a text message.
  3. 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.
  4. 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.
  5. Be a Role Model of our Values.
  6. 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.
  7. Don’t Underestimate a 1:1. Asynchonchrous 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.
  8. Always Adhere to our Anti-Harassment Policy and Code of Conduct. Everyone should be comfortable in their work environment.

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.

External communication

There are 8 key practices to consider during any meeting. They are the following:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Post Meeting Action - Immediately write down notes and next steps and input into proper directory (Google Drive, Salesforce, etc.).

  9. 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.

    Social Media

    Please see our social media guidelines.

    Everything starts with a Merge Request

    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.

  10. 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.

  11. Starting with a Merge Request is part of Handbook First and helps ensure the handbook is up-to-date when a decision is made.
  12. Merge Requests, by default are non-confidential. However, for things that are not public by default please open a private 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. Even when something is not done, share it internally so people can comment early and prevent rework.
  26. 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.
  27. 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.

  28. 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.

    Internal Communication

  29. All written communication happens in English, even when sent one on one, because sometimes you need to forward an email or chat.

  30. Use asynchronous communication when possible: merge requests (preferred) or issues. Announcements happen on the company call agenda and people should be able to do their work without getting interrupted by chat.
  31. 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.
  32. 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.
  33. You are not expected to be available all the time. There is no expectation to respond to messages outside of your planned working hours.
  34. 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.
  35. 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.
  36. If you mention something (a merge request, issue, commit, webpage, comment, etc.) please include a link to it.
  37. All company data should be shareable by default. Don’t use a local text file but rather leave comments on an issue.
  38. 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.
  39. 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.
  40. Avoid creating private groups for internal discussions:
    1. It’s disturbing (all users in the group get notified for each message).
    2. It’s not searchable.
    3. It’s not shareable: there is no way to add people in the group (and this often leads to multiple groups creation).
    4. 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.
    5. History is lost when leaving the group.
  41. It is perfectly fine to create a channel, even for a single customer meeting. These channels should be named “a_-internal” to indicate their “internal” nature (not shared with customers).
  42. 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.

  1. IPO => becoming a public company, because we might do a direct listing instead of an offering.
  2. EE => subscribers or paid users, because EE is a distribution and not all people who use EE pay us.
  3. CE => Core users, since CE is a distribution and many Core users use EE.
  4. Hi guys => Hi people, because we want to use inclusive language
  5. Aggressive => ambitious, since we we want to attract a diverse set of people
  6. Employees => team members, since we have team members who are contractors
  7. Resources => people, since we are more than just our output.
  8. Community => wider community, since people at GitLab are part of the community too and we should see it as something outside the company.
  9. GitLabber => GitLab team member, since the wider community shouldn’t be excluded from being a GitLabber, we use team member instead.
  10. Radical transparency => Transparency, since radical tends to be absolute and we are thoughtful and have exceptions to transparency.
  11. Sprint => iteration, since we are in it for the long-term and sprint implies fast, not quick.
  12. Obviously => skip this word, since using things like “obvious/as we all know/clearly” discourages people who don’t understand from asking for clarification.

  13. 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…”

    Asking “is this known”

  14. If something is behaving strangely on https://gitlab.com, it might be a bug. It could also mean that something was changed intentionally.

  15. Please search if the issue has alreadybeen reported.
    1. If it has not been reported, please file an issue.
  16. If you are unsure whether the behavior you experience is a bug, you may ask in the Slack channel#is-this-known.
    1. Make sure that no-one has experienced this issue before, by checking the channel for previous messages
    2. If you know which stage of the DevOps lifecycle is affected, it is also okay to ask in #s_{stage}, for example #s_manage.
    3. 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.
    4. 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.

      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

  1. 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.
  2. 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.
  3. 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?
  4. 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?”.

  5. 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.

    Use Public Channels

  6. If you use Slack and plan to message 3 or more people, we recommend a channel for customer/issue/project/problem/partnership.

  7. Learn about common channels and channel-naming conventions.
  8. 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.
  9. 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.

  10. 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

  11. 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.

  12. 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.
  13. 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.
  14. 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.
  15. Do not feel obligated to respond to Slack messages when you are not working.
  16. Feel free to send a colleague a link to these guidelines if the communication in Slack should be done asynchronously.
  17. 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@mentiona 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.

  18. 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

  19. If the subject is of value to the wider community, consider commenting on an existing issue or opening a new issueinstead.

  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.”
  25. 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.
  26. 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.
  27. 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:
    1. Review the contents for confidentiality of users, customers, or any other sensitive information before posting.
    2. Copy and paste the relevant parts of the thread into the issue using blockquote formatting.
    3. Link to the Slack thread and include (internal) after the link. For example: https://gitlab.slack.com/archives/C0AR2KW4B/p1555347101079800 (internal)
    4. Post a link to the issue note in the Slack thread to let others know that discussion has moved to the issue.
  28. 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

Emergency Chat

Slack is down

  1. Use the “Slack Down!” group chat on Zoom.

    1. In the Zoom desktop app go to the Contacts tab
    2. Click +
    3. Click “Join a Channel”
    4. Search “Slack down!”
    5. Click “Join”

      Slack and Zoom are down

  2. Join the Slack Down! room on Hangouts Chat

IMPORTANT: Once service is restored, go back to Slack.

User Communication Guidelines

  1. Keep conversations positive, friendly, real, and productive while adding value.
  2. 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.
  3. 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.
  4. Assume positive intent and explicitly state the strongest plausible interpretation of what someone says before your 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.
  5. Answer questions, thank people even if it’s just a few words. Make it a two way conversation.
  6. Appreciate suggestions and feedback.
  7. Don’t make promises that you can’t keep.
  8. Guide users who ask for help or give a suggestion and share links. Improving Open Development for Everyone, Types of requests.
  9. When facing negative comment, respond patiently and treat every user as an individual, people with the strongest opinions can turn into the strongest supporters.

  10. 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

  11. At GitLab, we use American English as the standard written language.

  12. 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.
  13. Don’t use ALL CAPS because it feels like shouting.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. GitLab operates on aFiscal Yearoffset from the calendar year. When referring to a fiscal year or quarter, please use the following abbreviations:
    1. “FY20” is the preferred format and means: Fiscal Year 2020, the period running from February 1, 2019 through January 31, 2020
    2. “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.
    3. When referring to a quarter in a future or past year, combine the two above: “FY21-Q1”
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. When you reference an issue, merge request, comment, commit, page, doc, etc. and you have the URL available please paste that in.
  24. In making URLs, always prefer hyphens to underscores, and always use lowercase.
  25. 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”.
  26. When we refer to the GitLab community excluding GitLab team members please say “wider community” instead of “community”.
  27. All people working for GitLab (the company) are the GitLab team. We also have the Core team that consists of volunteers.
  28. Please always refer to GitLab Inc. people as GitLab team members, not employees.
  29. Use inclusive and gender-neutral language in all writing.
  30. 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.
  31. Always capitalize the names of GitLab products, product tiers, and features.
  32. Write a group name as “Stage:Group” when you want to include the stage name for extra context.
  33. Do not use a hyphen when writing the term “open source” except where doing so eliminates ambiguity or clumsiness.
  34. Monetary amounts shouldn’t have one digit, so prefer $19.90 to $19.9.
  35. If an email needs a response, write the answer at the top of it.
  36. 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.
  37. Our homepage is https://about.gitlab.com/ (with the about. and with https).
  38. Try to use the active voice whenever possible.
  39. Refer to environments that are installed and run “on-premises” by the end-user as “self-managed.”
  40. 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.
  41. Always use a serial comma (a.k.a. an “Oxford comma”) before the coordinating conjunction in a list of three, four, or more items.
  42. Always use a single space between sentences rather than two.
  43. Read our Documentation Styleguide for more information when writing documentation.
  44. Do not use acronyms when you can avoid it as you can’t assume people know what you are talking about. Example: instead of MR, write merge request.
  45. We segment our customers/prospects into 4 segments Strategic, Large, Mid-Market, and Small Medium Business (SMB).