如何為開源做貢獻？

在開源專案[freenode]的工作讓我學習到許多技能，這些技能在我往後大學研究及實際 ... 即使你是一個軟體開發者，撰寫說明文件也能幫助剛加入開源的你去更加的認識它。

關於 貢獻 Deutsch English Español Farsi Français Magyar Indonesia 日本語 한국어 Malay Nederlands Polski Português Romanian Русский தமிழ் Türkçe 简体中文 繁體中文 OpenSourceGuides 為何要為開源貢獻心力？ 在開源專案[freenode]的工作讓我學習到許多技能，這些技能在我往後大學研究及實際工作上有許多幫助，我在開源專案的貢獻跟收穫一樣多！ —@errietta,“為什麼我熱愛貢獻心力在開源軟體上” 透過為開源貢獻力量，能從中學習、幫助他人並且從中累積相關技能的經驗-任何你能想像得到的技能。

為什麼會有人為開源做出貢獻？有數不清的原因！ 鞏固現有技能 無論是撰寫程式碼、設計使用者介面、平面設計，撰寫文章或是組織活動，只要你有意願實踐，你總能在開源專案中找到自己的位置。

認識那些與你有相似興趣的人 一個友善、溫暖的開源社群會讓人們持續的參與。

許多人透過參與開源建立了深厚的友誼，可能是在一次的技術研討中，也可能是在線上聊天室的閒聊中發生。

尋找導師，並且嘗試幫助他人 與他人在共享的專案中工作，你會需要向他人解釋自己是如何做的，同時也需要向他人求助。

每個參與開源的人都教學相長。

在公眾建立你的名聲（以及職業名聲） 根據開源的定義，你在開源裡的所有工作都是公開的，這也意味開源專案是一個能好好展現你實力的地方。

學習人際交往的能力 開源為練習領導及管理的能力提供了很好的機會。

例如如何解決衝突、組織團隊以及如何為工作的優先順序排列。

鼓勵作出改變，哪怕只是很微小的改變 你不一定要持續不斷的貢獻開源才能享受參與的樂趣。

你是否曾在某個網站上發現拼寫錯誤，並希望有人能夠修改它？在開源專案中你可以親自修正這樣的錯誤即可。

開源讓人們自在的做事，而這正是這個世界應有的體驗。

具體而言什麼是貢獻 如果你是一名開源世界的新手，可能會對貢獻的流程心生畏懼。

如何找到適合彼此的專案？不會寫程式又想參與怎麼辦？萬一中間出了差錯怎麼辦？ 不用擔心！條條大路通羅馬，有很多能參與開源專案的方式。

以下是一些實用的技巧，幫你快速的獲得經驗。

你不一定要會寫程式才能貢獻 對開源做出貢獻常見的誤解之一就是：要寫程式才算貢獻。

其實專案裡不需編碼的工作也是經常被忽視的部分。

你對專案所做的非程式類貢獻，其實是對專案來說莫大的幫助！ 我被大家所熟知是因為為CocoaPods做了一些事,但大多數人並不知道我實際並沒有為CocoaPods本身做了什麼，我多數的工作是撰寫說明文件與品牌宣傳的事情。

—@orta,“將自己預設為開源軟體” 即便你樂於寫程式，撰寫程式以外的貢獻對於專案來說也是舉足輕重的，維繫這樣的關係也能讓你獲得與專案的其他成員共事的機會。

我第一次接觸Python開發團隊（簡稱python-dev）是在2002年6月17日，當時我向郵件列表寄了一份請求接受補丁的信，接著我決定為工作小組蒐集整理郵件摘要，後來他們甚至給了我一個機會去諮詢某個主題，這當中的關鍵是，我能注意到有人指出哪些東西必須要處裡。

—@brettcannon,“系統維護者的故事” 你是否熱衷於規劃活動？ 為專案舉辦一個工作坊或線下聚會，例如@fzamperin為NodeSchool所做的 為專案舉辦一個大型會議﹝如果它有需求的話﹞ 幫助社群成員找到合適的會議，或是協助成員找到窗口提交演講的提案。

