作者:doodlewind

原文地址:https://juejin.im/post/59f98a196fb9a045132a03ed

【開源社區貢獻者】聽起來是個專屬于頂級開發者的頭銜，但它真的有這么遙不可及嗎？下面的分享旨在揭開它的神秘面紗，幫助感興趣的同學更輕松地參與到社區項目中來。

首先需要澄清的是，本文作者自己并不是社區高大上項目的原創作者，只是在一個 5k+ Star，100+ 貢獻者的項目中貢獻排名前十而已（作為參考，Vue 的貢獻者不到 150 人），和《維護一個大型開源項目是怎樣的體驗》這個問題里閃耀的群星相比，只不過是個小透明的存在。不過因為自己也只有一年有余的經驗，在很多方面上和剛剛入門的新人同學們都很相似，因此相信個人經驗能有一定的參考價值，才在此做了些總結。文中如有不妥之處，請 dalao 們斧正。

下文內容主要分為這兩部分：

• 起步與進階，介紹在對編程一無所知的時候，能夠通過什么方式參與到社區中來。以及在有了貢獻的條件后，如何通過 Issue 和 PR 在開源項目中協作。

• 技巧與總結，介紹一些技術性的細節，以及如何在 Github 上商業互吹的溝通技巧。

起步

參與開源項目的主要方式，由易到難不外乎這三種：

• 翻譯文檔

• 報告 bug

• 提交代碼

在起步階段，翻譯文檔的難度無疑是最低的。因為這甚至不需要你編寫或運行任何代碼，只要在編輯頁面里翻譯就足夠了。

以 Mozilla 維護的 MDN 文檔為例，也許有不少同學不知道，MDN 文檔和維基百科一樣，是允許所有用戶編輯的。比如，一篇介紹 CSS 定位方式的 MDN 文檔，頁面頂部大概長這樣：

mdn-large

注意到 Languages 和 Edit 了嗎？你可以在 Languages 里選擇你需要的語言，或者添加新語言的翻譯。如果已有翻譯，可以直接點擊 Edit 編輯！

在翻譯時，Mozilla 的富文本編輯器會分為左右兩個部分，可以直接對照：

mdn-editor

現在只要點擊保存，你就會出現在這個頁面的貢獻者里了！你的更改也會在文檔歷史中保存，所以在提交前不妨檢查下內容吧。另外，并不是一次保存就必須搞定一整篇文檔，寫到一半準備保存的話，可以點擊頁面最下方的 本地化進行中 選項，這樣就能夠在瀏覽頁面中添加一個【翻譯正在進行中】的標識啦。

這個過程里我們似乎一行代碼都沒有寫，那么這有什么用嗎？個人的觀點是，翻譯文檔是一個很好的開始，因為它可以：

• 幫助你更好地理解英文技術文檔的行文結構，為后面和其他開發者的交流打好基礎。后面我們也會提及，很多時候需要為一兩行代碼編寫的文檔遠遠不止一兩行。

• 很大地鍛煉你的行文水平。在初期你可能會寫出比較翻譯腔、不通順的技術文檔，熟悉以后會有很大的進步。

• 讓你的貢獻迅速地得到反饋。MDN 的權重在 Google 并不低，通過 Google 在第一頁查到你翻譯的內容，還是挺有成就感的。

• 提高你自己對文檔內容的了解。以作者本人為例，在了解富文本編輯領域時首先就是從搬運?Mozilla 中的富文本編輯器文檔作為開始，完成翻譯后就這個領域內的基礎概念了然于心了。

除了 MDN 文檔外，中文技術社區也有不少優秀的相關項目可以參與。這方面個人的參與不多，就不班門弄斧了。

進階

只是翻譯文檔的話，你可能很快就會達到【寫膩了】的階段，這時候就不妨來看看更大的世界吧。找一個 Github 上的活躍項目作為開始吧！對于在 Github 上維護的開源項目，主要的參與方式包括 Issue 和 PR 兩種：

Issue

對一個中大規模的開源項目，Issue 主要用來：

• 報告 Bug 與提問

• 提出并討論新特性

• 設定 Todo 目標

需要注意的是，許多項目是有自己的 Discuz 論壇或 Slack 群的，有一些類似【為什么安裝失敗了】的新手向問題可以先在已有 Issue 中搜索，然后再在論壇和 IM 中提出。如果隨意地提出 Issue，很可能會得到 Duplicateof#xxx 的回復然后被關掉。對于新同學，一個非常好的參考是《提問的藝術：如何快速獲得答案》。

