介绍

我们是一家全远程公司，可让人们在世界上几乎任何地方工作。我们雇用优秀人才，无论他们身在何处，但GitLab团队成员遍布60多个国家/地区，对我们而言，进行清晰的沟通以帮助我们保持联系并完成工作非常重要。为此，我们使用异步通信作为起点，并且通过公共问题，合并请求和Slack渠道进行通信，并尽可能地保持开放，并强调确保写下离线对话的结论。当我们来回三回时，我们跳到同步视频通话。
我们始终保持尊重和专业的沟通。

有效和负责任的沟通准则

  1. 假设积极意图。始终处在积极和优雅的位置。
  2. 善良事宜。您正在看屏幕，但实际上是在与人交谈。如果您不想对别人说，请不要通过短信发送给他们。
  3. 表达您的想法。我们生活在不同的位置，通常有不同的看法。我们想知道您对事物的想法，看法和感受。
  4. 拥有它。如果您说或输入，请拥有它。如果它无意间伤害了公司或个人，我们建议您从其他角度来看事情，并向您道歉。
  5. 做我们价值观的榜样。
  6. 反馈至关重要。很难知道什么适合我们60多个国家/地区的每个团队成员。我们鼓励团队成员以体贴的方式给出反馈并接收反馈。
  7. 不要小看1：1。异步交流（例如，通过文本）是有帮助且必要的。在某些情况下（例如，为了消除误解），跳转到Zoom视频通话会更加有效。
  8. 始终遵守我们的反骚扰政策和行为准则。每个人都应该在自己的工作环境中感到舒适。

拥抱文本交流并学习有效使用它需要精神上的转变。对于来自同一地点的人来说，这是不寻常的，甚至让他们感到不舒服，在这些地方，面对面的会议和发声的公报是常见的。了解有关在全远程环境中掌握书面文字用法的更多信息。

对外沟通

