前言

開(kāi)源這件事情在軟件開(kāi)發(fā)領(lǐng)域一直是一個(gè)高頻話題，我們工作中不管是使用到的工具還是第三方庫(kù)都離不開(kāi)開(kāi)源的支持。

近期由于工作的原因，我需要經(jīng)常和 Apache Pulsar 社區(qū)溝通，同時(shí)也會(huì)將日常碰到的問(wèn)題反饋給社區(qū)，包括一些 bug ，一些我能修的也是順帶就提了一些 PR。

之前或多或少我也參與過(guò)其他的開(kāi)源社區(qū)，但和現(xiàn)在的還是有些許的不同：

• 以前我更多的是個(gè)人開(kāi)源項(xiàng)目，偶爾也會(huì)有其他開(kāi)發(fā)者向我的倉(cāng)庫(kù)貢獻(xiàn)代碼。
• 也參與過(guò)其他個(gè)人作者或者是社區(qū)性質(zhì)的項(xiàng)目，但流程上沒(méi)有那么正規(guī)或者是標(biāo)準(zhǔn)。

簡(jiǎn)單來(lái)說(shuō)就是以前就是小打小鬧，Pulsar 畢竟是 Apache 社區(qū)的頂級(jí)項(xiàng)目，參與的整個(gè)流程要求也會(huì)比較復(fù)雜，當(dāng)然學(xué)到的知識(shí)也會(huì)更多。

image.png

這半年時(shí)間大大小小提了十幾個(gè) PR ，也逐漸捋清楚了一些上手的方法和套路，所以如果你也想?yún)⑴c開(kāi)源，但苦于不知道如何入門，看完后希望對(duì)你有所幫助。

為什么參與開(kāi)源

首先還是來(lái)聊聊參與開(kāi)源的好處，了解之后也許會(huì)讓你有路轉(zhuǎn)粉。

首先最明顯的一點(diǎn)就是讓你對(duì)貢獻(xiàn)的這個(gè)項(xiàng)目更加深入的了解，我們常常都在面試的時(shí)候被問(wèn)到對(duì) XX 框架的熟悉程度，哪怕你在簡(jiǎn)歷里寫(xiě)的天花亂墜也沒(méi)有是這個(gè)項(xiàng)目 Contributor 更具有說(shuō)服力。

其次是溝通交流能力也會(huì)得到鍛煉，開(kāi)源社區(qū)往往都是以 github issue/PR，或者是 Mailing List 的方式溝通交流，這樣的溝通方式和我們常用的微信、QQ 這類及時(shí)通訊工具有著本質(zhì)的區(qū)別。

往往需要我們有了冷靜的思考加上清晰的描述才會(huì)將自己的觀點(diǎn)發(fā)布出去，這樣不自覺(jué)的就會(huì)養(yǎng)成自己的總結(jié)能力，這個(gè)能力對(duì)于內(nèi)容創(chuàng)意內(nèi)容工作者來(lái)說(shuō)非常重要。

還有一個(gè)更明顯的好處就是對(duì)個(gè)人的能力背書(shū)，大家常說(shuō)的 show me the code，而 GitHub 就是最好的方式。

當(dāng)你是某個(gè)知名開(kāi)源項(xiàng)目的 Contributor 甚至是 Committer/PMC 就已經(jīng)足夠證明自己的能力了。

如何參與

如何參與呢，其實(shí)也很簡(jiǎn)單，不外乎有以下幾種方式（由易到難）：

• 一些 typo 類的修復(fù)。
• 回答社區(qū)中用戶的問(wèn)題。
• 使用過(guò)程中遇到 bug，直接反饋，有興趣的話最好是自己能修復(fù)。
• 修復(fù)現(xiàn)有 issue 列表中未解決的 bug。
• 軟件不具備自己需要的功能時(shí)提交 feature 提案并實(shí)現(xiàn)。

不管是哪種方式我的建議是在準(zhǔn)備貢獻(xiàn)之前都應(yīng)該先看看官方提供的貢獻(xiàn)指南，通常在官網(wǎng)就能查看。