只要給項目提出過 Issue，你當天的 Github 貢獻圖就會刷綠，并且也能夠把這個項目固定在個人主頁里了！看起來同樣不需要寫代碼，并不難呀。不過，單純地提 Issue 并不會讓你出現在項目的貢獻者列表里，如果想真正地【貢獻】代碼的話，PR 是必須的。

PR

Pull Request 顧名思義，就是請求別人拉取你的代碼的意思。這是十分符合開源工作流的：開發者們 fork 出自己的倉庫，在自己的 分支里 commit 代碼，然后請求維護者將自己的更改合并進來。一般而言一個 PR 只要做好一件事情就足夠了，其作用不外乎以下之一：

• 修復 bug

• 實現新特性

• 優化性能

• 例行更新（如文檔、依賴版本等）

新同學如果想要貢獻 PR，不妨先從自己擅長或關注的方面去著手，比如一些簡單的文檔拼寫錯誤，或者標記為 help please 一類的 Issue。

只要提出 PR，不論合并與否當天的 Github 貢獻圖都會刷綠，而 PR 合并入主干時，當天的貢獻圖也會刷綠。假設你發現了一個小 bug，只要一行就能夠修復，那么整個流程走下來大概是這樣：

提出 Issue，貢獻 +1

提出 PR，貢獻 +1

回復維護者的 Review 評審，貢獻 +1

PR 通過，貢獻 +1

所以，哪怕僅僅提交一行代碼，最多也足夠點綠四天的貢獻圖了。并且，維護者們在 Review 或并入你的 PR 時，他們的貢獻也會相應增加。這樣想來，大型項目貢獻者們一年動輒幾千的貢獻數量也不是只能讓人仰望的了吧。

技巧

上面僅僅介紹了開源工作流中的幾個基礎概念。在真正參與時，還有一些可以稍加注意的技巧。下面介紹的就是一些與此相關的小細節。

問題導向的源碼閱讀

在需要提出 bugfix、新 feature 或性能優化類 PR 的時候，閱讀框架源碼基本是繞不開的。當然，我們經常能夠在技術社區看到很多【源碼解析】類的文章（在近期以 Redux / Vue / Koa 為甚）。作者寫這些文章的出發點肯定是好的，不過令人有些遺憾的是，許多這類文章的閱讀量相對并不高，并且多數這類文章的作者并不是這些框架的貢獻者。

是我們太浮躁了嗎？我們不妨從動機上考慮一下，我們為什么需要閱讀源碼呢？是為了解決實際遇到的問題，還是僅僅為了寫一篇博客來展示自己的技術水平呢？如果只是貼上一個個看起來高大上的代碼截圖，然后把注釋翻譯成中文，這樣的文章對讀者、對社區又有什么幫助呢？【我讀過這個框架的源碼】和【我修過這個框架的 bug】相比起來，哪個的貢獻更大呢？

個人的觀點是，帶著問題去調試源碼，收獲會比簡單的閱讀理解大很多。在你真正需要解決一個 bug 的時候，你才會真正去思考調用的順序、執行的流程、變量的意義，然后在一個個斷點、日志和錯誤堆棧的幫助下，真正知道一些看起來漫不經心的判斷是多么不可或缺，看似簡單的地方又隱藏著怎樣的預設條件。

從這個角度而言，以修復 bug 的動機驅動去維護開源項目，對技術水平的鍛煉，會比在單純的源碼閱讀或在技術社區里逛博客點贊要來的更高。而每一個發展中的項目，都會有不少已發現或未發現的 bug 等待我們去修復。在這個參與的過程中，你的工作不僅能讓社區收益，也能夠更多地讓自己獲益。

不過，【如何閱讀源碼】已經脫離了本文的討論范圍。在此我們點到為止就足夠了。

友善的互吹評價

參與開源項目和搬運文檔相比，很重要的一點區別在于和其他人之間的互動。你的 Issue 會有人評論、代碼會有人 Review，PR 也會有人點贊。這時候，和其他人的互動是少不了的。在 Github 這樣的英文技術社區，合適的交流方式對促進社區發展是很有幫助的。

這里我們只分享一點：如何更友善地對其他人的工作作出評價。在中文社區，除了【伸手黨】以外，還經常能夠看到【噴子】直接抨擊項目質量或者給人蓋上【抄襲】的帽子。不過，吐槽別人的代碼肯定是少不了的。在社區中交流時怎么樣更委婉地指出 PR 的問題或在 Issue 中回復觀點呢？

很有趣的一點是，在 Github 上很少看到這些詞：

bad wrong dirty terrible ***...復制代碼

更基本看不到這樣的說法：

I think this code is bad and do things wrong!復制代碼

