學(xué)習(xí)資料：開源軟件指南（Open Source Guides，GitHub：XNoteW/opensource.guide）

為什么會有人為開源做貢獻(xiàn)？

為開源貢獻(xiàn)力量，得到的回報(bào)就是能夠?qū)W習(xí)到很多、受教很多、且能夠鍛煉任何你能夠想到的經(jīng)驗(yàn)。

鞏固現(xiàn)有技能

無論是撰寫代碼、設(shè)計(jì)用戶界面、圖形設(shè)計(jì)、撰寫文檔、亦或是組織活動，假如你有實(shí)踐的愿望，你總能在開源項(xiàng)目中找到自己的位置。

遇見那些和你”臭味相投”的人

開源項(xiàng)目一般都會有一個和諧、熱心的社區(qū)，以讓大家團(tuán)結(jié)一致。實(shí)際上，開源界經(jīng)常發(fā)生這樣的情形，很多人的深厚友誼都是通過共同參與開源所建立起來的，至于具體的方式，可能是在一次技術(shù)研討會上相談甚歡，也可能是一直在聊天室中探討問題。

尋找導(dǎo)師，并且嘗試幫助他人

和他人共同在一個共享的項(xiàng)目下工作，這意味著需要向他人解釋清楚自己是如何做的，同理，也需要向他人求助，詢問別人是如何做的。相互學(xué)習(xí)和彼此教學(xué)對于每位參與者都能滿載而歸。

在公眾間建立你的聲譽(yù)（職業(yè)口碑）

根據(jù)開源的定義，你在開源下所有的工作都是公開的，這也就意味著開源項(xiàng)目是一個很好展示你實(shí)力的地方。

學(xué)習(xí)領(lǐng)導(dǎo)和管理的藝術(shù)

開源為實(shí)踐領(lǐng)導(dǎo)力和管理技能提供了很好的機(jī)會，比如解決沖突、組織團(tuán)隊(duì)、工作的優(yōu)先級排列。

鼓勵作出改變，哪怕改變是很微小的

在開源的世界里，作出貢獻(xiàn)的不一定非得是花了很長時間擁有大量經(jīng)驗(yàn)的人。你是否遇到過瀏覽某些網(wǎng)站發(fā)現(xiàn)有拼寫錯誤，希望有人能修改它？其實(shí)，在開源的項(xiàng)目中，你只需要做就可以了。沒有那么多的顧忌，開源讓人們在很舒服的狀態(tài)做事，而這才是這個世界應(yīng)有的體驗(yàn)。

開源貢獻(xiàn)意味著什么？

如果你是一名開源界的新手，可能會對貢獻(xiàn)的流程心生畏懼。比如：該如何找到正確的項(xiàng)目？不懂編碼又想?yún)⑴c怎么辦？萬一做錯事情了怎么辦？

你不需要具備編碼的能力

對于為開源做貢獻(xiàn)常見的誤解就是：為開源做貢獻(xiàn)必須得提交代碼。事實(shí)上，代碼固然重要，但是項(xiàng)目中不需編碼的重要部分經(jīng)常被忽視。你若做了這部分，對于項(xiàng)目來說可是莫大的貢獻(xiàn)，而這根本就不需要什么撰寫代碼！

即使你是一位開發(fā)者，非代碼的貢獻(xiàn)對于項(xiàng)目來說也是舉足輕重的，尤其是對于社區(qū)的其他成員來說。用心維系這些關(guān)系能夠讓你有到項(xiàng)目的其它部分的工作機(jī)會。

是否熱衷于規(guī)劃事件？

• 為項(xiàng)目組織研討會或線下分享，一如 @fzamperin 為 NodeSchool 所做的那樣
• 為項(xiàng)目組織大型會議（假如它有的話）
• 幫助社區(qū)成員尋找合適的技術(shù)會議，且?guī)椭袑?shí)力的成員提交演講的擬稿

是否偏向于設(shè)計(jì)？

• 重新布置布局以提高項(xiàng)目的可用性
• 進(jìn)行用戶研究以重新組織和完善項(xiàng)目的導(dǎo)航或菜單
• 整理一個風(fēng)格指南，以幫助項(xiàng)目有一致的視覺設(shè)計(jì)
• 創(chuàng)建 t 恤的藝術(shù)或一個新的標(biāo)志，就像 hapi.js 的貢獻(xiàn)者那樣

你是否熱衷于寫作？

