孔蓄

Github上有眾多優(yōu)秀的開源項目，大多數(shù)IT從業(yè)者將其當(dāng)做了予取予求的工具庫，遇到什么需求，先去Github搜一搜，但有沒有想過有一天自己也可以給開源事業(yè)做一些貢獻呢？本文將會以incubator-dubbo項目為例，闡釋給開源項目做貢獻并不是一件難事。

為何要給開源貢獻力量

為開源項目做貢獻得到的收益是多方面的，為了讓大家有足夠的信心加入到開源項目中，在文章最開始先列舉出它的諸多好處。

鞏固技能

無論是提交代碼、撰寫文檔、提交Issue，還是組織活動，當(dāng)切身參與到一個開源項目中，相關(guān)的技能都會得到歷練，并且在開源項目中找到自己的位置。一方面，日常工作中大多數(shù)人接觸到的是業(yè)務(wù)場景，并沒有太多機會接觸到基礎(chǔ)架構(gòu)組件，開源項目為我們提供了一個平臺，在這里，可以盡情地挑選自己熟悉的項目為它添磚加瓦（以Dubbo為例，并不是所有IT公司都有能力自研服務(wù)治理框架）；另一方面，所提交的代碼，會有管理員協(xié)助審核，他們會給出專業(yè)的建議，更好的代碼規(guī)范以及更優(yōu)的編程思路最終都會變成你的經(jīng)驗。

結(jié)交朋友

開源社區(qū)提供了一個平臺，在這里，可以認識很多純粹的技術(shù)愛好者，開源貢獻者是最符合geek定義的那群人，你所接觸到的往往是某個領(lǐng)域最厲害的那批人。

建立口碑

這是一個很好展示個人實力的地方，俗話說：“talk is cheap，show me the code”。作為技術(shù)人員，沒有什么比一個漂亮的Github主頁更有說服力的了。如果能夠為開源項目做出可觀的貢獻，也將收獲到業(yè)界的知名度，此時開源項目的成就和你是密不可分的。

傳承開源精神

只有源源不斷的貢獻者給開源項目添磚加瓦，才可以為Github一類的開源社區(qū)形成良好的開源風(fēng)氣。否則，只有輸出沒有輸入，開源會失去活力。

養(yǎng)成習(xí)慣

相信一旦養(yǎng)成了每天提交代碼的習(xí)慣，就像不想中斷打卡一樣，你絕不想中斷commit。不止有英語打卡、健身打卡，還有開源打卡。

貢獻代碼時的一些疑難雜癥

如果你是一名開源界的新手，可能會對貢獻的流程心生畏懼。比如：該怎么修改代碼并提交？我的代碼要是存在bug怎么辦？別人會不會認為我的代碼很low？我該如何尋找合適的開源項目？開源社區(qū)那么多的工具和詞匯都是什么意思？

在此將從一個小白的角度，介紹一下開源中的一些常見問題。

git常規(guī)操作

一般而言，我們選擇使用git來作為版本管理的工具，不一定要非常熟練地使用它，在我看來掌握clone，add，commit，pull，push即可，遇到復(fù)雜的場景，還有谷歌。

如果只是想下載源碼，查看它的源碼實現(xiàn)，使用Clone or download按鈕即可。

如果你想要給開源項目做改動，并且最終請求合并，讓開源項目存在你貢獻的代碼，就應(yīng)該使用fork。fork將會復(fù)制一份當(dāng)前主分支的代碼進入到你的倉庫中，之后你所有的修改，應(yīng)當(dāng)基于自己的倉庫進行，在功能開發(fā)/bug修復(fù)之后，可以使用倉庫向源倉庫提交pull request。只有源倉庫的管理員才有權(quán)利合并你的請求。

pull request經(jīng)常被縮寫為PR，指的是一次向源倉庫請求合并的行為，是fork了incubator-dubbo的倉庫之后才存在的操作按鈕。

管理者會對pull request涉及的改動進行review，以確保代碼是符合規(guī)范的，邏輯沒有沒偏差，以及是否符合框架的功能需求。

Travis CI