與直接吐槽代碼 bad 相對地，不妨這么說：

• 表達 API 笨重不好用，可以說?heavy to workwith

• 表達模塊結構不好，可以說?notintuitive

• 表達處理方式太粗暴，可以說?overkill

• 表達邏輯可能有漏洞，可以說?leaky

• 表達要引入的東西太多，可以說?aggressive

• ...

而 I think 則顯得非常武斷，可以這樣：

• 萬能的?IMO?或?IMHO，即?Inmy(humble)opinion

• 補充一個?Notsure,maybe missing something

• 用?Tomyknowledge?或者?Forme

以及，在請求其他貢獻者 Review 或合并時，記得加上 Wouldyou please 和 Couldyou please 也是很不錯的。哦對了別忘了 Thanks 啊。

總之探索合適的溝通詞匯是一件很有趣的事情，不過對英語的要求并不高，運用上面的介紹其實只要初中英語水平就足夠了吧…相信有興趣的同學能夠總結出更多【開源黑話】😅另外，不少項目的 Code of Conduct 也值得一讀。

有效的溝通

貢獻社區的過程并不是上來就把代碼砸到人臉上，許多 bugfix 都是需要和上游維護者討論方案后再做決定的。這時除了客氣的言辭外，溝通的方式也很重要。在此個人總結了這么幾點：

提問式的反駁

蘇格拉底有種和人辯論的方式是，不停地向對方提問，直到對方答不上來為止。在社區的交流中，這種方式同樣很常見。

比如，在認為一個 PR 存在著未考慮到的邊界情形時，作為 Reviewer，比起直接判斷 Youare missing XXX，評論 HowisitwhenXXX 就巧妙地【把鍋丟了回去】，能夠客氣地讓提交者進一步說明對特殊情況的判斷或修改代碼，而不是直接【把天聊死】。

同樣地，在不認可某種 Workaround 方式時，回復 I don't know what you mean at... 然后等待對方的解釋，效果也比直接說 Thisiswrong 要更好。

注意描述方式

在提交 Issue 時，不同的描述方式可能會帶來不同的優先級與不同的處理結果。舉一個最近遇到的例子：

我們參與的項目中，有一個描述【性能問題】的 Issue，內容大致是【輸入內容大的時候速度特別慢】。這個 Issue 被晾了一兩周沒有人處理。而我在調試后找到了一個特殊的場景，這時反復的重繪會讓頁面崩潰。在將【頁面死循環】作為標題提交 Issue 后，作者在當天就修復了這個問題，而性能問題也一并解決了。

模板與工具

其實上面的不少內容是有固定的套路可循的。比如，Issue 和 PR 都有相對固定的模板，幫助參與者提高溝通的效率。

對 Issue 來說，常見的模板大致是這樣的三段論：

Bug or Feature?

Current Behavior?

Expected Behavior?

而對于 PR 來說倒不一定需要長篇大論，正式一些的結構大致是：

This Closes #xxx

Current Behavior / Reason

Solution

在提交 Issue 時，提供復現的例子、步驟或 GIF 是非常重要的。這時我們可以用 JSFiddle 提供簡單的復現例子，在 Mac 上也有 Giphy Capture 這樣免費的 GIF 動畫錄制工具來提供幫助。

最后，在 Git 提交時，整潔的提交記錄也是很大的加分項，這方面有興趣的同學不妨參考作者之前的文章：使用 git rebase 提高 PR 質量。

總結

參與到開源社區中是個既有挑戰也有成就感的事情。比起國內互聯網公司常見的招聘 slogan【你的一行代碼，能影響多少多少人】來，貢獻到開源項目中，就意味著【你的代碼能夠被多少多少公司】使用，這無疑是更高的層次，也會有更多的挑戰。如果覺得日常的增查改刪邏輯已經讓你感到厭煩，那么參與到社區中來或許能為你打開新世界的大門。

這里順便安利一下我們目前維護的編輯器項目 Slate。這是一個優秀而迭代迅速的富文本框架，目前還處在大刀闊斧地添加新特性和新功能的 beta 時期，有非常多參與貢獻的機會，源碼的風格與注釋也相當完備。另外有趣的一點是作者和 Evan You 一樣有著設計師的背景（不妨想象一堆程序員給 UI 設計師寫的代碼修 bug 的場景）。我也在之前的博客里安利過 Slate，希望能有更多的同學來嘗鮮！

最后我們引用 Chrome V8 項目的一個原則作為本文的總結吧：

In short, do the right thing for the project, not the easiest thing to get code committed, and above all: use your best judgement.

總結

以上是生活随笔為你收集整理的零起点的开源社区贡献指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。