你是否喜愛設計？ 重新佈置佈局以提高專案的可用性 做一份使用者調查去整頓與完善專案導覽或菜單，像Drupal所提出的建議 整理一個風格指南，以幫助專案有一致的視覺設計方針。

透過藝術創作設計T恤或畫一個新標誌，就像hapi.js的貢獻者所做的 你是否熱愛寫作？ 撰寫和改善專案的說明文件 策劃一個資料夾來蒐集專案的實際應用案例 辦一個專案的電子報，或者蒐整郵件列表的摘要 寫一個專案教學，就像PyPA的貢獻者做的 翻譯專案的說明文件 講真的，[說明文件]是至關重要的。

目前Babel的說明文件已經很棒了，這也是它傑出的特色之一。

有些段落還需要加強或者補上一個句子，有些段落是很值得讚賞的。

—@kittens,“貢獻者召集令” 你喜歡組織活動嗎？ 指認出過去討論過或重複的議題、推薦一個新的議題類別，讓事物井井有序 瀏覽在開放狀態（open）的議題，並建議將已經處於開放狀態很久的議題設為已結束（closed）就像@nzakas在專案eslint做的 鼓勵最近才剛提問的人將疑問闡釋清楚，加速討論的進展 你喜歡寫程式？ 嘗試解決一個開放狀態（open）的議題（issue）就像@dianjin在Leaflet做的 想想自己是否能協助開發一個新功能？ 將專案建置變得自動化 改善工具及測試方法 你喜歡幫助他人？ 回答有關於專案的問題，例如在StackOverflow(Postgres的展示範例)或者reddit上 回答處於開放狀態的議題 鼓勵、協助創造友善的討論區禮儀 你喜歡協助他人改善它的程式嗎？ 為他人貢獻的程式碼做程式碼審查 寫一個教學向大家介紹如何使用該專案 當其他貢獻者的導師，像在Rust專案中@ereichert為@bronzdoc做的 其實不一定要是開源軟體的專案！ 雖然很多人提到「開源」兩字是指「開源軟體」，其實不盡是如此，許多事物你都可以開源協作，你可以開源一本書、開源食譜、開源一張你整理的清單，都可以像開源軟體一樣發展你想製作的東西。

舉例來說： @sindresorhus蒐集了「驚奇」（awesome）列表 @h5bp維護了針對前端開發者的面試題 @stuartlynn和@nicole-a-tesla蒐集了關於海鸚的小知識 即使你是一個軟體開發者，撰寫說明文件也能幫助剛加入開源的你去更加的認識它。

這通常也能讓你以一個不用接觸程式碼的方式自在的參與專案，當中協作的過程亦能建立你的信心與經驗。

根據專案定位自我 如果你嘗試使用Issuetracker去了解一件Issue，看完後還是滿腹疑惑，其他的人一定也會。

要能會活用這些工具有許多小訣竅，總會有人教你怎麼使用，你也可以直接向他們提出問題。

—@shaunagm,“如何為開源做貢獻” 除了錯誤檢查錯字的簡單工作之外，為開源做貢獻有時就像是走進陌生人群嘗試融入一樣。

如果這群人已經討論西討論得的非常深入了，你突然加入劈頭就開始講東，肯定會讓人覺得你有點奇怪。

與其盲目地在社群中拋出你自己的看法，不如先觀察一下社群的氛圍後再提出，這樣你的想法被注意到的機會才會增加。

剖析一個開源社群 每一個開源社群都不盡相同。

在某個開源專案中耕耘多年，意味著你只是對這一個開源專案很熟悉。

若是轉換到不同的專案，你可能會發現社群的規範、用字遣詞與溝通方式都變得不一樣了。

很多開源專案還是都遵循著組織架構的。

嘗試認識不同社群角色和整體流程，能幫助你在加入一個新的專案時快速的找到你的定位。

一個典型的開源專案都會有下列的這些人： 作者:專案的發起者或發起的社群 擁有者:有權限直接修改程式碼或修改文件的管理員（不一定和作者是同一人） 維護者:貢獻者，負責專案的方向和組織的管理（他們通常也是專案的作者或擁有者。

） 貢獻者:只要是爲專案做出了貢獻的人。

