【伯樂線上導讀】：對程式設計師而言，參與開源有著難以置信的回報，比如有一個自己的出色開源專案，在技術面試能增色很多，極大加分。所以，越來越多的人在參與到開源運動中來。但對應很多新手來說，如何參與開源做出第一個貢獻，如何發起一個新專案，卻成了一個問題。

2月14日，GitHub 官博發文宣告正式推出「開源指南」，旨在方便想參與到開源的個人和組織。「開源指南」是一個系列集合，內容簡潔明瞭，分了 10 個方面。伯樂線上在本文中翻譯了首篇。

怎樣為開源做貢獻

想為開源做貢獻嗎？這是一份寫給新手和老手的開源貢獻指南。

第一部分：為何要為開源做貢獻？

在 freenode 的工作使我學到了很多技能，後來我將它們運用到我的大學學習和實際工作中。我認為在開源專案中的工作對我的幫助和它對專案本身的幫助一樣大！—

@errietta，《為什麼我熱愛為開源軟體做貢獻》

為開源做貢獻是學習、教學和在你能想象的任何技能上積累經驗的有益途徑。

為什麼人們為開源做貢獻？有許多理由！

提升現有技能

不管是寫程式碼、使用者介面設計、平面造型設計、寫作，或是規劃，如果你在尋找實踐機會，在開源專案中總有適合你的任務。

結識愛好相似的人

擁有熱情而友好的團體組織的開源專案使人們在多年以來常常回訪。許多人通過參與開源成了一輩子的好朋友，無論是在會議中碰面還是深夜裡線上聊玉米煎餅。

找到導師和教導他人

在共享的專案中與他人一起工作，意味著你必須解釋你做事的方式，此外還要尋求他人的幫助。學習和教導，對參與其中的所有人都是一種滿足的活動。

開發公開作品，幫你提升聲望（和事業）

根據定義，你的所有開源工作都是公開的，這意味著你得到了免費的樣本，可以帶到任何地方，作為你能做事情的證明。

學習交際能力

開源提供了練習領導才能和管理技能的機會，比如解決衝突、組織不同團隊的人，和給工作排優先順序。

人人都可以參與改變，不分大小

你不一定要成為終生的貢獻者才能享受參與開源的樂趣。你是否曾在網站上看到一個拼寫錯誤，希望某人會修正它？在開源專案中，你就能做到這點。開源幫助人們在他們的生命中和他們對世界的體驗中感受到力量，這本身是令人滿足的。

第二部分：貢獻意味著什麼

如果你是一個開源貢獻方面的新人，這個過程可能是令人生畏的。怎麼找到合適的專案？不會寫程式碼怎麼辦？某件事出岔子了會怎樣？

不用擔心！有各種各樣的方法參與開源專案，並且有幾個訣竅會幫你最大程度地運用你的經驗。

你不一定要貢獻程式碼

關於為開源做貢獻，一個常見的誤解是你必須貢獻程式碼。事實上，常常是專案中非程式碼的部分大多被遺漏和忽視了。通過參與提供非程式碼的貢獻，你會給專案做出巨大的幫助！

我因為在 CocoaPods 中的工作出名，但大多數人不知道實際上我在 CocoaPods 工具本身上並沒有做任何實際的工作。我在這個專案上花費的時間，大部分是在做諸如文件和品牌推廣工作之類的事情。— @orta，《預設轉向開源軟體》

即使你是一名開發者，非程式碼貢獻也是參與專案並結識其它團體成員的極好方式。建立那樣的關係，將給予你在專案的其它部分工作的機會。

我初次接觸 Python 開發組（也叫做 python-dev）是在 2002 年 6 月 17 日，我就接受我的補丁事宜向郵件列表發電子郵件。很快我發現了開源中的一個 bug，並決定把這個錯誤寫成郵件摘要彙報給小組。我對這個主題做了澄清，他們為麻煩我做這件事而表示了大大的歉意。但更關鍵的是，當某人指出的某些東西需要修正時，我能夠看到的。

你是否喜歡活動規劃？

• 組織專案會議（如果他們有的話）
• 幫助團體成員找到合適的會議並提交演講提議

你是否喜歡設計？

• 調整佈局以提高專案的可用性
• 做使用者調查以重新組織和改善專案的導航和選單，就像 Drupal 建議的那樣。
• 制訂風格指南以幫助專案擁有一致的視覺設計

你是否喜歡寫作？

• 編寫和改進專案文件
• 組織一個示例資料夾，展示怎樣使用專案
• 開辦專案通訊，或從郵件列表中組織重要內容
• 翻譯專案的文件

說真的，“文件”極其重要。到目前為止，Babel（Kittens 的開源專案）的文件一直很棒，已經成為了它的殺手級特性。但是肯定還需要做一些工作加以完善，甚至加一些段落上去，對此我非常感激。