在任何会议上都要考虑8个关键实践。它们是：

  1. 屏幕共享-如果这是您第一次遇到客户/潜在客户/合作伙伴/等等，请在登录“缩放”时打开屏幕共享。这将有助于使客户/准客户感觉更舒适，因为他们确定您将全心投入到他们身上。
  2. 议程-始终准备好议程并准备就绪。与您的听众分享。确保议程上的所有内容都是准确的，并询问是否有任何遗漏需要在此通话期间或将来解决。没有议程时，它意味着您不在乎。
  3. 70/30规则-提出开放性问题，使听众有70％的时间说话，而您有30％的时间在说话。请注意，这取决于您进行的会议类型。注意需要问什么问题并捕获这些项目。
  4. 记笔记-有效的记笔记是一项宝贵的技能，可帮助您保留和记住任何重要细节。成为记住听众需求的所有细节的人。
  5. 适应听众的语气-在进入会议的业务部分之前，请先评估听众的语气。相应地调整您的语气，以吸引各种类型的个性。
  6. 通话中-会议进行中，与听众进行通话。询问他们对这次会议的进展有何想法，以及您的陈述是否正确。通过重新调整期望并确保会议的方向正确，这对您和观众都有帮助。
  7. 收盘前摘要-结束通话前10分钟（1小时会议）或5分钟（30分钟会议），请听众为下一步或会议制定议程。这有助于确保下一步操作并确保没有任何球掉落。
  8. 会议后动作-立即写下笔记和后续步骤，并输入到正确的目录（Google云端硬盘，Salesforce等）中。

  9. 两段式规则-对于与外部方进行的面对面会议，您应该等到会议距离两个以上以内之后再讨论会议结果。没有人希望听到自己在浴室里被讨论。

    社交媒体

    请参阅我们的社交媒体指南。

    一切始于合并请求

    最佳做法是在可能的情况下使用合并请求（MR）而不是问题开始讨论。MR与提出的特定更改相关，并且透明，所有人都可以查看和公开讨论。MR的性质促进了围绕可解决问题的提议解决方案的讨论。MR是可行的，而问题需要更长的时间才能采取行动。

  10. 始终针对您的建议和/或提议打开 MR。不管是什么工作不正常，还是我们正在迭代新的内部流程，值得以最小的可行更改来打开合并请求，而不是打开一个问题以鼓励对此问题进行公开反馈，而无需直接提出任何具体更改。记住，MR也需要引起讨论，但是它特定于建议的更改，从而有助于集中决策。

  11. 从“合并请求”开始是“ 手册第一版”的一部分，有助于确保在做出决定时手册是最新的。
  12. 合并请求默认情况下是非机密的。但是，对于默认情况下不是公开的事物，请打开一个私人问题，其中包含对您建议的特定更改的建议。还可以创建机密合并请求。如果可能，请考虑不包括敏感信息，以便更广泛的社区做出贡献。
  13. 并非每种解决方案都能解决眼前的问题。通过首先定义问题并解释 MR中提出的最小可行变更（MVC）的理由，使讨论保持重点。
  14. 积极主动并与具有外部利益相关者（例如客户）的讨论保持一致。保持沟通畅通对每个人保持最新很重要。如果没有最近的讨论，并且根据反馈没有明确何时定义另一个更新，则MR可能会显得过时。这使得那些订阅者处于黑暗中，如果某些事情最终延迟并突然跳到下一个里程碑，则会引起不必要的惊喜。重要的是，应通过批准或拒绝未解决的请求来及时关闭MR。
  15. 对行动有偏见，不要达成共识。每个MR都是一个提案，如果MR的作者不响应，则将其所有权并完成。有些进步总比没有好。
  16. 交叉链接问题或其他具有相关对话的MR。例如，如果有ZenDesk票证导致您创建了GitLab.com MR，请确保在ZenDesk票证中记录MR链接，反之亦然。在批准或拒绝MR时，请包括ZenDesk的理由或回应。将链接放在每个MR描述的顶部，并简短提及该关系（报告，相关性等），并以一个为中心，并最好将其替换（如果有重复的话）。
  17. 如果提交功能更改，请使用最终结论更新说明（为什么MR被拒绝或为什么被批准）。这使涉及实施的每个人都更容易看到问题的当前状态，并且避免了以后的混乱和讨论。
  18. 提交有意义的最小项目。提出更改时，请提交最小的合理承诺，在其他问题/ MR中提出其他增强建议，并将它们链接起来。如果您是GitLab的新手，并且正在编写文档或说明，请最多提交20行的首次合并请求。
  19. 不要将MR长时间打开。MR应该是可操作的 –利益相关者应该对更改内容以及最终批准或拒绝的内容有清晰的了解。
  20. 做出有意识的努力来优先安排工作。项目的优先级取决于多个因素：是否有人在等待答案？如果延迟，会有什么影响？它会影响多少人等？工程工作流程中对此进行了详细说明。
  21. 提交MVC时，请您的同行征求反馈。例如，如果您是设计师，并且提出了设计建议，则请Ping一位同行设计师来审查您的工作。如果他们提出更改建议，您将有机会改进设计并提出替代MR。这样可以促进协作并提高每个人的技能。
  22. 在讨论中回应评论。如果还没有讨论主题，则可以使用评论中的“ 回复评论”按钮创建一个。这样可以防止评论包含许多交织的讨论以及难以理解的回复。
  23. 如果您的评论或答案包含单独的主题，请为每个主题分别编写评论，以便其他人可以使用“ 回复评论”按钮独立处理主题。
  24. 对于GitLab，产品合并请求指南在贡献指南中，而针对审阅者和维护者的代码审阅指南在我们的代码审阅指南中进行了描述。
  25. 即使未完成，也要在内部共享，以便人们可以提早发表评论并防止返工。
  26. 创建一个进行中的（WIP）合并请求，以防止意外的早期合并。仅在合并时使用WIP 会使情况变得更糟，这在编写手册时很少发生。正在进行的大多数合并请求不会使情况变得更糟，在这种情况下，请不要使用WIP，如果有人比您期望的更早地合并它，只需为其他项目创建一个新的合并请求即可。永远不要要求某人进行最终审查或合并仍然具有WIP身份的东西，那时候您应该确信它足够好出去。
  27. 合并合并请求后，如果对问题需要采取任何后续措施（例如向任何客户报告或编写文档），请避免自动关闭问题。

  28. 如果一个项目需要多个批准才能接受您的MR，请随时同时指定多个审阅者。这样，最早可用的审阅者可以立即开始，而不会被先前的审阅者阻止。

    内部沟通

  29. 所有书面交流都以英语进行，即使是一对一地发送，也是因为有时您需要转发电子邮件或聊天。

  30. 尽可能使用异步通信：合并请求（首选）或问题。公司电话会议上发生了公告，人们应该能够做事而不会被聊天打扰。
  31. 在问题或合并请求中进行讨论比其他所有方法都更可取。如果您紧急需要响应，则可以使某人具有对您对问题或合并请求的评论的链接，要求他们在此处做出响应，但是请注意，他们仍然可能不会立即看到它。有关更多信息，请参见Slack。
  32. 如果您选择发送电子邮件而不是聊天，则可以发送仅包含短消息的内部电子邮件，类似于在聊天中使用的电子邮件。
  33. 预计您不会一直有空。在您计划的工作时间之外，不会期望对消息做出响应。
  34. 有时，同步通信是更好的选择，但不要默认使用它。例如，当您被阻止时，视频通话可以快速清除所有内容。有关更多详细信息，请参见视频聊天准则。
  35. 提出尽可能多的问题是非常好的。请问他们有多少人可以回答他们，很多人看到答案，因此请使用问题或公共聊天渠道（例如#questions），而不要使用私人消息或一对一的电子邮件。如果有人给您发送了一个手册链接，他们会为我们记录了答案而感到自豪，但这并不意味着您应该已经找到自己或这是完整的答案，请随时提出澄清。如果尚未记录问题的答案，请立即提出合并请求，将其添加到您所需要的位置的手册中。回答问题的人很高兴看到您的帮助，以确保他们只回答一次。合并请求是表示感谢的最佳方式。
  36. 如果您提及某些内容（合并请求，问题，提交，网页，评论等），请添加指向该内容的链接。
  37. 默认情况下，所有公司数据都应可共享。不要使用本地文本文件，而要对问题发表评论。
  38. 当有人问某事时，请退还一个截止日期或您已完成。诸如“将做”，“确定”，“它在我的待办事项清单上”之类的答案无济于事。如果太小，最好花2分钟时间来完成任务，以便其他人可以从心理上忘记它。如果内容太大，则需要弄清楚何时进行处理，如果返回的信息过长，则其他人可能会决定以其他方式解决该问题。
  39. 可以通过CC（“ cc @user”）引起某人的注意，但是如果需要某人采取特定的措施，仅靠CC是不够的。提到的用户可能会阅读此问题，并且不采取进一步措施。如果您需要某些东西，请明确传达您的需求，并@提及您需要的人。
  40. 避免创建私人小组进行内部讨论：
    1. 令人不安（该群组中的所有用户都会收到每条消息的通知）。
    2. 无法搜索。
    3. 这不是共享的：无法在组中添加人员（这通常会导致创建多个组）。
    4. 他们没有主题，因此每个人都必须根据参与者记住每个私人小组的主题，或者再次打开小组以阅读内容。
    5. 离开小组时，历史会丢失。
  41. 即使对于一次客户会议，创建一个渠道也很好。这些通道应命名为“ a_ <客户名称>-内部”，以指示其“内部”性质（不与客户共享）。
  42. 通过在通信中明确使用低上下文通信。我们是一家位于世界各地的远程公司。提供尽可能多的上下文以避免混淆。例如，在公司电话会议中向公司讲话时，考虑介绍您自己和您的职能，因为不是每个人都可能知道您是谁。相关地，我们使用普遍存在的语言来提高通信效率。

    在全公司范围内发布公告

    “我如何发布全公司公告？” 对于那些刚接触GitLab的人来说，这是一个常见问题。公司范围内的常见公告包括（但不限于）：策略迭代，参与调查的请求，公布下一个GitLab贡献者位置，代码库迁移，赠品和流程改进。
    应该考虑以下步骤，以确保以异步方式将消息传递给所有人。

  • 选择一个您将能够实时参加的公司电话，并将议程项目添加到日历邀请中的Google文档中。提供有关公告的书面内容，以及指向要公告或要求的内容的链接。这可能是GitLab问题，合并请求，手册页面，调查，注册门户等。下面显示一个示例。

  • 在公司电话上的口头声明之后，立即从公司电话议程Google Doc中复制书面文本，并将其粘贴到#company-announcementsSlack频道中。一个例子如下所示。

  • 可选：如果需要和适当，请提供公司范围内的Zoom呼叫以托管AMA（任何问题都可以问我）。通常，可以在GitLab问题或合并请求的“讨论”选项卡中管理问题。对于广泛的公告（例如，GitLab Contribute的注册开放），AMA可能更适合于大量查询。要安排公司范围内的通话，请在#peopleopsSlack频道中进行请求，并在邀请中包含Google文档以询问问题。

    热门滥用条款

    以下是人们在应该使用其他术语时经常使用的术语。格式为：误用术语=>正确术语，原因。

  1. IPO =>成为上市公司，因为我们可能会直接上市而不是发行股票。
  2. EE =>订户或付费用户，因为EE是发行版，并非所有使用EE的人都向我们付费。
  3. CE => Core用户，因为CE是发行版，并且许多Core用户使用EE。
  4. 大家好=>大家好，因为我们要使用包容性语言
  5. 进取=>雄心勃勃，因为我们要吸引各种各样的人
  6. 员工=>团队成员，因为我们有团队成员是承包商
  7. 资源=>人，因为我们不仅仅是产出。
  8. 社区=>更广泛的社区，因为GitLab的人员也是社区的一部分，我们应该将其视为公司之外的东西。
  9. GitLabber => GitLab团队成员，由于不应将更广泛的社区排除在GitLabber之外，因此我们改为使用团队成员。
  10. 激进的透明度=>透明度，因为激进主义往往是绝对的，我们很体贴并且有透明性的例外。
  11. Sprint =>迭代，因为我们是长期的，而sprint意味着快速，而不是快速。
  12. 显然=>跳过这个词，因为使用“显而易见/我们都知道/很清楚”之类的东西会使那些不明白的人灰心。

  13. 他们=>不要在外部将GitLab上的其他团队称为“他们”（例如，“他们还没有解决问题！”）。没有“他们”或“总部”-只有我们作为团队成员，而是一个团队。您可以改为说“产品团队正在研究该问题……”。

    问“这是已知的”

  14. 如果https://gitlab.com上的行为异常，则可能是错误。这也可能意味着有意更改了某些内容。

  15. 请搜索问题是否已经报告。
    1. 如果尚未报告，请提出问题。
  16. 如果不确定所遇到的行为是否是错误，可以在Slack频道＃is-this-known中询问。
    1. 通过检查频道是否有以前的消息来确保没有人以前遇到过此问题
    2. 如果您知道DevOps生命周期的哪个阶段受到影响，也可以在#s_ {stage}中询问，例如#s_manage。
    3. 描述您所遇到的行为，这使其易于搜索并易于理解。不同的人可能会在相同的屏幕快照中寻找不同的事物。
    4. 在单个渠道中提问有助于发现，重复工作并减少其他渠道中的噪音。请不要询问通用渠道，例如#frontend，#backend，#development或#questions。

      多模式通讯

      采用多模式通信来广播重要决策。若要联系我们的分布式组织，请在公司电话上宣布重要的决定，通过电子邮件发送相应的团队电子邮件列表，放松适当的渠道，并在同一天以相同的信息定向1：1或其他重要会议。
      执行此操作时，请创建并链接到单个事实来源：最好是手册，否则是史诗，特刊或Google文档。电子邮件或Slack消息不应成为事实来源。

      Slack

      Slack仅用于非正式交流。仅保留90天的活动。因此，Slack不应专门用于：
  • 获得批准；
  • 记录决策；
  • 存放公司的正式记录或文件；要么
  • 分享有关任何个人的个人或敏感信息

    避免私信

  1. 将Slack用于与工作相关的目的时，请避免使用私人消息。私人消息不鼓励协作。您可能实际上是在联系错误的人，他们无法轻易将您重定向到正确的人。如果此刻此人不可用，则效率会降低，因为其他人无法介入并提供帮助。使用公共频道并提及您想要联系的人或团体。这样可以确保其他人容易结识，在需要时让其他人参与并从讨论的内容中学习。
  2. 如果有人向您发送与工作相关的私人消息，可以让他们知道您想将对话带到公共渠道，并链接到手册的此部分。该过程可能类似于：
    • 在私人消息中： 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)
    • 在适当的公共频道中： @Person asked "question" in a DM, pulling that out here if anyone else has input.
    • 在该频道消息的线程中回答问题，以使其他人受益。
  3. 如果您发现自己收到许多应在公共频道上发送的私人消息，请考虑将您的Slack状态更改为吸引注意力的表情符号，并将其设置为类似以下内容：
    • Please consider posting in a public channel before direct messaging
    • Why direct message me when you can post in a public channel?
  4. 如果您必须发送与工作相关的私人消息，请不要与“ Hi”或“ Hey”开始对话，因为这会打断他们的工作，而无需进行任何交流。如果您有一个快速的问题，请直接问问题，此人将异步响应。如果您确实需要进行同步通信，则在提到主题的同时先明确要求它。例如，“我在理解问题#x时遇到问题，我们可以迅速谈谈吗？”。

  5. 不要使用群组私人消息。使用私人渠道，而不是分组私人消息。群组私人消息很难维护，跟踪和响应。首先，请考虑是否可以在公共渠道进行对话。如果没有，请改用私人频道。

    使用公共频道

  6. 如果您使用Slack并计划向3个或更多人发送消息，我们建议您使用一个渠道来处理客户/问题/项目/问题/合作伙伴关系。

  7. 了解有关常见渠道和渠道命名约定的信息。
  8. 如果重要但不紧急的事情（例如称赞或鼓励整个团队），则在不@提及团队的情况下使用电子邮件或在频道中发布。
  9. 离开频道不礼貌。当您的问题得到回答或不再感兴趣时，请随时离开频道，这样就不会再分散您的注意力了。

  10. 使用ChatBots进行集成有时可能取决于渠道的名称。在更改常用/常用频道的名称之前，应咨询有关此类集成的渠道，以避免无意间破坏集成。

    尊重别人的时间

  11. 如果您仅指的是某人，但实际上并不需要他们的注意，并且想使他们免于受到通知，请正常说出他们的名字而无需@提及他们。

  12. 松弛消息应被视为异步通信，并且您不应期望即时响应。你不知道对方在做什么。
  13. 由于我们在全球开展业务，因此您可能会在一天中的任何时候收到Slack的提及。请考虑启用Slack的“请勿打扰”功能，以免打扰您，例如在下班时间。
  14. Slack当前不支持在周末自动激活“请勿打扰”。如果您选择在周末工作，请记住这一点，因为向某人发送的Slack消息可能会打扰他们的休息时间。考虑改用另一种通讯方式。
  15. 当您不工作时，不要觉得有义务响应Slack消息。
  16. 如果Slack中的通信应该异步进行，请随时向同事发送指向这些准则的链接。
  17. 请避免使用@here或@channel，除非这是紧急和重要的事情。在聊天中，请尽量减少提及整个频道的关键字的使用。它们仅应用于紧急且重要的ping，而不仅仅是重要的。通过过度使用频道提及，您会变得难以及时回应个人提及，因为人们经常会ping通。另外，如果您打算组成@mention一个特定的团队（Slack用户组），请考虑您要提及的组的大小（请参阅组成员），以及在特定情况下对所有这些人员执行ping操作的影响。如果有紧急和重要的事情：
    • 使用@here到所有当前通知活跃在房间里的成员。仅@here在消息很重要且紧急时使用。
    • 使用@channel通知所有在房间里的成员，不论离开状态。仅@channel在消息很重要且紧急时使用。

  18. 如果您知道队友正在休假，请避免在高流量频道中提及他们。当他们返回时，将很难找到信息或问题。如果需要确保它们返回到线程，请确保通过直接消息向他们发送指向相关Slack消息的链接。

    一般准则

  19. 如果该主题对更广泛的社区有价值，请考虑对现有问题发表评论，或者开放一个新问题。

  20. 使用:white_check_mark:表情符号或类似符号表示已回答查询。任何人都可以添加表情符号。如果您不确定，请随时将其留给提出要求的人。表情符号指示器在发布许多问题的渠道（例如#questions和）中特别有用#git-help。
  21. 总的来说，您可以将表情符号反应等同于我们在现实生活中使用的肢体语言反应，例如，当口头（或以松弛状态，书面）反应过多时，点头以鼓励。
  22. 在公共渠道中，线程对于将对话保持在一起非常有用。如果您想在频道中回答问题或评论，请启动话题，而不是在频道下方对其进行回复。这有助于将讨论保持在易于跟踪的地方，并减少噪音，因为线程中的每条消息不会导致频道中所有人的未读消息。
  23. 除非您处于活跃的聊天状态，否则请勿将主题分解为多条消息，因为每条消息都会导致通知的发送，可能会造成干扰。如果您想为您发布的问题/评论提供更多信息，请使用主题。
  24. 如果您在跟上消息时遇到麻烦，可以更新您的首选项以让Slack通过电子邮件发送所有通知。要更改设置，请转到Preferences > Notifications > When I'm not active on desktop...并“向我发送电子邮件通知”。
  25. 如果您同意发起视频通话的消息（通常是通过询问“通话？”），则没有留下最后评论的人将开始通话。因此，要么响应“呼叫”？要求提供视频链接或说“是”，然后让其他人开始。不要说“是”并在5秒钟后开始通话，因为您可能都将同时创建一个视频通话链接。
  26. 作为Slack工作区的管理员，如果从邮件中删除附件时，如果为“禁用此网站上的将来的附件”选项提供了选项，则此链接/域将在整个Slack工作区中展开时将其列入黑名单。选择此选项时请小心谨慎，因为它会影响工作区中的每个用户。
  27. 在GitLab.com问题中引用Slack线程时，不要仅链接到该线程。GitLab组织外部的人员不仅无法访问内容，而且链接在Slack保留期到期后也会过期。代替：
    1. 发布前，请查看内容的内容以确保用户，客户或任何其他敏感信息的机密性。
    2. 使用blockquote格式将线程的相关部分复制并粘贴到问题中。
    3. 链接到Slack线程，并(internal)在链接之后包含。例如：https://gitlab.slack.com/archives/C0AR2KW4B/p1555347101079800（内部）
    4. 在Slack线程中发布指向问题注释的链接，以使其他人知道讨论已移至问题。
  28. 选择您的Slack显示名称时，请不要用大写字母写上您的名字，因为在书面交流中，这通常会大喊大叫。

    与电子小组联系

    要与Slack上的e-group联系，您可以使用以下渠道。如有疑问，您可以使用常规#e-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