社群成員:專案的使用者，他們有時會積極的參與討論或是表達他們對專案走向的看法。

一個較大的專案，可能底下還會細分子社群，或是針對不同任務組成的工作小組，比如負責打造工具的小組、引導社群力量的人、負責社群管理以及組織活動的小組等。

試著找找看專案網站上「團隊介紹」的頁面，或著也能從說明成員編組的文件中找到更多這類的訊息。

專案會有一系列的說明文件，這些文件通常會在根目錄上找得到清單。

許可協議（LICENSE）:根據定義，每個開源專案都必須有個開源許可協議。

如果專案沒有的話，那它不能算是個開源社群。

README:README是一個引導手冊，對剛加入社群的人們表示歡迎，它通常會解釋專案有何用處，為何發起，以及如何快速入門等。

貢獻（CONTRIBUTING）:README幫助人認識與使用專案，「貢獻」這個文件則是針對想對專案貢獻的人寫的指南。

它會說明目前專案需要怎樣類型的貢獻者，並介紹貢獻時的流程是如何進行。

並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。

行爲準則（CODE_OF_CONDUCT）:這份文件裡頭設立了基本規範來約束參與者的行為以及提醒應有的禮儀，並非所有的專案都會有這個文件，但如果有的話某種程度上也是向有意貢獻的人表達友善的意思。

其它文件:有些專案也許還有其它文件，例如教學、專案導覽，或者是管理政策，這在大型專案中常見。

此外，開源專案還會利用如下列的一些工具來進行組織討論，閱讀這些檔案對於理解社群的想法、是如何工作的有非常大的作用。

問題追蹤（Issuetracker）:這裡是人們討論專案相關問題的地方。

請求提取（Pullrequests）:這裡給人們檢查程式碼、以及相關問題的討論。

論壇或郵件列表:一些專案會利用對話式的方式討論主題（例如“HowdoI…“或“Whatdoyouthinkabout…“來替代回報Bug或特別的請求）。

然而有一些專案討論過程都全程使用問題追蹤。

即時在線聊天:有一些專案會使用聊天頻道（諸如Slack或IRC），能夠隨意的談話、協作和快速的交換意見。

找尋專案開始貢獻 讀到這裏，已經對開源專案如何運作有了進一步的了解，是該找一個合適的專案做貢獻的時候了！ 如果你從來都沒有爲開源做過貢獻的話，那麼請謹記來自美國總統約翰F.肯尼迪的這段話：「不問國家能爲你做什麼，要問你能爲國家做什麼。

」 開源專案的每個面向與跨專案間都需要貢獻者，先不用太鑽牛角尖的去想你一定要先在那做貢獻，或是做得好不好。

不如從你使用過的或將來會使用到的專案開始貢獻，你特別關注的專案才會是你會自願積極參與的專案。

參與的過程中，如果有任何點子，覺得可以讓專案更好或更不一樣的，就依你的直覺行事。

開源並不是會員專屬的俱樂部；它就是由你這樣的人所打造。

「開源」只是針對這個世界的需要修復的問題的一個夢幻術語罷了。

你或許在查看README的時候，發現了失效的超連結、或發現了錯字。

又或者你在使用的過程中發現了問題、某件你真的覺得該寫進說明文件的議題，與其視而不見或請別人處理，試著自己投入看看是否有你能幫上忙的地方，這就是開源的精神！ 平均一個專案有28%的貢獻是隨意且偶然的，像是寫說明文件、修正錯字、調整格式或翻譯。

你也可以利用如下列的資源來找到合適的新專案： GitHub探索 FirstTimersOnly 你的第一個PR CodeTriage 24PullRequests UpForGrabs 貢獻忍者 最初的贡献 SourceSort 提交貢獻前應做的檢查清單 當你找到了你打算貢獻的專案時，在有任何行動之前，先整體做個瀏覽，確保專案是願意接受貢獻的。

否則，你辛勤的工作可能沒有任何的回報。

以下是一個簡易的檢查表，用來評估一個專案是否適合新的貢獻者。

符合開源的定義 有許可協議嗎？通常會在根目錄有一個叫做LICENSE的文件。

