本文是github官方給出的參與github上開源項目的一些指導，對希望加入開源社群的開發者是一個不錯的參考。
最近一年開源項目特别的熱，很多技術大會或論壇都以開源項目作為主題進行探讨，可見這是一種趨勢。而github作為開源項目的著名托管地，可謂無人不知，越來越多的個人和公司紛紛加入到github的大家族裡來，為開源盡一份綿薄之力。對于個人來講，你把自己的項目托管到github上并不表示你參與了github開源項目，隻能說你開源了自己的項目，可以任别人自由下載下傳。
<a target="_blank"></a>
我們推薦你從已正在使用的或感興趣的項目開始。這裡有幾個很棒的地方供你參考：
下面是一些你在github開源項目中可能遇到的因素。
項目通常會有一個社群維護，由不同角色（正規或非正規）的其他使用者組成：
所有者（owner）：即建立該項目且在他們github賬戶上有該項目的使用者或組織。
維護者和協作者（maintainers and collaborators）： 緻力于一個項目并促進該項目發展的使用者。通常所有者和維護者是同一個使用者或組織，他們對項目庫都有寫的權限。
貢獻者（contributors）：每一個對該項目發出過pull request并合并到項目中的使用者都是貢獻者。
社群成員（community members）：即那些經常使用且非常關心該項目的使用者，他們在讨論功能特征和pull request上非常活躍。
一般項目中都有的檔案。
readme：幾乎所有的github項目都包含一個readme.md檔案。readme提供了該項目的一個概覽及關于如何使用、建構甚至如何貢獻于一個項目的相關細節。
contributing：項目和項目維護者不同，是以每個項目所期望的作貢獻的最佳方法也會有所不同。一定要注意一個标注為contributing的文檔，contributing文檔較長的描述了一個項目的維護者希望看到貢獻的更新檔或功能應該符合怎樣的規格。這可能包含要寫什麼測試，代碼文法規範或更新檔集中的區域。
documentation and wikis：許多大型項目有的不隻有一個readme來指導人麼如何使用他們的項目。在這種情況下你通常能夠發現一個指向庫中名為“docs”的另一個檔案或檔案夾的連結。
另外，該庫也可能使用github wiki來代替文檔。
既然你已經找到了了解該項目的相關資料，下面你就可以采取一些行動了。
在建話題之前檢查已有的話題：話題重複對雙方都無利，是以搜尋整個正開放和已關閉的話題以檢查你遇到的問題是否已經有人解決了。
務必對自己的問題有清晰的認識：期望的結果是什麼？然而卻發生了什麼？ 較長的描述其他人如何重制該問題。
包含一些系統相關的細節，比如用的什麼浏覽器、庫或作業系統及版本号。
如果你能夠修複bug或自己添加功能 — 太棒了，請發一個pull request吧！確定你已經讀過任何關于contributing的文檔，且需要了解license以及已經簽過cla（如果需要的話）。一旦你送出了一個pull request，維護者就會将你的分支與已有的分支作比較來決定是否要合并（即pull in）你作的改動。
務必清楚所出現的問題以及如何重制該問題或為什麼你的功能有幫助。然後同樣的要清楚做一些改變有哪些步驟。
最好測試一下。在任何已有的測試（如果存在）上運作你所做的改動并在必要時建立新的測試。不管測試存不存在，都要確定你的改動不會破壞已有的項目。
如果你的改動包含了html/css方面的不同，那麼請包含改動前和改動後的截圖。将你的圖檔拖放到你pull request的正文裡。
盡你所能的在項目的風格上多做努力。這可能意味着使用不同于你自己github庫中采用的縮進，分号或注釋，但是這讓維護者更容易合并，也讓其他人更容易了解和以後的維護。
一旦你打開一個pull request，就會有一個讨論，圍繞你提出的改變作出探讨。其他的貢獻者和使用者可能會參與進來，但最終由維護者做決定。你可能會被要求對你的pull request做一些改變，如果這樣，請給你的分支添加更多的commit并push它們 — 它們将自動的加入到已有的pull request裡。
如果你的pull request被合并了——太好了！如果沒被合并的話，也沒什麼大不了的，也許這不是項目維護者所期望看到的改動，亦或者他們已經緻力于該bug或功能。這種情況有可能發生，是以我們的建議是：對收到的結果做出回報，進一步努力然後再次pull request出去— 或者建立你自己的開源項目。
原文釋出時間為：2014-04-14
本文來自雲栖社群合作夥伴“linux中國”