在上海举行的 2019 中国KubeCon+Cloud Native大会上，聚集了超过 3500 名的参会者。会议主要讨论了 Kubernetes 社区的发展速度，并重点讨论了如何为社区做出贡献。
除了本地中文社区的演讲之外，本次活动的其他许多演讲也都谈到了 Kubernetes 社区在相对较短的时间里达到的惊人数字。很多开发人员在走廊里聊天时讨论的都是如何以某种形式为社区做贡献，因为对于他们来说，只是感觉成了社区的一部分是不够的。云原生计算基金会最近公布了一些统计数据，这些数据来自对该基金会最大托管项目 Kubernetes 日志的追踪。
InfoQ 采访了 Kubernetes 社区的贡献者Nikhita Raghunath。她也是 CNCF 的大使和 SIG（特别兴趣小组）贡献者体验小组的技术负责人。
Raghunath 以她的第一次贡献经历开始了本次讨论，这最初看起来令人生畏，但与社区的互动消除了她的恐惧。她还谈到了社区的组织，并简要介绍了帮助贡献者的一些工具，这些工具的主要目的是让读者更好地了解如何以及在哪里作出贡献。
尽管人们可以通过阅读详细的贡献者指南来获得全面的操作方法，Raghunath 还是列出了一些速成技巧和诀窍，这些技巧和诀窍主要针对那些缺乏耐心的贡献者，他们渴望尽快开始并在贡献者的道路上前进。
InfoQ：欢迎来到 InfoQ。你能介绍一下你的第一个贡献吗？你是怎么计划的，花了多长时间，并从中学到了什么？
Raghunath：在读大学的时候，我注意到 Kubernetes 参与到了谷歌暑期代码（GSoC）实习项目。GSoc 是一个为期四个月的带薪实习项目，目的是让学生们可以参与开源项目。
作为我的 GSoC 应用程序的一部分，我决定处理一个与 CRD 中整数封装不正确有关的 bug（那时的名称是 TPR）。我并不是很熟悉 TPR 的内部工作原理，所以我决定首先阅读与之相关的设计方案。在对它有了一个大致的了解后，我就开始学习 Kubernetes 如何进行 JSON 序列化和反序列化。老实说，从零开始理解这些还是让人有些恐怖的。我了解了现有的问题，使用相关词语在所有代码中进行了检索，并在 SIG API mechanical slack 频道里提了许多问题。在这之后，我终于创建了一个 PR（拉取请求），并且被合并了！
整个过程花了我大约一周的时间，其中每天都要工作几个小时。我记得当时我对整个 GitHub 自动化的工作方式感到困惑，我担心自己会在 Slack 中问一些非常愚蠢的问题。现在回想起来，我当初的恐惧是多么的毫无根据，因为每个人在回答的时候都是那么的善良和耐心。那是在 2017 年，从那以后，我们在面向贡献者的文档方面取得了长足的进步。有文档解释自动化功能，有视频说明如何查阅代码。我最大的建议是不要回避问问题，并且在 slack 和（如果可能的话）会议上露面，这样其他贡献者就会看到你很活跃，知道你是谁。这也有助于承担/委派新的任务，并晋升为评审者。
InfoQ：你能提供一些关于如何开始贡献的建议吗，尤其是对那些没有耐心并且不想从头到尾阅读贡献者指南的人？
Raghunath：我们有一个使用八种语言编写的攻略，就是因为这个原因！:)
除了这份攻略，这里还有一些实用技巧：
开始在 SIG Slack 频道和会议中潜伏！它消除了介绍自己或从一开始就要贡献的额外压力。这也将有助于理解社区准则和 SIG 目前正在从事的工作。贡献者日历包含了所有关于 SIG 会议的信息。即使你不能参加会议，这些会议记录还是可以帮助你快速了解情况。
Kubernetes 使用Prow以“斜杠命令”的形式实现了 CI/CD 和 GitHub 自动化。当创建 PR 时，你可能会看到机器人添加了某些标签和注释，甚至要求你运行某些命令。理解这种自动化至关重要，这可以确保你的 PR 得到评审者的足够重视，并迅速合并。命令帮助页面提供了所有命令的简洁概述，包括如何使用它们的示例。
要找到一个需要修复的问题，你可以查找带有“good-first-issue”或“help-wanted”标签的问题。除此之外，从修复lint、shellcheck或静态检查等错误开始贡献代码也不错，因为它们不需要对代码库有很深的理解。
要了解kubernetes/kubernetes库的概念，可以查看本视频。如果你希望浏览某一个特定库的代码，你也可以在贡献者见面页面直接提问。针对特定文件运行“git blame”命令可以找到导致某些更改的特定提交/PR。这非常有帮助，因为拉取请求中包含了许多额外的背景和讨论。
如果你正在需求具体的指导，并且愿意每周贡献一定的时间，那么可以考虑成为发布团队的“影子”。“影子”们将会得到导师的指导，甚至可以逐步成为未来发布周期的负责人！
InfoQ：贡献 Kubernetes 文档比贡献实际的 Kubernetes 代码容易吗？你能比较下文档贡献和代码库贡献吗？
Raghunath：我认为这是很微妙的。修复文档中的错别字的确很容易，但文档贡献远远超出了这个范围。用清晰、简洁和明确的术语表达技术概念，让具有不同技术背景的人都能轻松地理解，这是非常难做到的。
SIG 文档团队目前正在积极开展的一项工作就是本地化为不同的语言。表面上看，这似乎更容易，但实际上要费力得多。本地化超越了单纯的翻译，它要求所有的概念都能够保持原有的意义，并且在目标语言中传达出相似的内涵。要在实践中实现这一点，需要对技术概念和语言进行仔细的审阅和深刻的理解。
让我们对比一下代码更改，比如修复 lint、shellcheck 或静态检查错误。修复这些错误需要运行一个脚本，然后输出包含错误原因的故障信息。由于原因已经知道（大多数情况下，输出还包含关于所需更改的建议），所以修复它们比较容易。此外，修复这些错误并不特别需要有很强的 Kubernetes 背景。
InfoQ：如果我已经知道如何在 GitHub 上创建拉取请求（PR），那么在开始向代码库贡献代码之前，从技术角度来说，我还需要知道些什么呢？
Raghunath：首先，你需要设置你的开发环境。根据所贡献代码库的不同，你可能还需要运行其它命令。从位于代码库根目录下的 CONTRIBUTING.md 文件中，你可以找到更多相关信息。一旦你对代码进行了更改，你就必须将更改划分为更小提交的逻辑序列。一个简单的技巧就是把所有生成的代码都放在一个提交里，因为这样可以更容易检查更改。
虽然我们没有对提交消息的样式强加任何特定的限制，但遵循良好的提交消息实践总是有帮助的。请注意，某些库还是可能会施加额外的限制，如禁止合并提交或提交消息中的某些关键字。创建 PR 后，你会发现机器人会给你的 PR 添加标签和注释。理解上面提到的 GitHub 自动化和斜杠命令将有助于同机器人交互。下面是一些常用的命令：
通过添加注释/sig cli 来应用 SIG 标签。这将确保你的 PR 进入 SIG CLI 评审者的视线。
命令/cc @username 将请求评审，/assign @username 会把你的 PR 分配给一个特定的人。
/retest 会自动重新启动你的 PR 上所有的失败测试。当你的 PR 遇到flake测试时尤其方便。
最重要的命令/meow 和/woof 会让机器人添加一个猫和狗的图片评论！
当评审者觉得你的 PR 看起来还不错后，他们会使用/lgtm 和/approve 命令为你的 PR 添加“lgtm”（在我看来不错）和“approved”标签。一旦你的 PR 有了这些标签，它就会被机器人自动合并。
InfoQ：有没有某些 Kubernetes 社区更适合来贡献呢？相反的，哪些社区更具挑战性呢？
Raghunath：有一些棘手的错误很难调试和修复，比如可扩展性失败或者 flaky 测试。但是在我看来，不能用一个笼统的说明把一个库标记为更难做贡献。
话虽如此，许多人将对 Kubernetes 的贡献等同于对 Kubernetes/Kubernetes 核心库的贡献。但事实远非如此。在‘kubernetes-sigs’、‘kuberentes-client’和‘kubernetes-csi’等 GitHub 组织中还有许多其他子项目和库。所有这些代码库都非常重要，而且通常只有一小部分人在维护它们。参与这些子项目相对比较“简单”，因为你可以与维护人员进行更多的交互，并且可以更快地得到响应。
InfoQ：为开源做贡献，除了提交代码带来的满足感之外，还有其它回报吗？
Raghunath：代码是最初吸引我的一个方面，但是我在实习之后仍然留了下来，继续为社区做贡献。“为代码而来，为人而留“绝对引起了我的共鸣。我结交了很多来自世界各地的朋友，虽然他们中的许多人在不同的公司，但我们仍然可以一起工作相互学习。
就个人而言，对我来说最大的奖励就是在我找工作的时候许多机会为我打开了大门。一些贡献者也已经换了工作，但是他们仍然像以前一样继续为 Kubernetes 工作。这有助于个人成长，也使项目能够长期成功。
当然，还有其它奖励，比如Kubernetes贡献者补丁，参加 Kubernetes 贡献者峰会的机会（与 KubeCons 同时举行)，还有一大堆与 Kuberentes 相关的礼物！
总之，参与 Kubernetes 社区贡献会涉及到一些步骤和流程，但理解并遵循上面提到的指导意见会减少一些恐惧，也让参与社区贡献变得更加容易。
更多关于 Kubernetes 社区贡献的信息请参阅贡献者指南。
原文链接：
Contributing to the Kubernetes Community: Getting Started Q&A with Contributor Nikhita Raghunath
评论