阿里土话
身为一个老阿里，开篇之前总想甩点和阿里相关的内容，当然，这些内容或多或少的也和如何成为ASF提交者（Committer）有关系：
- 做正确的事，正确地做事。
- 与其抱怨老板关注细节，不如比老板更细节, Don't Complain. Go to fix it.
- 绝不放弃，就会发光；若有光芒，必有远方。
如果说做正确的事是一种选择，那么正确的做事就是一种能力，就以阿里巴巴在疫情期间对武汉捐赠10亿医疗物资来说，进行捐赠就是在做正确的事，那么如何将海内外的10亿医疗物资快速的送达武汉就是能力，其中大量医疗物资都来自海外，那么这些物资空运要跨越10多个国家的领空，如何处理？怎么做到？我不知道怎么处理的，但可以说 得道者多助，阿里巴巴做到了！
此外，阿里巴巴还有能让全球振奋和刮目相看的大数据和AI技术能力，一项传统技术30分钟才能完成的核酸对比，阿里巴巴技术团队让这个检测在60秒内完成，这不仅仅是和时间赛跑的问题，这是对生命延续的问题！还有 支付宝的 健康码，钉钉的 在家上课，复工平台等等。阿里巴巴不仅仅在做正确的事，而且也一直被证明着阿里巴巴拥有正确做事的能力！
提交者(Committer)是怎样的角色？
我们在《走进ASF系列》多次提及 ASF金字塔组织，今天我们重点聊聊其中的Committer的权利与职责。
在ASF官网上面对贡献者(Contributor)和提交者(Committer)有明确的角色定义，如下：
简单理解如下：
- 贡献者(Contributors) - 就是开发人员，以写代码或写文档的形式为项目做贡献。开发人员可以多种方式共享社区，比如参加者邮件列表讨论、提交代码补丁、提交文档等等。
- 提交者(Committers) - 提交者是一批特殊的贡献者，他们是拥有代码仓库写操作权限的开发者。
也就是说，Committer 也是社区的Contributor，表面上看某个项目的Committer相对于该项目的普通Contributor来说，拥有了对该项目代码仓库的写入权限。那么这个写入权限又意味着什么呢？- 个人荣耀和反哺社区的责任！
我们暂且记住这个 “个人荣耀和反哺社区的责任！”，我们聊聊怎样才能拥有这个“个人荣耀”和肩负“反哺社区的责任”？
Contributor 到 Committer
在《走进ASF系列 - 如何成为一个合格的ASF贡献者(Contributor)》中我们介绍了如何向社区贡献第一个PR，但一个PR距离成为一名优秀的Contributor，距离成为一名Committer还有一段修炼之路。
Never update your description of an issue
通常我们有很多种贡献社区的途径，但往往完整性和逻辑严谨性把握的好坏决定了迎来的是掌声还是抱怨。
一次性的将问题描述清楚是一种能力。虽然看似简单，但事实证明大部人都做不到，很多人描述一个问题需要被追问多次才能将问题表述清楚。也就是说，很多人在汇报一个Issue的时候，还没有到讨论问题解决方案的地步，就已经把想帮你解决问题的人弄崩溃了。要解决这个现象首先要从内因出发，我相信参与社区贡献的人都是有能力将问题描述清楚的，只是缺少了 一定要 一次性 将问题描述清楚的意识！所以 “Never update your description of a issue” 目的就是要努力做到描述完一个问题之后就不需要有任何更新了，如果你真的能做到这一点，并成为一种习惯，那你想不被认可都很难～～
当然，要做到这一点，还是需要一些做事的逻辑思维的，我们以向社区汇报一个问题（创建一个JIRA）为例，当我们发现一个问题（不论是代码问题，还是文档问题）的时候，第一件要做的事情就是创建一个Issue。创建Issue的时候，我们可以按照如下逻辑进行（当然每个步骤要有一次性将问题描述清楚的意识）：
其实“Never update your description of an issue”的本质也是我们在《走进ASF系列 - 如何成为一个合格的ASF贡献者(Contributor)》中所说的 “前进一小步，文明一大步”的原则，你多思考一下表述逻辑，多描述一下问题始末，多搜集一下问题资料，就避免了他人的麻烦、顾虑和对问题的确定，进而可以直接进入对问题解决方案的思考，既节省了他人的时间，也加速了你问题的解决速度！所谓，己所不欲，勿施于人，予人玫瑰, 必将手有余香！
Small is Powerful，Small is Beautiful
"不因善小而不为", 这是我们为人之道，也同样适用于我们做开源建设。一个语法错误，一个typo，一个标点符号的改进都会受到社区的欢迎！优秀的社区贡献者不仅仅可以为社区提供重大的功能贡献，更需要具备为社区小的改变而努力的意识！很多关注社区贡献的人会发现，一些贡献者会只做test的优化，也能获得Committer的殊荣，为什么？有些人抱怨“不公平”，凭什么我做了很重要的功能还没有拿到Committer，而那些只做test优化的人却成为了Committer。 我来告诉你可能的原因：
- 贡献的重要性 - 对于整体项目，固然代码非常重要，但文档和测试对开源建设同样至关重要，写文档和做测试也是一门学问；
- 贡献的初衷和持续性 - 处处为社区考虑，不挑活的默默付出精神更值得尊重，PMC会细致的观察每个人对社区贡献的初衷，贡献的内容和贡献的持续性。
- 贡献的多面性 - 代码贡献，文档贡献，回答社区问题，宣传社区文化，组织社区活动，维护社区安全等等，任何对项目有利的贡献不分轻重，不要有某种类型的贡献一定是比另一种类型的贡献更重要的偏见，要看到社区贡献的多元化。
Don't Complain. Go to fix it.
上面聊到阿里土话 “与其抱怨老板关注细节，不如比老板更细节”，这里我想说，不要抱怨代码reviewer太关注细节，如果你做的足够足够完美，别人除了说“LGTM”之外，就是大赞你的高质量贡献了。社区规则是一种“精英统治”，所谓“精英统治”就是 谁是对的，谁就是精英，就服从谁。所以在具体的代码面前，0就是0，1就是1，没有Committer和PMC的特权，谁是对的，谁是最优的就以谁的为准。所以如果在社区贡献过程中，Reviewer对你提出的建议，哪怕是微小的改进，请不要抱怨，按正确的建议优化贡献就好了！所以请做到：
- 不要抱怨代码reviewer太关注细节，请你自己更注重细节！
- 如果有人提出任何微小但有意义的建议， Don't Complain. Go to fix it！
更多的交互才会让PR更完美，哪怕有几百个Comments，在某种意义上来说，更多Reviewer和更多的Comments也证明了PR的重要性和社区的精益求精，不要被Comment数量所吓到，比如下面的PR，尽管有300个评论，但这些讨论可以留痕，最终让PR是最好的状态，那么同样是优秀的PR。这个和 “前进一小步，文明一大步”并不矛盾，对吧? :-)
要驱动别人，先点燃自己
燃烧自己是一种状态，是通过自我不断的对外输出，通过行为让周围的人感知的，进而让别人感受到你的能量和驱动力！社区贡献是自怨的，没有任何人能够指挥或者命令其他贡献者。人性本善，你给予我微笑，我必给你一个拥抱。如果你想让你的PR被人及时的Review，那么你也要先主动的力所能及的Review其他人的PR。请注意，不仅是Committer可以Review Contributor 的PR，Contributor之间同样可以积极Review彼此的PR，也可以Review Committer和PMC所提交的PR，让你的激情引燃他人，进而让你所专注的项目模块快速发展！如果你一直以燃烧自己的方式持续积极的推动社区的发展，那么你的贡献必将被社区关注，必将被PMC所关注，你距离Committer也就不远了。更幸运的是社区有多种方式，很方便的查看到你对开源的贡献，比如你的github的profile页面，我去年的贡献有600+，如下：
如图，小方块颜色越深代表你当时的贡献越多，如果你以前没有看过，你也可以现在查看一下你自己一年来的贡献 :-)
成为Committer的信号
任何人的成功都不是偶然的，成为Committer也不是一夜成名的事情，都是要经过不断的持续努力。到一定程度某些信号会释放给你：
- 如果你的PR没有过多的改进建议，不断收到： “Great Job！ LGTM. +1 to merged"。
- 如果你Review其他人PR所给出的建议，持续收到：“Thanks for the commons, makes sense to me."
- 如果你发起的邮件提议，多数情况最终收到：“Good idea，+1 for the proposal.”
- 如果社区的用户列表时时会收到你帮助解答的问题，持续收到用户：“Thanks for your help，the suggestion solved my problem."
- 其他...
上面这些信号不仅仅会激发你的激情，其实PMC也会关注某个贡献者的社区贡献状态。这些信号都是提名你成为Committer的有力佐证！特别提醒： 上面的信号是需要有“持续性”和“一致性”特点的 。
好的贡献心态和持续不断的贡献社区是成为Committer的大前提，坚持不懈，永不放弃的精神必将促使你成为一并优秀的Contributor, 进而成为一名令人羡慕的Committer ：） 所谓： “绝不放弃，就会发光；若有光芒，必有远方。” 你也必将在某个不经意的时刻迎来那个激动人心的邀请，比如Flink社区的邀请内容大概如下：
那么问题来了，成为Committer之后应该如何进行社区贡献？如何成为优秀的Committer呢？
Review and Merge PR
在你成为Committer之后，提名你的PMC成员会给你发送一封如何Merge PR的操作步骤邮件（不是所有的项目PMC成员都会给自己发展的Committer发送这类邮件，因人而异），以我发展的Flink Committer为例，我会发一封如下邮件：
那么我现在就Merge一个PyFlink的PR12061为例，演示一下邮件中核心的操作内容：
- 查看你本地的repo情况
执行命令git remote -v:
我自己的repo命名为“jincheng", asf 的 repo 为“origin”，镜像repo就叫做“mirror”，这个名字不重要，你自己能区分清楚就行：
- 将你要Merge的PR拉取到本地
执行命令git fetch mirror pull/12061/head:FLINK-17454-PR:
- 将所有的Commits压缩为一个（保留必要的多个也是可以的）
切换到刚才建立的分支git checkout FLINK-17454-PR并查看git log -2(可以查看你想看的commit数量）要压缩的Commits, 如下：
由于这个PR已经被贡献者压缩过Commits，所以我们这里可以不执行git rebase -i HEAD~N(N是要压缩的数量）了.
- 规范Commit信息
有些刚刚加入社区贡献的贡献者提交Commit时候，描述信息可能不是十分完美，那么Committer可以借此机会进行一定的调整。比如这个PR中的Commit信息如下：
[FLINK-17454][python]python gateway callback server port should not be determined by JVM process. 这个信息没有大毛病，但就我个人而已，更希望把这个信息做一点点优化：
1) 在 [python]python之间添加空格 [python] python。
2) 将描述信息的句首用大写 [python] Python。
3) 描述信息尽量用肯定句，不要用否定句。
因为否定句只是否定了一种错误的做法，没有描述正确的做法是什么，这样会造成后面想了解这个Commit具体变化的人，只有通过查看源代码才知道。所以我做一点点的改进，变成 [FLINK-17454][python] Specify a port number for gateway callback server from python gateway, 如下：
- Rebase 代码到Master
执行命令git rebase master:
- Push 待Merge的分支到自己的repo
执行命令git push jincheng FLINK-17454-PR:FLINK-17454-PR，在我的repo会自动跑CI测试(Flink目前采用的是Azure)。当所有的测试都过了之后，就可以Merge代码了。 - Merge PR to ASF master
执行命令gck master,git merge FLINK-17454-PR,git push origin master:
可以通过查看repo的最新提交代码查看double check你Merge的情况：
- 关闭JIRA
最后一步是关闭JIRA，在Flink社区要求关闭JIRA时候要将Merge的分支和对应的Commit留痕在JIRA上面，如：Merged in to Master: 5f744d3f81bcfb8f77164a5ec9caa4594851d4bf。
Committer 的职责和反哺
作为项目的Contributor，有权设定自己工作内容，以及工作内容的优先级，可以选择在社区做一些自己喜欢的贡献。但作为一名Committer，拥有了项目代码的写权限，就响应的担负了一些对项目的责任，比如：
- Review PRs - 作为一名Committer，一个明显的职责就是尽可能多的Review来自Contributor的PRs，进行PR的Review即是对Contributor的帮助（反哺），更是在行使Committer的职责之一。
- 参与社区讨论 - 作为一名Committer，对社区发出的各种新功能的讨论，需要在自己熟悉的模块做出支持或者不支持的选择，并根据项目的实际情况和发展规划明确的解释清楚 支持或者不支持的原因。
- 参与项目发布 - 作为一名Committer，项目每个版本的发布都需要你进行发布的检查，确保每次发布的质量（当然PMC成员有跟多责任确保每次发布的质量）。
- 监督项目的发展 - 作为一名Committer，同样要时刻关注你所熟悉部分的Issues的进展，比如：JIRA上的讨论，PR Review的进度，并且Committer之间进行交叉Review，相互查阅待Merge的PR质量。面对任何不利于项目发展的事情，做敢于说No的人。
- 帮助用户解决问题 - 作为一名Committer，要有较强的用户服务意识，不仅仅要关心@dev邮件列表，更要关注@user邮件列表的用户问题。
- 项目活动 - 作为一名Committer，不仅仅要关注代码层面问题，也要适当的参加各种演讲，通过各种渠道扩大项目的知名度，吸引更多的贡献者，为项目的社区的成长做出最大的努力。
己所欲施于人，成为一名Committer之后应该更多的与现在的Contributor换位思考，尽可能多的响应Contributor的问题和Review Contributor的PRs. 同时思考PMC的日常事务，尽可能多的帮助PMC完成力所能及的事情，比如主动承担RM的职责，帮助进行项目版本的发布，这也是在为后期成为PMC成员作准备哦:-)
坚持坚持，相信相信
在Contributor成为Committer的过程中会存在很多的困难，会发生很多你无法想象的困难。同时也会存在你认为很不公平的事情，比如你认为不如你的人成为了Committer，成为了PMC成员。这个时候请牢记：“如果你喜欢这个项目，你相信你所参与的这个项目是可以为他人造福的，那么请暂时收起你认为不公平的想法，相信PMC的能力与公平公正性！”，由社区贡献延伸到公司职场，在考虑到社会生涯，你认为不公平的事情太多了，但 若干时间过去后你会发现，当时你认为的不公平 其实 很公平，任何人，任何组织，不会莫名其妙的对你戴有色眼镜，如果戴了，那也是你自己的行为影响了环境所造成的。想改变任何结果，请先改变自己对外界的看法！你变了，你眼里的世界才会变化，你变了，那面墙的回声才会发生改变。所谓，山不过来，那么你就走向山！总之，要 坚持你所坚持的，相信你所相信的，在漫长的社区贡献中，请始终牢记：
- 做正确的事，正确地做事。
- 与其抱怨他人关注细节，不如你更关注细节，如果做不到，Please Don't Complain. Go to fix it.
- 绝不放弃，就会发光；若有光芒，必有远方。
小结
本篇为大家介绍了参与开源的利好，原则，以及介绍为自己的第一个社区贡献需要做怎样的准备。最后诚挚邀请想参与开源建设的朋友首站加入Apache Flink 的PyFlink建设！
参考
[1] http://www.apache.org/foundation/how-it-works.html#committers