• 撰寫和改進(jìn)項(xiàng)目的文檔
• 能夠以實(shí)例來展示項(xiàng)目該如何使用的
• 為項(xiàng)目撰寫新聞稿，或者到郵件列表高調(diào)布道
• 為項(xiàng)目撰寫教程，一如 pypa 的貢獻(xiàn)者所做的
• 翻譯項(xiàng)目的文檔為本土語言

你喜歡組織活動嗎？

• 鏈接重復(fù)的問題，并建議新的問題標(biāo)簽，使事物井井有條
• 通過開放的問題，并建議關(guān)閉舊的，就像 @nzakas 為 eslint 做的
• 把最近開放的問題闡述清晰，以推動討論

享受編碼的樂趣？

• 找到一個開放的問題并解決它，就像 @dianjin 為 Leaflet 做的
• 想一想你是否可以幫忙寫一個新的功能
• 自動化項(xiàng)目設(shè)置
• 改進(jìn)工具和測試

熱衷于幫助他人？

• 回答關(guān)于項(xiàng)目的問題，例如在 Stack Overflow（像 Postgres 的這個示例）或者 reddit 上
• 為人們解答公開的問題
• 幫助緩和討論板或?qū)υ捛?/li>

在編碼方面是否喜歡幫助他人？

• 為他人的提交審核代碼
• 為如何利用項(xiàng)目撰寫教程
• 為其他貢獻(xiàn)者做導(dǎo)師，正如 @ereichert 為 @bronzdoc 所做的那樣，哦，是 Rust 項(xiàng)目

其實(shí)不必一定是軟件項(xiàng)目！

盡管人們一提起”開源”二字，默認(rèn)就是指開源軟件，其實(shí)不盡然，開源可以是任何事情的修飾，而不僅僅是指軟件而言的。比如圖書、食譜、列表、以及任何可以開源的項(xiàng)目類。

舉例來說：

• @sindresorhus 創(chuàng)建了 “驚奇” 列表
• @h5bp 維護(hù)了針對前端開發(fā)者的面試題
• @stuartlynn 和 @nicole-a-tesla 制作了收集關(guān)于海雀的有趣的事實(shí)

盡管你是一名軟件開發(fā)者，也可以去撰寫一些文檔去幫助新的入門者。其實(shí)項(xiàng)目中那些看起來令人生畏的項(xiàng)目并不是寫代碼，做開發(fā)者總得挑戰(zhàn)自己，其實(shí)在做得過程中可以增強(qiáng)信心和獲得全新的體驗(yàn)。

分析感興趣的開源項(xiàng)目

每一個開源社區(qū)都是不一樣的。

在某一個開源項(xiàng)目扎根多年，這意味著你只是對這一個開源項(xiàng)目無比的熟悉。若是切換到不同的項(xiàng)目，可能會發(fā)現(xiàn)完全是另外一回事，所謂的使用詞匯、習(xí)慣用語、溝通方式都發(fā)生了變化。

然而，很多的開源項(xiàng)目還是遵循相似的組織結(jié)構(gòu)的。理解不同的社區(qū)角色和全部的流程，可以很好的幫助你快速的切入新的項(xiàng)目。

一個典型的開源項(xiàng)目均會有如下類型的人：

• 作者: 項(xiàng)目的創(chuàng)始人或創(chuàng)始組織
• 歸屬者: 代碼倉庫或組織的管理員（不一定和作者是同一個人）
• 維護(hù)者: 貢獻(xiàn)者，負(fù)責(zé)項(xiàng)目的未來走向和組織的管理（他們通常也是項(xiàng)目的作者或歸屬者。）
• 貢獻(xiàn)者: 只要是為項(xiàng)目做出了貢獻(xiàn)，就算。
• 社區(qū)成員: 那些使用項(xiàng)目的人們。他們或許是積極的討論者，又或者是為項(xiàng)目的方向提出意見的人。

一個較大的項(xiàng)目，可能下面還會細(xì)分子社區(qū)，或者是針對不同的任務(wù)分成不同的小組，比如工具小組、分流、社區(qū)事務(wù)、以及活動組織等。徑直到項(xiàng)目到 web 站點(diǎn)，找到”團(tuán)隊(duì)”頁面，或者是查看治理文檔，從而獲得類似到信息。

靠譜的開源項(xiàng)目，一般都會有文檔的，這些文檔文件通常會在代碼倉庫的頂級目錄列出。