專案是否積極地接受各方的貢獻 在mainbranch上看看提交的活躍度。

在GitHub上託管的開源專案，你可以在專案主頁上看到這些訊息。

最近的一次提交是在什麼時候？ 專案目前有多少貢獻者？ 提交的次數頻繁嗎？（在GitHub，你可以點擊"commits"來查看。

） 接下來，就是看專案issue的數量。

目前有多少個還處於開放狀態的issue？ 專案的維護者對於開放狀態的issue回覆是否迅速？ 是否有討論很頻繁的issue？ issue都是最近提的嗎？ issue是否都會一個個地被標為結束？（在GitHub,點擊"closed"標籤就可以看到所有已經結束的issue。

） 同樣再來看看PR的情形。

現在有多少處於開放狀態的PR？ 當提交了PR後，維護者的回覆是否迅速？ 是否有討論很熱烈的PR？ 都是最近發的的PR嗎？ 最近有多少PR合併？（在GitHub,點擊PR頁面的"closed"的標籤頁來查看已經關閉的標籤頁。

） 專案是友善的 一個專案的友好程度意味着更能接納新的貢獻者。

在issue的問題中，維護者的回答是否有幫助？ 人們在issue的討論中、聊天室、論壇是否親切？ PR是否被審查過？ 維護者是否對付出貢獻的人們表達謝意？ 當你看到一個很長的對話時，來自核心開發者的零星的回覆排在列表的後面。

你就得想想，他們是否在作建設性的總結？是否保持風度的情況下做出最後的決定？如果你看到的是更多的口水仗，這通常代表社群的能量都在拿來爭論，已經不在開發上了。

—@kfogel,開源軟體生產力 如何提交成果 你已經找到了你喜愛的專案，也已準備好貢獻了，接下來就剩思考如何以一個適當的方式去貢獻。

有效溝通 無論你只是一次性的貢獻，或是決定長期參與社群，在開源的世界裡，學會如何與他人共事是很重要的技能之一。

[作爲一名新手,]我很快的就注意到，若嘗試要解決一條issue時，我不得不向社群提問題。

我瀏覽了程式碼，一旦對議題有一定程度的了解後，我就會去社群徵詢一些指南，然後嘩啦！在我得到所有的所需要的訊息後，我就有能力親自解決這個問題！ —@shubheksha,一名菜鳥進入開源世界的顛頗之旅 在你提出一個issue或PR之前，或者是在聊天室提問之前，請謹記下面所列出的幾點建議，會讓你的工作更有效率。

交代來龍去脈。

以便於讓其他人能夠快速的理解。

比方說執行程式時遇到一個錯誤，你要解釋你當時是想做甚麼，並描述如何做才能重現錯誤。

又比方說你是提交一個新的想法，你要解釋爲什麼這麼想，為什麼你認為這點子對專案會有幫助（而不是只對你有幫助！） 😇“當我做Y的時候X功能沒有正常運作” 😢“X出問題!請修好它。

” 在進一步行動前，做好準備工作。

不知道沒關係，但至少你要先嘗試過、努力過。

在尋求幫助之前，請確認閱讀了專案的README、文件、issue（open的和closed的）、郵件列表，並在網絡上查查看。

當你表現出很強烈的求知慾時，人們會很樂意的幫助你的。

😇“我不確定X是如何做到的，我查閱了說明文件，但沒有找到相關的介紹。

” 😢“我該怎麼做X這件事?” 溝通時力求精簡明瞭。

就像發送一份郵件、每一次的貢獻，無論是多麼的簡單，都是需要他人去檢閱的。

很多專案都是請求的人多，提供幫助的人少。

保持簡潔，能讓你得到他人幫助的機會大大增加。

😇“我很樂意寫API的教學。

” 😢”有一天開車在高速公路上，停在某個加油站加油的時候，我突發奇想，覺得我們應該這麼做，在進一步解釋之前，我先和大家展示一下…“ 盡量讓溝通都是在公開場合下進行。

盡量不要發私訊給維護者，雖然很多人會想這樣做，除非是你要分享一些機敏資訊（諸如安全問題或有人嚴重的違反行為準則）。