即便是最簡(jiǎn)單的修復(fù) typo，因?yàn)樵绞菍I(yè)的項(xiàng)目每個(gè) PR 的合并都是嚴(yán)謹(jǐn)?shù)?，提前了解后可以避免犯一些基本錯(cuò)誤從而影響積極性。

這里我以 Pulsar 為例：

官網(wǎng)有著詳細(xì)的貢獻(xiàn)指南，包括環(huán)境搭建、代碼約定、PR/git commit 語(yǔ)義等各種規(guī)范。

這里我重點(diǎn)強(qiáng)調(diào) PR 的語(yǔ)義，一個(gè)好的 PR 規(guī)范更容易引起社區(qū)成員的注意，畢竟我們每一次提交都需要 Committer 的同意才能合并。

還是以 Pulsar 為例，在提交 PR 前一定得先看看這里的規(guī)范要求，不然很可能第一步就會(huì)吃癟。

可能遇到的問(wèn)題

下面講講貢獻(xiàn)過(guò)程中可能會(huì)碰到的問(wèn)題。

在上面講到的難度排序中將修復(fù)個(gè)人 issue 排在了其他 issue 之前了，這是因?yàn)橥鶎?duì)自己提交的 bug 更熟悉，而社區(qū)其他人反饋的問(wèn)題大概率會(huì)被老手認(rèn)領(lǐng)。

加上自己也不熟悉，可能在自己研究復(fù)現(xiàn)的過(guò)程中就把自己勸退了。

認(rèn)領(lǐng) issue

這里還有個(gè)小技巧，當(dāng)我們準(zhǔn)備修復(fù)一個(gè)不是自己提交的 issue 時(shí)，最好是在評(píng)論區(qū)讓 Committer 將這個(gè)任務(wù)分配給你，這樣社區(qū)成員就不會(huì)做重復(fù)工作了。

類似于這樣。

同時(shí)我們?cè)诓檎铱梢孕迯?fù)的 issue 時(shí)也要注意這個(gè) issue 有沒(méi)有被認(rèn)領(lǐng)以及是否有 PR 關(guān)聯(lián)。

image.png

有時(shí)候 issue 并沒(méi)有被指定但也有相關(guān) PR 在處理該問(wèn)題了，這時(shí)我們就可以過(guò)濾掉這個(gè) issue。

help want

也可以找找?guī)в?nbsp;help want 標(biāo)簽的 issue，這類問(wèn)題往往會(huì)相對(duì)簡(jiǎn)單，修復(fù)起來(lái)也更容易。

社區(qū)反饋較慢

還有一個(gè)比較常見(jiàn)的問(wèn)題是自己提交的 issue 或者是 PR 遲遲沒(méi)有人處理。

我們可以先看看這個(gè) issue 對(duì)應(yīng)的代碼最近主要是哪些人在維護(hù)，這個(gè)在 IDE 中配合 GitToolBox 插件就很容易看出來(lái)。

后面的 ID 往往是 PR 號(hào)，我們可以通過(guò)這個(gè) PR 找到對(duì)應(yīng)的作者，然后嘗試在 issue 評(píng)論區(qū)艾特對(duì)方。

如果依然沒(méi)有回復(fù)，那我們也可以給開(kāi)發(fā)組發(fā)送郵件。

如果還是沒(méi)有回復(fù)，比如我這個(gè)

那也還有一個(gè)辦法，就是嘗試在社交媒體（GitHub 首頁(yè)、技術(shù)群）上找到 Committer 的微信，直接私聊的方式讓對(duì)方幫忙推進(jìn)。

當(dāng)然也有一些項(xiàng)目長(zhǎng)期沒(méi)有維護(hù)了，這種 PR 要做好心里準(zhǔn)備，很有可能對(duì)方不會(huì)理你；這點(diǎn)在國(guó)內(nèi)某個(gè)企業(yè)的開(kāi)源項(xiàng)目中比較常見(jiàn)。

總結(jié)

總的來(lái)說(shuō)想要做好開(kāi)源得有耐心和長(zhǎng)期堅(jiān)持，同時(shí)給自己帶來(lái)的好處也是物超所值的，Apache 這類專業(yè)的社區(qū)我也才參與了半年，后續(xù)也會(huì)長(zhǎng)期堅(jiān)持下去，也希望哪天可以積累到成為 Committer 后再和大家分享。