隨著社區正在努力準備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下，粘貼以下設計文檔的鏈接，在國內的朋友，你可能還要多一個“翻牆”用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
閱讀更多 示說網 的文章