一些自動化的CI流程被植入在每一次pull request的構(gòu)建之中，用于給開源倉庫去校驗提交者的代碼是否符合既定的規(guī)范，如：編譯是否有問題，單元測試是否通過，覆蓋率是否達標(biāo)，代碼風(fēng)格是否合規(guī)等。一般情況下，必須通過CI，pull request才會被管理review。

Mailing list

每個開源項目都會有自己的貢獻規(guī)范，可以參考首頁的Contributing，獲取具體的信息。incubator-dubbo作為一個孵化中的apache項目，遵守了apache的傳統(tǒng)，在Contributing中描述道：當(dāng)你有新特性想要貢獻給Dubbo時，官方推薦使用mailing list的方式描述一遍你想要做的改動。

mailing list簡單來說，就是一個郵件通知機制，所有的Dubbo開發(fā)者都會訂閱該郵箱：dev@dubbo.incubator.apache. org。有任何新特性的改動，或者什么建議想要通知其他開發(fā)者，都可以通過向該郵箱發(fā)送郵件來達到這個目的，相同，你也會收到其轉(zhuǎn)發(fā)的其他開發(fā)者的郵件?；蛘吣闶且粋€Dubbo的使用者，想要得知開發(fā)者的改造方向，也可以訂閱，這個指南可以幫助你訂閱Dubbo的mailing list。

作為一個modern developer，可能覺得mailing list的交流方式存在滯后性，這樣的溝通方式不是特別的高效，但它作為apache項目的推薦交流方式存在其特殊的原因，在此不多贅述?？傊裱粋€原則：bug fix或者討論，可以在github issue中進行，影響較大的特性和討論則推薦在mailing list中展開。

其他貢獻形式

不僅僅只有貢獻代碼，修復(fù)bug等行為才算作為開源做貢獻，以下這些行為也屬于主要形式。

撰寫文檔

Dubbo文檔是其開源組成成分的重要一環(huán)，其內(nèi)容源文件位于：https：//github.com/apache/incubator-dubbo-website。同樣也是一個Git倉庫，任何想要對dubbo知識點的補充，都可以在這兒提交pull request，只需要一些markdown的語法知識，和一些可有可無的npm語法即可。如果覺得貢獻代碼對于現(xiàn)在的自己仍然有點難度，不妨從貢獻文檔開始接觸開源。

Issue

無論是Github中的Issue還是mailing list中的討論，無論是提出問題，匯報bug，還是回答問題（bugfix則不僅僅需要Issue了），協(xié)助管理者review pull request，都是貢獻的一種形式，勿以善小而不為。

其他行為

任何能夠想到的，可以幫助開源項目變得更好的的行為，都屬于開源貢獻。例如，給每個Issue打上合適的tag，關(guān)閉重復(fù)的Issue，鏈接相關(guān)聯(lián)的Issue，線下組織沙龍，回答Stack Overflow上相關(guān)的問題，以及文檔中一個錯別字的修改等。

有效溝通

無論處于什么樣的目的：僅僅是一次性的貢獻，亦或是永久性的加入社區(qū)，都得和他人進行溝通和交往，這是在開源圈發(fā)展必須修煉的技能。

在開啟一個Issue或PR之前，或者是在聊天室問問題之前，請牢記下面所列出的幾點建議，會讓工作更加高效。

給出上下文

以便于讓其他人能夠快速的理解。比如，運行程序時遇到一個錯誤，要解釋是如何做的，并描述如何才能再現(xiàn)錯誤現(xiàn)象。又比方說提交一個新的想法，要解釋為什么這么想，對于項目有用處嗎（不僅僅是只有你）。

做好準(zhǔn)備工作

不知道沒關(guān)系，但是要展現(xiàn)嘗試過、努力過。在尋求幫助之前，請確認閱讀了項目的readme、文檔、開放的和關(guān)閉的問題、郵件列表，并搜索了網(wǎng)絡(luò)。當(dāng)你表現(xiàn)出很強烈的求知欲時，人們是非常欣賞這點的，會很樂意的幫助你。

保持請求內(nèi)容短小而直接

正如發(fā)送一份郵件，每一次的貢獻，無論是多么的簡單，都是需要他人去查閱的。很多項目都是請求的人多，提供幫助的人少。相信我，保持簡潔，能得到他人幫助的機會會大大增加。

讓所有的溝通都是在公開場合下進行