你若能夠保持談話是公開的，很多人可以從彼此交換的意見中學習和受益。

😇（評論）“@維護者你好！我們該如何處理這個PR？” 😢（郵件）“你好，非常抱歉發信給你，但是我實在很希望你能看一下我提交的PR。

” 大膽的提問（但是要有耐心！）。

每個人參與社群，開始的時候都是新手，哪怕是經驗老到的貢獻者也一樣，在剛進入一個新專案的時候，也是新手。

出於同樣的原因，長期維護的人也並不一定都熟悉專案的每一個部分。

協作時表現出你的耐心，你也會得到同樣的回報。

😇“感謝你檢查了這個錯誤，我按照您的建議做了，這是輸出結果。

” 😢“你爲什麼不處理我的問題？這不是你的專案嗎？” 尊重社群的決定。

你的想法可能會和社群的優先順序、願景有所差異，他們可能回覆了你的想法或最後決定不採納你的建言，這時你應該去積極討論並尋求折衷的辦法，維護者必須慎重的考慮你的想法。

但是如果你實在是不能同意社群的做法，你還是可以堅持己見將專案分支（fork）出去另起爐灶。

😇“雖然我很遺憾你不能支援我的需求，但是你解釋這只是對一小部分使用者起作用，我理解你的理由。

感謝你的耐心傾聽。

” 😢“你爲什麼不支援我的需求？這真是難以接受！” 以上幾點，要銘記在心。

開源是由來自世界各地的人們共同協作實現的。

需要面對跨語言、跨文化、不同的地理位置、不同的時區的問題，另外，單純文字上的溝通無法傳達語氣和情緒。

就先假設這些對話都充滿善意吧。

不用害怕拒絕人家，詢問事情的狀況，進一步澄清你的立場。

試著讓網路世界成為一個更好的地方。

多了解來龍去脈 在正式開始之前，做一些快速檢查，也許有人已經討論過你的疑惑了。

瀏覽專案的README、issue（open和closed都算）、郵件列表、StackOverflow。

毋需去花好幾個小時去全部折騰一遍，但是用幾個關鍵字搜尋一下是必要的。

如果你沒有找到和你想法一樣的內容，你就可以開工了。

如果專案是在GitHub上的話，你可以開啓一個issue或PR： Issues開啓一次對話或討論 Pullrequests請求接受自己的解決方法 簡單的溝通，例如澄清或how-to的問題，嘗試到StackOverflow、IRC、Slack或其它聊天頻道問問看。

在你創建issue和PR之前，請檢查專案的貢獻者文件（文件名通常叫做CONTRIBUTING，或者就直接寫在README中），找到你需要、較具體的東西，例如他們會要求你遵循某個樣板，或者是要求你使用某個測試。

如果你想做一個重大的貢獻，在正式開始之前先創建一個issue。

監控專案是很有幫助的（在GitHub，點擊“Watch”，所有當中的對話都會通知你），通知社群的成員們，讓大家知道你要做的工作，免得你做了之後，他們事後才知道。

只要你踊躍的使用watching，在GitHub上密切觀察專案，並閱讀每一個issue和PR，你會從你積極參與的專案中學到很多。

—@gaearon參與專案 提出問題 你應該在遇到下列情況時，去創建一個issue： 報告一個你自己無法解決的錯誤 討論一個重要的主題或想法（例如：社群、遠景、政策等） 提議做一個新的功能，或者其它專案的想法 在issue的溝通中幾點實用的技巧： 假如你看到一個open的issue，也是你打算解決的，寫下留言，告訴其他人你要開工了。

這樣的話，可以避免與其他人做了重複的事情。

假如某個issue已經處於open的狀態很久了，可能是有人正在處理中，又或者是已經解決了，也請你留言確認一下事情的狀態再決定下一步。

假如你創建了issue，但是沒多久自己解決了，也要留言，讓其他人知道，然後結束該issue。

記錄本身就是爲社群的貢獻。

創建pullrequest 在下面的情形時，請你務必使用PR： 提交簡易的補丁(例如拼寫錯誤、失效的超連結、或者是其它較明顯的錯誤) 開始一項別人請求的任務，或者是過去在issue中早就討論過的事情 一個PR並不代表工作已經完成了。

