GitLab 致开源项目维护者的一封信

前几日，GitHub 上一些流行的开源项目维护者联合签署了一篇名为“亲爱的，GitHub”的公开信，表达了对 GitHub 某些行为的不满之情。

接下来，GitLab 官方也发出了自己的声音。他们在自己的博客上表达了希望 GitLab 成为任何软件项目的最佳托管场所的愿景，无论开源与否，无论项目规模是怎样的，他们都希望 GitLab 能在这个过程中助广大开发者一臂之力。

GitLab 官方表示，虽然 GitHub 开源社区联合签署的公开信并不是针对于自己，但他们还是对这封公开信中所提及的问题进行了深入的思考。最后，GitLab 希望能与广大开发者分享他们的一些想法，以及为了让 GitLab 变得更好而做出的努力。

主要的问题

在记录 Issue 时常常会丢掉诸如重现步骤或是测试的版本等相关的重要信息。我们希望 Issue 能够拥有一些自定义字段，同时还能提供一种机制（比如说强制性的 Issue 模板，这也许可以通过在项目根目录下的 newissue.md 文件来实现，这也是个简单的解决方案）来确保每个 Issue 都能如此。

在 GitLab 中，你可以对 Issue 与合并请求设定模板。我们还计划添加多个模板，这样使用者就可以根据需要进行选择了。此外，GitLab 还对自定义字段表示出了兴趣。对于模板使用 new_issue.md 文件是个好想法，我们也很乐意讨论这个问题。

Issue 通常伴随着毫无内容的“+1”评论，这只会不断困扰项目维护者以及其他订阅了这个 Issue 的人。这些 +1 对于让维护者知晓这个 Issue 的影响范围有多么广是很有意义的，不过其缺点也是显而易见的。我们希望 Issue 能有一个不错的投票系统，对于那些诸如“+1”或是“me too”等无内容的评论会触发一个警告，并给出相应的指示告诉大家该如何使用投票机制。

GitLab 目前有一个投票系统，它会自动将 +1 转换为一个投票。在我们自己使用 GitLab 作为问题追踪或是特性投票功能时，这对于我们来说是个优先级很高的事情。我们还计划对投票进行一些改进，这里也欢迎大家提出更多有价值的想法以及合并请求。

很多时候，人们在创建 Issue 与 Pull Request 时并未遵守 CONTRIBUTING.md 贡献指南，这是由于在创建 Issue 时，“贡献指南”并不起眼所导致的，同时也与该指南包含了大量与 Issue 并不相关的信息有关（比如说关于如何 Hack 项目的信息等）。维护者应该能在仓库中配置一个文件，该文件显示在新的 Issue/PR 页面的顶层位置而不是一个链接的形式。维护者可以选择在里面插入内容，当然也可以在必要时使用指向其他页面的链接。

目前，我们提供了对 CONTRIBUTING.md 的链接，你可以在创建 Issue 与合并请求时使用。还可以使用 Issue 模板告知人们具体的规则。我们对于在 GitLab 中为 Issue 添加自定义的贡献文件很感兴趣。

对于具体建议的响应

在“亲爱的，GitHub”的公开信中包含了长长的建议列表。若想了解我们对于每个建议的回应，请在 GitLab.com 上查看。其中有一个 Issue 被反复提起多次，那就是无法创建合并提交。在 GitLab 中，你可以使用快进合并或是对合并请求进行变基来间接实现合并提交。

我们是如何构建 GitLab 的

GitLab 的构建是开放的。我们对 GitLab 变化的决策、疑虑、争论与新特性等等都可以在我们的仓库中看到（主要是 GitLab CE 与 GitLab EE）。每个人都可以自由地提交、创建新 Issue、投票以及对 GitLab 的开发做出贡献。我们有着短期与长期的目标，这些目标都可以在仓库的 Issue 中与网站的页面上看到。如果想要改变某些东西，请创建 Issue 或是提交合并请求。你可以选择自己实现，也可以让其他人帮你做。好的想法总会得到人们的关注。

GitLab 的这份声明发出后，很快就在国外各大社区中引起了人们的广泛关注，也有很多人表达了自己的看法。

Mdw 说到：

我最近在 GitLab 上创建了一个 iOS App，GitLab 的工程师的表现让我感到震惊，他们很快就对我所提交的 Issue 作出了响应，并且每次发布时都改进了 API，我真的没有想到他们能做到如此之好的程度。GitLab 有一点做得特别好，那就是每个月的 22 号都会有一个发布，因此你可以进行持续的改进。如果你认为 GitLab 不适合于你的开源项目，那你也可以在其 Issue 追踪器上与 GitLab 团队好好聊聊，问题很快就会得到解决！

lexicality 说到：

在过去一年多的时间内，我们一直在组织内部使用 GitLab CE。我们需要一个 on-premises 解决方案，这是公司的策略所决定的。到目前为止，体验是非常棒的。在 EE 中，我们所需要的一切都在，我们最终也选择了 EE。我们还有专门的 dev-ops。此外，EE 的价格相比于 GitHub Enterprise 来说也是很给力的。从我个人角度来说，我认为 GitLab 做得非常不错。

akerro 说到：

我所在的公司有将近 300 名开发者，准备在未来的几个月内迁移到 GitLab 上。今天，公司的 CTO/PM 向我们分享了他们对于 GitLab 的看法，他们觉得我们的做法是非常正确的。我是 GitLab 的老用户了，使用 GitLab 也有好几年的时间。从我个人的角度来说，我喜欢 GitLab 要胜于 GitHub，其中一个重要的原因就是我担心 GitHub 有太多的项目，对 OSS 控制得过多。此外，我也不喜欢他们的 CoS。GitLab，好运，我看好你！

关于 GitLab

GitLab 包括 Git 仓库管理、代码审查、问题跟踪、Wiki 等功能。GitLab 搭配 GitLab CI，能更简单地实现持续集成和自动部署。目前的 GitLab 提供了社区版（CE）与企业版（EE）。社区版可从网络免费下载并且是开源产品，它出自一个由 700 多人组成的社区。企业版提供订阅服务，并且更深层次地集成了 LDAP/AD、Jira 与 Jenkins 等。