你是否喜歡組織？

• 連結重複的 Issue，給出新的 Issue 標籤建議，讓事情井井有條
• 在最近開放的 Issue 中提有助於澄清的問題，把討論向前推進

你是否喜歡寫程式碼？

• 問問你是否能幫忙寫一個新特性
• 自動化專案的設定
• 提升工具和測試

你是否喜歡幫助他人？

• 在諸如 Stack Overflow（就像這個 Postgres 的例子一樣）或 reddit 之類的地方回答關於專案的問題
• 在開放的 Issue 中為人們回答問題
• 幫忙主持討論版或會話通道（conversation channels）

你是否喜歡為他人的程式碼提供幫助？

你並不非得要在軟體專案中工作！

雖然“開源”通常指軟體，但你可以在任何事情上協作。有書籍、食譜、清單和課程是作為開源專案開發的。

例如：

即使你是一名軟體開發者，在文件專案上的工作也能幫你在開源方面起步。在與程式碼無關的專案中工作常常不那麼令人生畏，而且協作的過程將增強你的自信和經驗。

第三部分：熟悉一個新專案

如果你去看一個 Issue 追蹤器，發現事情看起來令人困惑，並不是只有你這樣。這些工具需要大量的隱性知識，但人們能幫你駕馭它，你也能向他們提問。

對任何超過修正拼寫錯誤的事情來說，為開源做貢獻就像在社交聚會上走向一群陌生人。如果當他們正在深入討論金魚時，你開始談論美洲鴕，他們可能有點奇怪地看著你。

在帶著你自己的建議盲目投入以前，先從學習怎樣觀察聚會中的人，參與他們討論的話題開始。這樣做能增加你的想法被注意到和聽取的可能性。

開源專案剖析

每個開源團體都是不同的。

在一個開源專案中花了若干年時間意味著你已經瞭解了一個開源專案。轉向一個不同的專案，你可能會發現詞彙、規範和溝通方式完全不同。

即便如此，許多開源專案遵循著相似的組織結構。理解不同的團體角色和總體過程將幫你迅速熟悉任何新專案。

一個典型的開源專案有以下幾類人：

• 作者（Author）：建立該專案的人或組織。
• 所有者（Owner）：對組織或倉庫（repository）擁有行政所有權的人（並不總和原始作者是同一個人）
• 維護者（Maintainers）：對推動願景和管理專案的組織方面負有責任的貢獻者。（他們可能也是專案的作者或所有者）
• 貢獻者（Contributors）：每個對專案做出過某種貢獻的人。
• 團體成員（Community Members）：使用專案的人。他們可能在對話中保持活躍或者對專案的方向表達他們的主張。

大的專案可能還有下屬委員會或工作組，他們致力於不同的任務，比如工具、分類（triage）、團體節制（community moderation）和活動組織。在專案的網站上尋找“team”頁面，或者在倉庫（repository）裡尋找治理文件（governance documentation），來找到此類資訊。

專案也有文件。這些檔案通常列在倉庫（repository）的頂層。

• 許可證（LICENSE）：根據定義，每個開源專案必須有一個開源許可證。如果專案沒有許可證，那它就不是開源的。
• 自述檔案（README）：自述檔案是迎接專案的新團體成員的操作指南手冊。它解釋了為什麼專案是有用的以及如何開始。
• 貢獻（CONTRIBUTING）：自述檔案幫助人們使用專案，而貢獻檔案幫助人們為專案做貢獻。它解釋了需要什麼型別的貢獻者以及這個過程是怎麼工作的。雖然不是每個專案都有貢獻檔案，但它的存在表明這是一個歡迎做貢獻的專案。
  • 行動守則（CODE_OF_CONDUCT）：行動守則為參與者的相關行為設定了基本準則，並且幫助促進一個友好而熱情的環境。雖然不是每個專案都有行動守則檔案，但它的存在表明這是一個歡迎做貢獻的專案。
  • 其它文件：可能有另外的文件，比如教程、演練（walkthroughs）或管理策略，尤其是在大專案中。

最後，開源專案使用以下工具來組織討論。通讀檔案檔案將為你很好地描繪該團體是怎樣思考和工作的。

• Issue 追蹤器（Issue tracker）：人們討論專案相關 Issue 的地方。
• Pull requests：人們討論和審查進行中的更改的地方。
• 討論板或郵件列表：有些專案可能為會話主題使用這些通道（例如，“我怎樣……”或“你認為……怎麼樣”，而不用 bug 報告或特性請求）。其它專案為所有會話使用 Issue 追蹤器。
• 同步聊天通道（Synchronous chat channel）：有些專案為臨時會話、協作和快速交流使用聊天通道（比如 Slack 或 IRC）。