它通常是儘早開啓一個PR，這樣其他人可以了解或者給你一些回饋。

只需要標記爲“WIP”（WorkinginProgress）。

你可以隨時添加任何留言。

如果說專案是託管在GitHub上，以下是我們對於提交PR的建議： Fork程式碼並下載到自己的電腦，在本地端設定「上游」爲遠端倉庫。

這樣你可以在提交你的PR時保持和「上游」同步，合併時會減少解決衝突的時間。

（更多關於同步的說明，請參考這裡。

） 創建一個分支方便自己編輯。

參考任何相關的issue或在你的PR中註記相關的文件（例如：”Closes#37.”） 留下更動前後的螢幕截圖，如果你修改了HTML/CSS。

在你的PR中放上截圖。

測試你的工作！用原本寫好的測試來跑你寫好的新功能，若沒有的話，則需要寫一個測試。

無論是否有測試，一定要確保你的改動不會弄壞現有的專案的功能。

和專案現有的風格保持一致，盡你最大的努力，在使用縮排、分號或註釋很可能和你自己的風格大相徑庭，但這是為了節省維護者的精力，為了以後要了解、維護時的方便。

如果這是你第一次提交PR。

可以瀏覽提交PR的文件，這是@kentcdodds專門爲初次創建PR的人寫的手把手教學。

提交後需要善後的事宜 你做到了！恭賀你成爲貢獻開源的一員。

希望這是一個好的開始。

在你提交了貢獻之後，下面幾種情形中的某種是可能發生的： 😭沒有人理你。

希望你在工作開始之前檢查過了專案的活躍度，不過有時即使檢查過了，在一個活躍的專案中沒有人理會你的貢獻也是很正常的。

如果過了一週，依舊沒有人回應，請心平氣和的在同個條目下留言，請人幫你審核。

如果你知道可以找誰審核，你可以使用@名字，提醒他一下。

千萬不要私下去聯絡他人；要記住開源專案裡，所有的溝通都應該是公開的。

如果還是沒有人回覆，那就是真的沒有人對你的貢獻做出回應。

這可能感覺很差，但千萬不要灰心。

每個人都會遇到這樣的情況。

有很多原因會導致沒人回應你，這些原因通常也不是你能控制的。

再接再厲，換一種方法去提交，或者換一個專案。

這也是一個好時機讓你決定不要投資太多時間在成員活動不活躍的專案。

🚧有人希望你修改你的貢獻。

被人要求修改你的貢獻是很常見的事情，可能是改變你的提議，或是修改程式碼。

當有人提出變更時，請及時回覆。

畢竟他們花時間看了你的工作。

開了一則PR，然後一走了之是一個壞習慣。

如果你不知道如何改，花點時間研究，如果還是沒有想到好辦法，那麼是該向他人求助的時候了。

如果你沒時間處裡一則issue（舉例來說，如果對話已經持續了一個月了，而你還有其他的事情要處裡），那麼請通知維護的人，你無法及時的回覆了，肯定有人非常樂意接替你的工作的。

👎你的貢獻沒有被採納。

你的工作最後可能沒有被接受。

希望你沒有為此花太多力氣。

如果你不確定爲什麼沒有被接收，這正是一個很好的機會，去詢問維護者的看法、給他們一個澄清的機會。

無論如何，你都要對他們的決定表示尊重。

別花時間在爭論或樹立敵人上。

如果你堅持自己，你還是可以隨意fork專案，按照自己的思路發展出分支來。

🎉你的貢獻被接受。

太棒了！你完成了一次開源貢獻！ 你辦到了! 不論你是第一次貢獻，還是正在嘗試其他的貢獻方式，希望本文有提供你一些靈感去實踐。

即便你的貢獻沒有被採納，別忘了對幫助過你的維護者表示感謝。

開源就是由你這樣的人所打造：一則issue、一則PR或透過留言討論。

回到所有指南 相關指南 發起一個開源專案 從開源的世界汲取智慧，著手發起開源專案。

打造友善、溫暖的社群 打造個人們願意使用、貢獻並願意主動宣傳的人氣社群。