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 功能的许可证,请参阅相关信息 .