第四部分：找到一個要做貢獻的專案

既然你已經弄明白開源專案是怎樣工作的，是時候找到一個要做貢獻的專案了！

如果你之前從未為開源做過貢獻，聽聽美國總統約翰·F·肯尼迪的建議，他曾經說：“不要問你的國家能為你做什麼-問問你能為你的國家做什麼。”

為開源做貢獻在所有層面和不同專案間都能發生。你不必對你的第一個確切的貢獻是什麼，或它看起來是什麼樣想得過多。

相反地，從考慮你已經在使用的或想要使用的專案開始。你會積極地做貢獻的專案正是你發現自己會回訪的專案。

在那些專案裡，無論何時你發現自己想到某件事可以變的更好或不同，按照你的直覺行動吧。

開源不是一個排外的俱樂部；它是由和你一樣的人做出來的。“開源”只是一個花哨的術語，為了把世界上的問題都作為可修正的來處理。

你可能會細看一份自述檔案，發現一個斷開的連結或一個拼寫錯誤。或者，你是一個新使用者，你發現某樣東西毀壞了，或是一個 Issue 你認為實際上應該在文件中。與其忽略它並繼續，或請求其他人修正它，不如看看你能不能參與幫忙。這就是開源的真諦！

對開源的非正式貢獻中，有28%是文件，比如拼寫錯誤修正、重排格式，或翻譯。

你也可以使用下列資源之一來幫你發現新專案：

做貢獻前的一份檢查表

當你找到一個你想要做貢獻的專案，做一個快速的瀏覽來確認該專案適合接受貢獻。否則，你的努力工作可能永遠得不到迴應。

這是一份便於使用的檢查表，用來評估一個專案對新貢獻者來說好不好。

滿足開源的定義

• 它有沒有許可證？通常，這是在倉庫（repository）根目錄裡的一個叫做 LICENSE 的檔案。

專案積極地接受貢獻

看看主分支上的提交活動。在 GitHub 上，你可以在倉庫的主頁上看到此資訊。

• 最新的提交（commit）是在什麼時候？
• 專案有多少貢獻者？
• 人們提交頻繁程度？（在 GitHub 上，你可以通過點選頂部橫條裡的“Commits”來找到此資訊）

下一步，看看專案的 Issue 。

• 有多少開放的 Issue ？
• 當 Issue 開放時，維護者是否快速地迴應？
• 對於 Issue 有沒有活躍的討論？
• Issue 是最近的嗎？
• Issue 是否得到關閉？（在 GitHub 上，點選 Issue 頁面上的“closed”標籤來看已關閉的 Issue 。）

現在對專案的 pull requests做同樣的動作。

• 有多少開放的 pull requests？
• 當開放pull requests時， 維護者是否快速地迴應？
• 對於pull requests有沒有活躍的討論？
• pull requests是最近的嗎？
• pull requests被合併是在多久之前？（在 GitHub 上，點選pull requests頁面上的“closed”標籤來看已關閉的pull requests。）

熱情的專案

友好而熱情的專案標誌著他們樂於接受新的貢獻者。

• 維護者對於 Issue 中的問題是否作出有幫助的迴應？
• 人們在 Issue 、討論板和聊天（例如 IRC 或 Slack）中是否友好？
• Pull Requests(PR) 功能是否得到審查（reviewed）？
• 維護者對人們的貢獻是否表示感謝？

無論何時你看一個長的討論帖，抽查一下較晚進入這個帖子的核心開發者的反應。他們是否作出建設性的總結，在做出決策和付諸實施時，是否同時還保持禮貌？如果你看到發生許多口水仗，那通常表明精力用在了爭論而不是開發上。— @kfogel，創作開源軟體

第五部分：怎樣提交貢獻

你已經找到一個你喜歡的專案，並且你已經準備好作出貢獻。最後！這裡告訴你怎樣以正確的方式作出你的貢獻。

有效的溝通

不管你是一次性的貢獻者或是試著加入一個團體，與他人一起工作是你將在開源中發展的最重要的技能之一。

作為一個新貢獻者，我很快認識到，如果我想要能關閉 Issue ，我必須提問。我瀏覽了程式碼庫。一旦我對發生的事有了一些認識，我請求更多的指點。就是這樣！在得到我需要的所有相關細節後，我能解答 Issue 了。— @shubheksha，一個新手在開源世界中的顛簸旅途

在你開啟一個 Issue 或使用pull request，或是在聊天中提問以前，記住這些要點可以使你的想法有效地被別人理解。

給出上下文。幫助他人快速趕上進度。如果你遇到一個錯誤，解釋你正準備做什麼和怎麼重現它。如果你提出一個新主張，解釋為什麼你認為它對專案有用（不只是對你！）。