紧急聊天

Slack Down

  1. 使用“Slack Down！” 在Zoom上进行群聊。

    1. 在Zoom桌面应用中，转到“ 联系人”选项卡
    2. 请点击 +
    3. 点击“加入频道”
    4. 搜索“放松下来！”
    5. 点击“加入”

      松弛和缩放降低

  2. 加入Slack Down！聊天室聊天。

重要信息：恢复服务后，请返回Slack。

用户交流准则

  1. 在增加价值的同时，保持对话积极，友好，真实和富有成效。
  2. 如果您输入有误，请承认。事前准备并迅速进行纠正。如果您要发布到博客，则可以选择修改先前的帖子。只需明确说明您已这样做。
  3. 在健康的辩论与煽动性的反应之间可能存在细微的界限。尝试构架您所写的内容，以邀请不同的观点，而不会激怒他人。您无需回应所有批评或倒钩。要小心和体贴。
  4. 假设积极的意图，并在回答之前明确陈述某人所说的最合理的解释，而不是较容易批评的较弱的解释。Rapoport的规则还恳请您列出协议要点，并提及您学到的任何东西。
  5. 回答问题，即使只是几句话，也要感谢别人。进行双向对话。
  6. 欣赏建议和反馈。
  7. 不要做出无法维持的承诺。
  8. 指导寻求帮助或提出建议的用户并共享链接。提升开放开发为大家，请求的类型。
  9. 当面对负面评论，耐心回应并将每个用户视为一个个体时，拥有最强见解的人可以成为最坚强的支持者。

  10. 在所有沟通中都遵守行为准则。同样，当与GitLab团队和其他GitLab社区进行交流时，希望用户遵循相同的代码。没有人应该接受虐待。

    写作风格准则

  11. 在GitLab，我们使用美式英语作为标准书面语言。

  12. 不要使用富文本格式，这会使复制/粘贴变得困难。使用Markdown格式化存储在Git存储库中的文本。在Google文档中，使用样式/标题/格式下拉菜单中的“普通文本”，然后粘贴而不设置格式。
  13. 不要使用ALL CAPS，因为感觉就像大喊大叫。
  14. 我们使用Unix风格（lf）的行尾，而不是Windows风格（crlf）的行尾，请确保*.md text eol=lf已在存储库中设置.gitattributes并git config --global core.autocrlf input在您的客户端上运行。
  15. 始终在一行上写一个段落。使用软中断（“自动换行”）以提高可读性。不要以一定的字符数限制（例如80个字符）硬性返回，也不要将您的IDE设置为自动插入硬性中断。插入硬中断后，很难编辑博客和手册的合并请求。
  16. 请勿创建“此处”或“单击此处”之类的链接。所有链接都应具有描述其链接内容的相关锚文本，例如：“ GitLab CI源安装文档”。使用有意义的链接对于搜索引擎搜寻器（SEO）和具有可访问性问题的人员而言都很重要。无论在手册，网站，GoogleDocs或任何其他内容中，提供链接的所有位置均应遵循本指南。避免编写状态为-的GoogleDocs内容Zoom Link [Link]。而是在单词后面直接粘贴完整链接Zoom。这使链接更加突出，并且在查看文档时更易于跟踪。
  17. 始终在所有书面和法律文档中使用ISO日期，因为其他格式会导致在线混乱。请使用yyyy-mm-dd，例如2015-04-13，并且永远不要使用04-13-2015、13-04-2015、2015 / 04/13或2015年4月13日。即使您使用明确的替代格式，也仍然很难搜索日期，对日期进行排序，让其他团队成员知道我们使用ISO标准。使用几个月yyyy-mm，因此1月为2018-01。指的是CY18的一年（从2018年起）和CY18-Q1的四分之一，以防止与会计年度和季度混淆。
  18. GitLab的会计年度与日历年相抵。在指一个会计年度或季度时，请使用以下缩写：
    1. “ FY20”是首选格式，其含义是：2020会计年度，该期间为2019年2月1日至2020年1月31日
    2. “ Q1” =当前会计年度的第一季度，因此在2020年2月1日，“ Q1”是从2020年2月1日到2020年4月30日的期间。请注意，GitLab中的Epics遵循日历年和季度。
    3. 当提及未来或过去一年的一个季度时，请结合以上两项：“ FY21-Q1”
  19. 请记住，并非每个人都在同一时区工作；对您而言，早上可能是别人的夜晚。尝试说3个小时前或4个小时后说，或使用时间戳记，包括时区参考。
  20. 我们将UTC用作工程（例如生产验尸）和与月度发布相关的所有跨职能活动的时区。由于我们是一家位于旧金山的公司，因此我们将太平洋时间（PT）用于所有其他用途。请将时间称为“太平洋时间9:00”或9:00 PT。不必经常指定时区当前是否正在遵守夏时制，并且此类引用通常是不正确的，因此，除非您特别需要区分PDT和PST，否则最好将“ PT”改为“ PDT”或“ PST” 。
  21. 尽管我们是一家位于旧金山的公司，但我们还是一家国际多元化的公司。请不要将美国以外的团队成员称为国际成员，而要使用非美国的成员。还请避免使用离岸/海外来指非美洲大陆。
  22. 如果您在评论或电子邮件中有多个要点，请给它们编号。在项目符号列表的讨论中，编号列表更易于引用。
  23. 当您引用问题时，请合并请求，评论，提交，页面，文档等，并且您拥有可用的URL，请将其粘贴。
  24. 在制作URL时，请始终使用连字符而不是下划线，并始终使用小写字母。
  25. 社区包括用户，贡献者，核心团队成员，客户，在GitLab Inc.工作的人员以及GitLab的朋友。如果要引用“不为GitLab Inc工作的人”。只是这样说，不要使用社区一词。如果您想提及为GitLab Inc.工作的人，您也可以使用“ GitLab Inc.团队”，但不要使用“ GitLab Inc.员工”。
  26. 当我们提及GitLab社区（不包括GitLab团队成员）时，请说“更广泛的社区”，而不是“社区”。
  27. 在GitLab（公司）工作的所有人员都是GitLab团队。我们还有由志愿者组成的核心团队。
  28. 请始终将GitLab Inc.人员称为GitLab团队成员，而不是员工。
  29. 在所有写作中都使用包容性和性别中立的语言。
  30. 即使在编写“ GitLab.com”时，也要始终用大写的“ G”和“ L”大写“ GitLab”，URL中除外。如果“ gitlab.com”是URL的一部分，则应小写。
  31. 始终使用大写的GitLab产品名称，产品层和功能。
  32. 当您想要包括舞台名称以获得额外的上下文时，将组名称写为“ Stage：Group”。
  33. 编写“开源”一词时，请勿使用连字符，除非这样做可以消除歧义或笨拙。
  34. 货币金额不应有一位数字，因此建议将19.90美元换成19.9美元。
  35. 如果电子邮件需要回复，请在其顶部写下答案。
  36. 使用未来的单词版本，就像我们不再使用大写字母写互联网一样。我们编写的前端和webhook没有连字符或空格。
  37. 我们的主页是https://about.gitlab.com/（带有`about.`和，带有`https`）。
  38. 尽可能尝试使用主动语音。
  39. 将最终用户“本地”安装并运行的环境称为“自我管理”。
  40. 如果您使用标题，请正确格式化##标题（在Markdown中，Google文档中的“标题2”）；从第二个标题级别开始，因为标题级别1用于标题。标题不要以冒号结尾。
  41. 始终在三个，四个或更多项目的列表中使用协调逗号之前，请始终使用串行逗号（也称为“牛津逗号”）。
  42. 句子之间始终使用单个空格，而不是两个。
  43. 在编写文档时，请阅读我们的文档样式指南以获取更多信息。
  44. 当您可以避免使用首字母缩略词时，因为您无法假设别人知道您在说什么。例子：代替MR，写merge request。
  45. 我们将客户/潜在客户细分为战略，大型，中型市场和中小型企业（SMB）的四个部分。