• LICENSE: 根據(jù)開源軟件的定義，每一個開源項(xiàng)目必須是有開源許可協(xié)議的. 可以這么認(rèn)為：假如說某個項(xiàng)目源碼開放，但是沒有任何的許可協(xié)議，那么它就不能叫做開源。
• README: README 是一個介紹性的說明文件，對初次光臨社區(qū)的人們表示歡迎，它通常會解釋項(xiàng)目有何用處，為何發(fā)起，以及如何快速入門等。
• CONTRIBUTING: READMEs 幫助人們來認(rèn)識項(xiàng)目，CONTRIBUTING 這個文件則是幫助對項(xiàng)目如何做貢獻(xiàn)。它解釋了目前項(xiàng)目需要什么樣類型對貢獻(xiàn)者，社區(qū)的流程是什么樣的。并非所有的項(xiàng)目都會有這個文件，它某種程度上也是展示項(xiàng)目對于貢獻(xiàn)者的友好程度。
• CODE_OF_CONDUCT: 顧名思義，即是一些參與社區(qū)時的一些禮儀、說話方式、行為等，幫助形成一種友好的氛圍，不是所有的項(xiàng)目都會撰寫行為準(zhǔn)則文件，它某種程度上也是展示項(xiàng)目對于貢獻(xiàn)者的友好程度。
• 其它文檔: 有些項(xiàng)目也許還有其它文檔，例如教程、導(dǎo)游，或者是治理規(guī)則，這在大型項(xiàng)目中常見。

此外，開源項(xiàng)目還會利用如下一些工具來進(jìn)行組織討論，閱讀這些歸檔對于理解社區(qū)的想法、是如何工作的有非常大的作用。

• 問題追蹤:（Issue tracker） 這里是人們討論項(xiàng)目相關(guān)問題的地方。
• Pull requests: 審核代碼、以及相關(guān)的問題討論。
• 論壇或郵件列表: 一些項(xiàng)目會實(shí)用會話式的主題（例如 “How do I…“ 或 “What do you think about…“ 來替代 Bug 報(bào)告或特性請求）。然而有一些項(xiàng)目關(guān)于討論全部實(shí)用問題追蹤。
• 即時在線聊天: 有一些項(xiàng)目會實(shí)用聊天頻道（諸如 Slack 或 IRC），從而能夠隨意的談話、協(xié)作和快速交流

找一個合適的項(xiàng)目做貢獻(xiàn)

你也可以利用如下列出的資源來找到合適的新項(xiàng)目：

• GitHub 探索
• Open Source Friday
• First Timers Only
• CodeTriage
• 24 Pull Requests
• Up For Grabs
• 像忍者一樣貢獻(xiàn)

在你貢獻(xiàn)之前需要一份檢查列表

當(dāng)你找到了你打算貢獻(xiàn)的項(xiàng)目時，在進(jìn)一步行動之前，作一個快速的掃描工作，以確保項(xiàng)目是否接受貢獻(xiàn)的。否則，你煞費(fèi)苦心的工作可能沒有任何的回報(bào)。

這是一個簡易的檢查表，用來評估一個項(xiàng)目是否適合新的貢獻(xiàn)者。

符合開源的定義

• 有許可協(xié)議嗎？通常情況下，會在根目錄有一個叫做 LICENSE 的文件。

項(xiàng)目被接收的提交活躍度

在主干上確認(rèn)提交的活躍度。在 GitHub 上托管的開源項(xiàng)目，你可以在倉庫主頁上看到這些信息。

• 最后一次提交是在什么時候？

• 項(xiàng)目目前有多少貢獻(xiàn)者？