哪怕是很不起眼的小事，也不要去給維護者發(fā)私信，除非是要分享一些敏感信息（諸如安全問題或嚴重的過失）。若能夠保持談話是公開的，在與很多人的交換意見中你可以學(xué)習(xí)和受益。

大膽但謹慎

每個人參與社區(qū)，開始的時候都是新手，哪怕是非常有經(jīng)驗的貢獻者也一樣，在剛進入一個新的項目的時候，也是新手。出于同樣的原因，甚至長期維護人員也并不總是熟悉一個項目的每一部分，給他們同樣的耐心，會得到同樣的回報。

尊重社區(qū)的決定

你的想法可能會和社區(qū)的優(yōu)先級、愿景等有差異，他們可能對于你的想法提供了反饋和最后的決定，這時應(yīng)該去積極討論，并尋求妥協(xié)的辦法，維護者會慎重地考慮你的想法。但是如果你實在不能同意社區(qū)的做法，可以堅持自己，保持自己的分支，或者另起爐灶。

開源是由來自世界各地的人們共同協(xié)作實現(xiàn)的。面臨的問題是跨語言、跨文化、不同地理位置以及不同時區(qū)，撰寫文字的溝通更是難上加難，無法傳達語氣和情緒。請讓這些會話都充滿善意吧。在以下情形中請保持禮貌：推動一個想法、請求更多的上下文、進一步澄清你的立場。既然你在互聯(lián)網(wǎng)找到了自己的所需，那么請嘗試讓它變得更好。

創(chuàng)建Issue

你應(yīng)該在遇到下列情況時，去創(chuàng)建一個Issue：

報告你自己無法解決的錯誤；

討論一個高級主題或想法；

期望實現(xiàn)某新的特性，或者其他項目的想法。

在Issue的溝通中幾點實用的技巧：

如果你剛好看到一個開放的Issue，恰是打算解決的，添加評論，告訴他人你將對此展開工作，并及時響應(yīng)。這樣的話，可以避免他人重復(fù)勞動。

如果說某個Issue已經(jīng)開放很久了，這可能是已經(jīng)有人正在解決中，又或者是早已經(jīng)解決過了，所以也請?zhí)砑釉u論，在打算開始工作之前，最好是確認一下。

如果你創(chuàng)建了一個Issue，但是沒多久自己解決了，也要添加評論，讓其他人知道，然后關(guān)閉該Issue。記錄本身就是對社區(qū)的貢獻。

創(chuàng)建pull request

在下面的情形時，請務(wù)必使用PR：

提交補?。ɡ?，糾正拼寫錯誤、損壞的鏈接、或者是其他較明顯的錯誤）；

開始一項別人請求的任務(wù)，或者是過去在Issue中早就討論過的。

一個PR并不代表著工作已經(jīng)完成，開啟一個PR，也可能是為了其他人可以觀看或者給作者反饋意見。只需要在子標(biāo)題標(biāo)記為正在進行中（WIP），作者可以在后面添加很多評論。

如果說項目是托管在GitHub上的，以下是總結(jié)出的提交RP的建議：

Fork代碼倉庫克隆到本地，在本地的倉庫配置“上游”為遠端倉庫。這樣可以在提交PR時保持和“上游”同步，會減少很多解決沖突的時間。

創(chuàng)建一個分支用于自己編輯，包含之前和之后的快照。如果改動包含了不同的HTML/CSS，在PR中拖拉相應(yīng)的圖片。

測試你的改動。若測試用例存在的話，跑一遍，以覆蓋你的更改，若沒有的話，則創(chuàng)建相應(yīng)的用例。無論測試是否存在，一定要確保改動不會破壞掉現(xiàn)有的項目。

盡最大的努力和項目現(xiàn)有的風(fēng)格保持一致。這也就是意味著在使用縮進、分號、以及注釋很可能和你自己的風(fēng)格大相徑庭，但是為了節(jié)省維護者的精力，以及未來他人可以更好地理解和維護，還請你容忍一下。

成為一個開源貢獻者

如果你有志于參與開源事業(yè)，可以嘗試從自己最熟悉的項目開始，開源并不是屬于高級開發(fā)者的專屬詞匯，它就是由你我這樣的人在需求、修復(fù)、構(gòu)建中演進下去的。

Lets try it ！