如何往Spark社区做贡献，贡献代码
随着社区正在努力准备Apache Spark的下一版本3.0，您可能会问自己“我如何参与其中？”。现在的Spark代码已经很庞大，因此很难知道如何开始自己做出贡献。Spark PMC & Committer Holden Karau以开发人员为中心，教你如何为Spark社区做贡献，逐步发现好的问题点，格式化代码，寻找代码评审者以及在代码评审过程中期望得到什么。除了如何编写代码之外，她还探讨Apache Spark做出贡献的其他方法，从帮助测试RC(Release Candidate)版本，到进行所有重要的代码评审，错误分类等等，也包括例如回答别人的技术问题。
Apache Spark社区已经有大量中国人的身影，在国内也常常有开发者线下聚会研讨，本文末尾也有示说网参与的上海和杭州地区Apache开源社区活动（完全免费），可以了解目前开源技术社区的前沿动态。
文末可以查看Holden演讲视频（含中英字幕），以下为PPT原文截图和核心要点整理，希望对如何贡献Apache Spark开源社区的同学有一定启发。
本文是基于Holden Karau在2019年Spark Summit EU上的分享视频整理而成，按照Holden自己的说法，不代表Spark PMC的观点，（虽然Holden是Spark PMC & Committer），仅仅是她个人的建议和看法，供广大开发者朋友参考。
主要讨论如下几个方面：
- 目前Spark开发社区的状态；
- 为什么要给Apache Spark做贡献；
- 给Spark社区做贡献的几个途径；
- 如何找到可以参与贡献；
- 贡献代码和文档修改，可能用到的工具集合；
作为Spark的PMC，她认为你可能有如下几个原因，期待能够给Spark社区做出贡献：
- 修复工作中碰到的Spark的bug或者问题
- 学习分布式系统
- 强化你在Scala/Python/R/Java等语言的技能
- 函数式编程的奇技淫巧
- 个人成长的光辉记录和成就感，（或许有利于找到更好的工作？）
- 基于Spark弄点有意思的事
如何向Spark做出自己的贡献？
- 直接提交相关的代码修改
- Spark Package中的代码修改
- 帮助审查Spark代码
- Spark周边的库代码
- Spark书籍，技术分享，技术博客等
- 在Spark邮件列表，StackOverflow等地方回答技术问题
- Spark测试和发行的验证工作
当然，每个人对于Spark的熟悉程度不一样，这个和每个人的工作内容及兴趣有很大关系，Holden列举了相关的工作涉及到的具体内容和问题。
假如你希望能从直接为Spark贡献代码：
- 或许你碰到了Spark的bug并希望修复它
- 或许你希望给Spark增加新的特性
- 你得先看看你的想法有没有人已经着手在做了
- 如果你期待的代码改动比较复杂，除非你已经有相当的经验，否则最好还是挑个简单的开始
- 千万别一意孤行，干起来再说，至少得先看看http://spark.apache.org/contributing.html 或者读完本文
既然已经下定决心要为Spark做点代码的活，那么先了解一下Spark 3.0目前的模块。
开始之前你还需要了解，Spark的任何改动，都会关联一个JIRA的Issue，你得先注册JIRA，然后关注JIRA上面的Spark社区动静。这个不是Spark独有的，貌似基本上所有的Apache开源项目都是通过JIRA来跟踪各种问题。
基本上JIRA里会包含别人发现，或者计划要做的那些事，如果你想修复一个bug或者增加新的特性，先查查JIRA上有没有人已经提了类似的Issue，如果没有，那很好，你可以创建一个JIRA，并且告诉别人你已经着手做了，当然，你也可以挑一个别人没有着手做的Issue，自己先干起来，当然，干之前你需要在Issue里留下点文字，告诉其他人你已经在做这个共组了。
JIRA里不太适合分配任务（通常这是committer们的活），也不太适合把很长的设计文档放到上面，更好的做法是，把设计文档用google doc来做，然后再JIRA相关的issue下，粘贴以下设计文档的链接，在国内的朋友，你可能还要多一个“fq”用Google Doc的步骤。
在JIRA中，找个简单适合初次贡献Spark代码的小技巧。
还可以在代码中grep一把，看看代码里留下的“TODO”注释，或许你可以从中找点灵感。
大的Spark特性或者改动，需要先提交SPIP（Spark Project Improvement Proposals）,会有很多熟悉相关模块的committer和contributor参与到这个修改建议的讨论，等代码都打成默契了，再来决定谁来干，怎么干。
你得熟悉github的玩法，视频原文中有详细的介绍。
怎么编译spark，这里比较简单，实际上的编译工作会涉及到很多的环境参数，还得fq，这个很重要。
如果修改代码可能有点难，也可以先考虑修改文档，文档中的错误总是特别容易出现，而且，一旦修改好后，总是很快会被合并到代码主干。
文档的生成工具
找一个你擅长的开发工具和Spark模块。
测试。。
代码写好了之后，是否符合spark社区的代码规范呢?http://spark.apache.org/contributing.html#code-style-guide 对应有Scala/Java/Python/R等语言的规范，还有Spark社区自己的规范。
MiMa是验证二进制兼容性的工具，确保在不同版本间API的兼容性得到检测，当然这玩意比较敏感，有时候API不兼容是实现设计上的改动，特别是3.0 API的出现，确实会有很多东西和以前不兼容了。
好了，当你已经完成代码改动和测试，终于可以提交PR了。提交之前还有些步骤，报名PR的名称规范，视频原文有演示，有一个网站不要错过：https://spark-prs.appspot.com/ （很不幸，还得fq）
代码PR已经创建后，会有代码评审环节，参与代码评审的人，也是值得尊敬的，是每个contributor成长和帮助别人成长的过程。
找到合适的人帮你评审代码，通常最后把关的是Spark的Committer们，当然不是每个Committer都熟悉所有的模块，需要找对合适的人比较重要，你可以@相关模块的活跃committer，他们通常都会很热心的回复你。
终于到了著名的：LGTM / SGTM，你离代码合并又近了一步。
实际操作PR的一些小建议
当然，PR很多时候是没有办法被合并的，原因和理由有时候会比较难以启口，任何时候都不要沮丧。
代码设计上每个人都有自己的思考和想法，慢慢积累自己的思考，深入了解Spark社区对于代码的规则和要求，你会进步很快的。
当然，有些问题可能和你没有关系，或者committer们太忙，或者jenkins不工作了，或者jenkins不帮你的PR做自动化测试了，大胆的ping committer们。
以人为本，共建和谐社区！以下是各种小建议：
社区不是独立存在的，而是来自全球1500名工程师参与探讨的地方，任何大的改动之前，请先知会社区，善于利用邮件列表来沟通。当然，现在会讲普通话的开发者和committer及PMC们越来越多，可以多参加示说网上关于各种大数据相关的技术交流社区，可以面对面和社区大神们探讨技术和技术以外的道道。
（全文完）
视频（中英文字幕）见：https://www.slidestalk.com/Spark/GettingStartedContributingtoApacheSparkFromPRCRJIRAandBeyond?video
另外，欢迎关注开源技术社区的相关内容研讨：
1）看点：由中国计算机学会(CCF)组织举办的，Alluxio / Hadoop / HBase / Flink / Spark PMC和Committer聚首探讨各自社区的最新动态和发展方向。
https://www.slidestalk.com/m/64
2）看点：由阿里云EMR团队和Intel大数据技术团队联合举办，分享Spark在云端环境中的优化及在AI和数据分析领域的最新动态。
https://www.slidestalk.com/m/61
3）看点：由StreamNative举办，分享ApachePulsar的动态，您可以和该项目的主创人员好好交流社区开发心得。
