如何参与 Apache 项目社区

| 作者：tison

| 转载自：知乎

| 编辑：贺鑫

| 设计：朱亿钦

| 责编：王皓月

如何参与到 Apache 项目的开发讨论中去，或者更广泛地说，如何参与到开源项目的开发讨论中去，在开源日渐风靡的今天越来越成为一个新手常问的问题。其实参与开源项目并不困难，参与 Apache 项目更有一些具体的套路。我有幸在今年九月份成为 Apache Flink 的 Committer，本文以 Apache Flink 社区为例，介绍作为开发者，如何参与到 Apache 项目社区中去，如何做出自己的贡献和发表自己的意见。

交流技巧

这里要摆在第一位的是交流技巧，放在这个具体的环境下即与来自全球各地的开发者协作的语言技巧。毫无疑问，清晰地表达自己的观点和谦虚地听取别人的观点是参与开源社区的一个重要能力。

所谓的社区是由人组成的，社区的活动也是为了解决社区成员的问题而发生的。抛开社区中的人光谈技术或者代码是没有意义的。在参与社区活动的时候，切忌一个人埋头苦干而不与社区交流，要与社区有良好的互动，这样社区的成员对你的信任感和认可才会提升，你也才能更好的为社区服务。

具体到 Apache Flink 这样拥有众多模块的项目，其中的 Committer 和 PMC 也未必甚至很大可能上不能详细了解每一个模块的具体细节。为此，社区的新人想要提升自己的影响力，最好是专注在某一个模块上，和模块的 maintainer 保持良好的关系。这样不管是对新人了解代码的来龙去脉和未来被推举成为 Committer 等过程都有帮助。

最早进入 Flink 的时候我基本上每周都会有一个问题问现在 Flink 的 Tech Leader Till，后来跟我家 mentor 另一位 Commiter 施晓罡博士一起工作的时候我也常常缠着他问各种各样的问题。从 FLIP-6 的框架设计到作业提交的设计，到各个小组件最早的设计构想到如何成为今天的融合怪（bushi）。了解代码的演化历史对新人修改代码的时候不会偶然破坏一些前提假设有莫大的帮助，明白某个模块想要解决的问题能够帮助修改代码时向着目标收敛，和 maintainer 形成的共识和公共知识更能够使得 Review 的流程更加流畅和顺利。

分享两个道听途说的说法，一个是据说在评价一个人能否成为 Committer 的时候，有一个通用的指标是“easy to work with”，也就是说合作起来很顺畅；另一个是据说情绪化的言语可能会阻碍当选 Committer，即使这个人技术过得去，也贡献了不少的 patch。

这一部分从实际操作上除了主观的交流技巧之外，对于国内开发者，有一个重要的事情是要练好英语呀！不管是读写还是听说，都非常的重要。在重大特性的合作讨论中，有时会出现邮件列表不能很好的进行沟通的情况，通过一次视频会议同步观点就可能能够使得共识的达成事半功倍进行，这和微信聊不明白的时候打电话或者当面聊是一样的。熟练的掌握英语特别是流畅的表达技巧能够使得项目的成员更好的了解你的思路，甚至很快地推举你成为 PMC，原因就包括了你能够让自己对项目发展的看法明确的传达出去的缘故。毕竟人类不是三体人，也没有卡拉，只能通过书面或者口头的方式同步观点，交流的技巧包括交流工具的熟练都至关重要。

代码提交技巧

代码提交技巧放在第二点讲是因为从道理上将它不比交流重要，但是对于国内开发者来说在如何向开源项目提交代码上却存在一个巨大的常识偏差，即没有认识到，只要是对代码仓库的修改，都算是代码提交，也都算是你个人的贡献。

国内的开发者总想搞个大的特性，对其他的小修改都看不上，也就是常说的眼高手低。其实社区的贡献涉及方方面面，不只是大特性是贡献，提交问题也是贡献，回答问题也是贡献，修复文档也是贡献，维护自动化流程也是贡献。一步一步积累对自己的认可才能得到社区的信赖。你就想想，社区里突然来了一个从来也没见过的人，上来就说我们把一个模块重写一遍吧，这你敢信他么。而且闭门造车有的时候自以为搞得特性多么了不起，其实跟这个模块的初衷乃至社区的发展方向都是违背的，自然不会得到重视。

