Contribute to GitLab

原文：https://docs.gitlab.com/ee/development/contributing/

Contribute to GitLab

感谢您有兴趣为 GitLab 做贡献. 本指南详细介绍了如何以每个人都容易的方式为 GitLab 做出贡献.

For a first-time step-by-step guide to the contribution process, see our Contributing to GitLab page.

寻找工作吗？ 有关更多信息，请参见如何贡献部分.

GitLab 有两种口味：

  • GitLab 社区版（CE），我们的免费和开源版本.
  • GitLab 企业版（EE），这是我们的商业版.

在本指南中，您将看到对 CE 和 EE 的缩写的引用.

要获得 GitLab 社区成员资格的概述，包括那些会审核或合并您的贡献的成员，请访问社区角色页面 .

如果您想知道 GitLab 核心团队的运作方式，请参阅GitLab 贡献过程 .

GitLab Inc 工程师应参考工程工作流程文档 .

Security vulnerability disclosure

将可疑的安全漏洞秘密报告给support@gitlab.com ，另请参阅GitLab.com 网站上的 “ 披露”部分 .

危险： 不要为疑似安全漏洞公开可见的问题.

Code of conduct

我们希望为每个有志于贡献的人营造一个温馨的环境. 请访问我们的《行为准则》页面，以了解有关我们对开放友好环境的承诺的更多信息.

Closing policy for issues and merge requests

GitLab 是一个受欢迎的开源项目，处理问题和合并请求的能力有限. 出于对我们志愿者的尊重，不符合本文档所列准则的问题和合并请求可能会被关闭，恕不另行通知.

以礼貌和尊重的态度对待我们的志愿者，这将大大有助于您解决问题.

发行和合并请求应使用英语，并包含适合所有年龄段受众的语言.

如果贡献者不再主动处理提交的合并请求，我们可以：

我们根据更改对我们的产品愿景的重要性来做出此决定. 如果合并请求教练将要完成合并请求，我们指定~coach will finish标签.

当团队成员选择社区贡献时，我们会通过添加一个记入作者的更改日志条目来记入原始作者，并有选择地将原始作者包括在 MR 中的至少一项提交中.

Helping others

可以的话，请帮助其他 GitLab 用户. 人们用于寻求帮助的方法可以在” 获得帮助”页面上找到.

注册邮件列表，在 StackOverflow 上回答 GitLab 问题，或在 IRC 频道中回复.

How to contribute

如果您想为 GitLab 做出贡献：

如果您有任何疑问或需要帮助，请访问” 获得帮助”以了解如何与 GitLab 进行通信. 我们有一个供参与者使用的Gitter 通道 ，但是相对于实时通信，我们更喜欢异步通信.

感谢您的贡献！

GitLab Development Kit

GitLab 开发套件（GDK）可帮助贡献者使用所有必需的依赖项来运行本地 GitLab 实例. 在提出合并请求之前，它可以用于测试对 GitLab 和相关项目的更改.

有关更多信息，请参见gitlab-development-kit项目.

Contribution flow

对 GitLab 进行贡献的一般流程是：

  1. 创建一个 GitLab 的叉子 . 在某些情况下，您将需要设置GitLab 开发套件以针对 fork进行开发 .
  2. 在叉子上进行更改.
  3. 准备就绪后， 创建一个新的合并请求 .
  4. 在合并请求的描述中：
    • 确保您提供完整而准确的信息.
    • 查看提供的清单.
  5. 将合并请求（如果可能）分配给相关项目的代码所有者之一或@mention ，并说明您已准备好进行审查.

当您向 GitLab 提交代码时，我们真的希望它被合并！ 但是，我们始终会仔细审查提交的内容，这需要时间. 合并之前，代码提交通常会由两位领域专家进行审核：

提交合并请求时，请牢记以下几点：

  • 当审阅者阅读合并请求时，他们可能会要求其他审阅者提供指导.
  • 如果发现代码质量不符合 GitLab 的标准，则合并请求审阅者将提供指导，并将作者推荐给我们：
    • 文档样式指南.
    • 代码样式指南.
  • 有时会遵循样式指南，但是代码将缺乏结构完整性，或者审阅者会对​​代码的整体质量有所保留. 如有保留，审阅者将通知作者并提供一些指导.
  • 尽管 GitLab 通常允许任何人表明对合并请求的批准 ，但是维护者在合并合并请求之前可能需要获得某些审阅者的批准 .
  • 审核后，可能会要求作者更新合并请求. 合并请求更新并重新分配给审阅者后，他们将再次审阅代码. 在合并之前，此过程可以重复任意次数，以帮助做出最佳的贡献.

有时，维护者可能会选择关闭合并请求. 他们将充分披露为什么不合并的原因以及一些指导. 维护人员将公开讨论如何更改代码，以便将来可以批准和合并.

manbetx 客户端打不开将尽其所能尽快审查社区贡献. 专门任命的开发人员每天审查社区贡献. 在团队页面上查看合并请求指导者，他专门研究您编写的代码类型，并在合并请求中提及他们. 例如，如果您编写了一些前端代码，则应@mention前端合并请求指导程序. 如果您的代码具有多个学科，则可以@mention多个合并请求指导.

GitLab 收到了很多社区的贡献. 如果您的代码在其初次提交后的两个工作日内仍未得到审查，请@mention与@gitlab-org/coaches合并的所有请求@gitlab-org/coaches引起他们的注意.

在向 GitLab 提交代码时，您可能会觉得您的贡献需要外部库的帮助. 如果您的代码包含外部库，请提供该库的链接，以及包含该库的原因.

@mention维护者在合并请求中包含：

  • 超过 500 种变化.
  • 任何重大变化.
  • 外部库.

如果您不确定要提及谁，则审阅者将在合并请求过程的早期为您完成此操作.

Issues workflow

This documentation outlines the current issue workflow:

Merge requests workflow

本文档概述了当前的合并请求过程.

Style guides

本文档概述了当前的样式准则.

Implement design & UI elements

本设计文档概述了实现设计和 UI 元素的当前过程.

Contribute documentation

有关如何编写文档的信息，请参见 GitLab 文档指南 .

Getting an Enterprise Edition License

如果您需要用于贡献 EE 功能的许可证，请参阅相关信息 .