人們提交的頻繁嗎？ (在 GitHub，可以在頂欄里點(diǎn)擊"commits"來展現(xiàn)。）

接下來，就是看項(xiàng)目的 issue 數(shù)量。

• 目前有多少個還處于開放狀態(tài)的 issue？

• 項(xiàng)目的維護(hù)者對于處于開放狀態(tài)的 issue 響應(yīng)是否迅速？

• 是否有討論很活躍的 issue？

• issue 均是近期產(chǎn)生的嗎？

• 有沒有關(guān)閉的issue？ (在 GitHub, 點(diǎn)擊 "closed" 標(biāo)簽就可以看到所有已經(jīng)關(guān)閉的 issue。)

同樣再來看看 PR 的情形。

• 現(xiàn)下有多少處于開放狀態(tài)的 PR？

• 當(dāng)提交了 PR 后，維護(hù)者響應(yīng)是否迅速？

• 是否有活躍討論的 PR？

• 均是近期的 RP 嗎？

• 最近有多少 PR 合并？ (在 GitHub, 點(diǎn)擊 RP 頁面的 "closed" 的標(biāo)簽頁來查看已經(jīng)關(guān)閉的標(biāo)簽頁。)

項(xiàng)目的受歡迎程度

一個項(xiàng)目的友好程度和受歡迎意味著更能吸引新的貢獻(xiàn)者。

• 在 issue 的問題中，維護(hù)者的回答是否非常有幫助？

• 人們在 issue 的討論中、在線聊天室、論壇是否很友好？

• PR 是否被 review？

• 維護(hù)者是否對做貢獻(xiàn)的人們道聲"謝謝"？

如何提交貢獻(xiàn)

你已經(jīng)找到了你喜愛的項(xiàng)目，也已準(zhǔn)備好貢獻(xiàn)了，迫不及待、躍躍欲試了。好吧！以下就是帶領(lǐng)你如何以正確的姿勢作貢獻(xiàn)。

有效溝通

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

avatar

[作為一名新手,] 我很快的就意識到，我若是要關(guān)閉一條 issue 時，我不得不問更多的問題。我瀏覽了代碼庫，一旦我覺得有什么問題的時候，我就得需要更多的指點(diǎn)，瞧！ 在我得到所有的所需要的信息后，我就可以解決這個問題！

— @shubheksha, 一名菜鳥進(jìn)入開源世界的坎坷之旅

在你開啟一個 issue 或 PR 之前，或者是在聊天室問問題之前，請牢記下面所列出的幾點(diǎn)建議，會讓你的工作更加的高效。
給出上下文 以便于讓其他人能夠快速的理解。比方說你運(yùn)行程序時遇到一個錯誤，要解釋你是如何做的，并描述如何才能再現(xiàn)錯誤現(xiàn)象。又比方說你是提交一個新的想法，要解釋你為什么這么想，對于項(xiàng)目有用處嗎（不僅僅是只有你?。?/p>

?? “當(dāng)我做 Y 的時候 X 不能工作”
?? “X 出問題! 請修復(fù)它?！?/p>

在進(jìn)一步行動前，做好準(zhǔn)備工作。 不知道沒關(guān)系，但是要展現(xiàn)你嘗試過、努力過。在尋求幫助之前，請確認(rèn)閱讀了項(xiàng)目的 README、文檔、問題（開放的和關(guān)閉的）、郵件列表，并搜索了網(wǎng)絡(luò)。當(dāng)你表現(xiàn)出很強(qiáng)烈的求知欲的時候，人們是非常欣賞這點(diǎn)的，會很樂意的幫助你。

?? “我不確定 X 是如何實(shí)現(xiàn)的，我查閱了相關(guān)的幫助文檔，然而毫無所獲。”

?? “我該怎么做 X ?”

保持請求內(nèi)容短小而直接。 正如發(fā)送一份郵件，每一次的貢獻(xiàn)，無論是多么的簡單，都是需要他人去查閱的。很多項(xiàng)目都是請求的人多，提供幫助的人少。相信我，保持簡潔，你能得到他人幫助的機(jī)會會大大的增加。

?? “我很樂意寫 API 的教程?！?br> ?? ” 有一天我駕駛汽車行駛在高速公路上，在某個加油站加油的時候，突發(fā)奇想，我們應(yīng)該這么做，不過在我進(jìn)一步解釋之前，我先和大家展示一下。。?！?/p>

讓所有的溝通都是在公開場合下進(jìn)行。 哪怕是很不起眼的小事，也不要去給維護(hù)者發(fā)私信，除非是你要分享一些敏感信息（諸如安全問題或嚴(yán)重的過失）。你若能夠保持談話是公開的，很多人可以你們交換的意見中學(xué)習(xí)和受益。

?? (評論) “@維護(hù)者 你好！我們該如何處理這個 PR？”
?? (郵件) “你好，非常抱歉給發(fā)信，但是我實(shí)在很希望你能看一下我提交的 PR。”

大膽的提問（但是要謹(jǐn)慎?。?/strong>。 每個人參與社區(qū)，開始的時候都是新手，哪怕是非常有經(jīng)驗(yàn)的貢獻(xiàn)者也一樣，在剛進(jìn)入一個新的項(xiàng)目的時候，也是新手。出于同樣的原因,甚至長期維護(hù)人員并不總是熟悉一個項(xiàng)目的每一部分。給他們同樣的耐心，你也會得到同樣的回報(bào)。