混迹开源社区的人常常开的一个玩笑是“fix typo”，通常是看到调侃某个人又在蹭改错别词的 commit 了。不过这样的 commit 对于新手来说是相性非常相合的，我个人也通过“fix typo”的方式接触过若干个社区。当然，这样的贡献是微不足道的，对于有志于做出更大贡献的开发者来说也不应该完全把时间都用来做编辑的工作。但是这样的一个贡献也会走一个正规的（可能有所简化的）commit 流程，在此期间你可以了解社区的接受代码提交运作方式。不同社区往往会有不小的差别，例如问题提在 GitHub Issue 上还是 JIRA 上，使用 JIRA 提交 Patch 还是使用 Pull Request 提交 Patch，需要运行怎样的测试，如何理解测试产出物，commit 的格式等等。保证代码提交符合规范，能够节省他人的时间，也能让社区的成员感觉到你是一个遵守规则的参与者。此外，对于某些第一次接触开源项目协作的同学来说，还需要通过这样的过程了解如何使用 Git 和 GitHub 或者其他各种工具的基本使用技巧。通过一个 trivial 的贡献，能够避免讨论修改细节的负担，先尽快的掌握这个流程。这也涉及社区对你的观感，试想一个社区规范都没搞清楚的人一来就要改代码，如果不是 trivial 的重构的话，也会审慎三分。当然，防杠起见，如果你已经是一个成熟的开发者，那你看这篇文章干啥，你还不懂吗

对于大的特性修改，国内开发者特别是一些写多了内部代码想也不想就提交的人，会犯的一个常见的错误是没有修改的背景和抽象设计，直接就 pia 上去一坨代码，英语又差，别人看不懂他也解释不通。其实代码的提交是一个协作的过程，需要达成共识，并不是说甩一脸代码别人就会去看，特别是 Java 之类的很多样板化的修改的代码，diff 贼多信息量贼少。对于任何 non-trivial 的改动，都需要有一定的描述来表明动机；对于大的改动，更需要设计文档来留存记忆。人的记忆不是永久的，总会忘记最初的时候自己为什么做某一件事情，设计文档的沉淀对于社区摆脱人的不确定性演化有至关重要的作用。只有记下来最初是为了做什么事而做出的这个改动，以后移交代码或者教授新人的时候才好援引和解释。

兴趣使然

上面两个是作为开发者的我从实践的角度具体讨论的几个小的切入点，最后一点想简单聊聊的是动机的问题。我曾经看到知乎上有这样的问题《如何在开源社区中提高自己的地位？》，也被人问过《在校生如何利用好开源社区？》。其实，总是想着成为 Committer，想着如何利用社区反而是缘木求鱼的方法，因为这些事情你想了也不会有任何帮助。真正需要的一是沟通技巧，二是技术水平。只要这两点到位了，如果社区健康的话，自然会欢迎你的加入。

我在成为 Committer 之前，并没有想着我的 commit 多么的重要，非要争取一到两个 commit 的实际数量，只是作为第一份工作感觉分布式系统的开发也非常的有趣，兴趣使然地想看看自己能做什么。出乎意外地成为 Committer 之后更愿意将一些 trivial 的或者稍微了解就可以上手任务告诉中文社区的同学，希望能够吸引他们参与进来，也会协助 Review 和合并。我相信，只要有一颗热爱开发的心，在自己的岗位上做好自己的工作，我们一定能够开发出立派的软件，让开发者的社会印象在国内有所提升，让中国开发者的名片在世界上都有口皆碑。

最后跳脱得有点儿厉害，嘿嘿。欢迎大家来找我交流 Flink 或者各种有趣的分布式系统的问题呀，说不定我们讨论的某一段内容，就是下一个有趣的开源软件的雏形。