前几日，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 等。
====================================分割线================================
文章转载自 开源中国社区[http://www.oschina.net]