GitLab 的开放文化是其最强大的优势之一，也是我在 DevOps 转型中使用 GitLab 的主要原因。社区版的代码是开源的，付费版则使其源代码可供贡献。 这些都是有价值的因素，根植于公司文化，其首席执行官多年来一直在认真维护。 它的工具也很棒，这也没有什么坏处。
我相信 GitLab 的销售和营销团队是所有公司中最好的。 在过去的几年里，他们把我当成用户、客户和朋友，他们是真诚和关心他人的人。 去年，当我想要贡献一个功能时，GitLab 的团队竭尽全力帮助我成功，这一点得到了强调。 这是我为 GitLab 做出第一个贡献的故事。
开始方式
在审查我们的应用程序代码时，全国保险专员协会 (NAIC) 发现许多应用程序要么没有包含我们的许可证，要么许可证已不再有效。 我们需要让公司中的每个人都能轻松访问我们的专有代码许可证，并提供审计功能以确保它们都保持最新。
所以，我在 GitLab issues 中搜索了一些相关的东西。 我发现了一个相关的 issue，它已经存在几年了，看起来不会很快被处理。 我向我们的 GitLab 客户经理 Joe Drumtra 提到，我想贡献这个功能，他非常兴奋。
Joe 立即安排时间让我与该团队的产品负责人 James Ramsay 和首席工程师 Douwe Maan 交谈。 他还将我添加到了他们的 Slack 频道中，以便更好地协作。 在我提到我们想要做出贡献一周后，我们举行了第一次会议。
我们的第一次会议
来自 NAIC 的 Aaron Blythe 与我一起参加了与 GitLab 的 James 和 Douwe 的第一次电话会议。 他们用 Zoom 录制了我们的第一次对话，并在 之后公开分享了它。 他们还在 Slack 频道中发布了后续内容，详细说明了我们讨论的内容。
在第一次电话会议中，James 向我们介绍了许可证在我们即将修改的版本中的工作方式，然后我们讨论了我们想要实现的功能的愿景。 这是为了确保我们都在同一页面上，并且每个人都了解发生了什么。 这对 Aaron 和我来说真的很有帮助，这样我们就可以在编写新功能时回顾一下。
他们还请来了一位设计师 Sarah Vesselov，以确保用户体验是正确的。 他们正在迁移到一个新的外观，我们将在那里工作，所以我们的时间安排将成为一个问题。 Sarah 还为结果制作了一些很棒的模型，并将它们发布在 GitLab issue 上。
在通话过程中，Douwe 引导 Aaron 和我了解 Ruby on Rails 代码，并进行了一些初步的更改。 他是一位经验丰富的指南，让我们更熟悉代码，向我们展示我们可能需要更改的部分，并帮助我们避免一些陷阱。 感谢他详尽的解释，我们仅仅在一个小时内就完成了许多工作。
在查看代码后，我感到有些紧张。 就在几年前，我每天都在编写 Ruby，而且这些都不是简单的脚本。 我正在为具有竞争条件和功能的复杂系统做出贡献，例如创建任务的有向无环图并执行它们。 然而，这些都不是在 Ruby on Rails 中，而且 Ruby on Rails 看起来几乎不像我记忆中的 Ruby。
（真正）开源编程
Aaron 和我决定在我们的 DevOps KC YouTube 频道上直播我们的工作。 我们进行了两次直播，每次两个小时，我们两人一起结对编程。 在 第一次直播之前，我们做了一些准备工作，主要只是四处看看并试图理解代码。
我们开始了第一次直播，简要回顾了 issue。 我有点挣扎，不知道如何使用 Google Hangouts。 （事实上，整个直播可能证明我需要从我说我懂的语言中删除 Ruby，而且我可能甚至不太了解技术。） 大部分时间，我们都在摸索着测试不同的解决方案，希望其中一个能奏效。 大多数人只是称之为“编程”。
在这次会议中，Aaron 教了我很多我不知道的关于 Ruby on Rails 的知识，并提醒我一些我忘记的关于 Ruby 语言习惯的东西。 我相信 Aaron 也从我这里学到了一些东西。 在第一次直播中，我们创建了该功能的几个部分，并且知道我们需要在哪里找到解决方案。
我们在 第二次直播中了解了更多。 例如，我们发现管理环境和依赖关系很困难，但是有一些工具可以提供帮助。 此外，当您有一个目录结构，其中包含项目内的单独项目时，管理项目可能会很困难。 上下文很重要！ 我们还发现下拉列表很难处理。
最后的润色
直播后，该功能尚未完成，但我们已经很接近了。 我决定自己完成它，因为 Aaron 需要专注于其他工作。 我也努力寻找时间来完成它，所以我很感激 GitLab 的某个人联系我并询问我是否需要帮助。 我完成了我能完成的工作，并提交了一个 合并请求。 （如果您想很快学到很多东西，值得阅读合并请求讨论。）
来自 GitLab 的 Douwe 和 Nick Thomas 很快加入了，并给了我很多指导来完成其中的一些工作。 我们发现下拉代码存在一个相当模糊的问题，导致了我们的大部分问题。 如果没有 Nick 的帮助，我想我永远找不到问题或需要更新的代码。
Nick 进行了很多更改，使其准备好合并，我尽我所能帮助在接下来的几周内完成它。
该功能最终完成并合并回 GitLab 11.3 版本的 Master 分支。 但是，这并不是与我们的工作相关的唯一完成的功能。 Nick 还实现了其他文件类型，例如 .gitlab-ci.yml、.gitignore 和 Dockerfile 作为 实例级别的模板。
我为什么要这样做？
那么，为什么一个非营利组织的技术总监决定为 GitLab 做出贡献呢？ 主要有三个原因
首先，它让我有机会表明我并非无所不知，而且我容易犯错。 我们正在 NAIC 建立一种非责备和仆人式领导的文化，而这是我认为最快的身体力行的方式。
其次，我们希望将贡献回开源项目作为我们文化的一部分。 当技术总监在 YouTube 上直播并告诉其他人他们可以这样做时，很难有人说“你不允许贡献”。 此外，我们由消费者资助，所以我的目标之一是让 NAIC 尽可能精益地运作，并尽可能多地回馈社区。
最后，我想贡献这个特定的功能，因为这是我们法律部门需要的。 使保持合规性更容易有助于我们的法律团队，这有助于我们建立一种信任和互利的牢固关系，这在我们进入具有法律模糊性的新领域时非常重要。 此外，我知道在不久的将来没有人会处理这个问题，很多客户都想要它，并且一旦我们建立框架，其他文件类型就可以很快地实现。
贡献者入门
决定是否为 GitLab 和开源或源可用代码做出贡献可能涉及您的法律团队和公司政策，因此请首先咨询他们。 即使为源可用代码做出贡献（就像我们所做的那样）也是有价值的。 我们不仅更改了商业版本的代码，还更改了开源版本的代码。
如果您想要一个 GitLab 没有优先考虑的功能，我建议您通过 issue 联系某人或与您的客户经理联系来贡献它。 他们很可能愿意与您交谈以确保您的方向正确，他们甚至可能同意像与我们合作一样进行合作。
在您开始处理贡献的有趣部分之前，请查看 GitLab 的 贡献指南。 如果您想做出贡献，但没有一个特定的功能，一个简单的入门方法是 搜索 GitLab issues 并按权重排序。 权重值较低的预计是最简单的。 GitLab 还尝试通过一些关于变更日志更新和其他常规管理工作的自动化魔法来使贡献更容易，但是如果您不知道这些东西的存在，可能会更加令人困惑。
我希望您能尽快做出贡献。 我希望我的第二次贡献发生在 2019 年。
评论已关闭。