這不是一篇權威的指南，只是一些你需要遵循的基本規則，這些規則可以讓你對開源項目的貢獻使得你和項目維護者都感到愉快!
爲什麼加入一個開源項目？
首先，有很多加入開源項目的動機。排在第一的可能是“酷”：）當你告訴你的朋友“嘿，我在XYZ項目開發團隊! 我很潮吧？”
但是這並不是一個很好的原因。加入一個開源項目的首先需求是你需要使用它。如果你自己不會實際使用，那麼就不會有很強的動機去加入一個項目。
其它一些加入開源項目的原因可能是：
- 獲得寫權限，將你自己的特性或者bug修訂加入到基礎代碼中；
- 你認爲自己能夠對項目帶來很大的提升；
- 你有很多空閒時間：）
初始方法
因爲如下兩個原因，第一次加入一個開源項目可能需要慎重對待：
首先，沒有標準的方法，沒有“加入此項目”這個按鈕。你需要直接聯繫項目的所有人（或者維護人），同他交談。
對起步者來說，另外一個可能導致加入過程有點困難的事情是缺少課題。
在你嘗試加入一個開源項目之前，你應該嘗試自己啓動一個項目。即使這僅僅是一個小項目或者只是一個Lib庫，或者是一些簡單但有用的東西，然後在你自己的Blog或者社交網站上宣告項目。如果你幸運的話，一些人會發現項目的價值，然後開始使用它。
通過做這件事情，你將學會兩件事：首先是如何運轉一個開源項目，其次是你的發明被很多其他人使用時是什麼樣子。當你意識到可能有成百上千的人使用你的代碼，有的人檢視它並反饋意見、想法、補丁包給你的時候，這是一件很令人激動的事情。
除了這些，你也可以看到社區是如何運轉和發展的，你將開始從不同的環境不同的角度來看你的項目。
它將爲你打開新的視野!
即使你已經做了這些事情，或者感覺自己已經做好無論如何都要加入一個開源項目的準備，也還有其它前提條件：
- 你必須熟悉掌握項目使用的VCS（Version Control System）工具。例如，如果項目使用Subversion（SVN），你必須知道如何提交、合併、回退、修補等等
- 你必須知道可讀的代碼和文檔的重要性
- 你必須知道如何註釋你的代碼
如果你覺得所有這些你都沒有問題，第一步就是開始“玩”項目：將代碼Checkout，然後一頭扎入代碼中，去學習代碼如何工作以及代碼完成什麼功能。
同時也要關注項目使用的編碼風格，你不需要完全按照當前項目維護者那樣編碼，但至少要保證是相同的風格。你需要考慮到總會有人將要閱讀和修改你的代碼。
就像有人說的：編碼的時候你要想象那個最後維護你代碼的人是一個知道你住在哪裏的暴力精神病患者!
當你感覺已經做好要加入的準備，你可以進入下一步：聯繫項目維護者！
初步聯繫
如果你準備運行自己的開源項目，你可能已經有了一個如何讓你的Email被尊重和別人看到Email的時候如何想的好主意。
這個不是什麼高深複雜的事情（原文爲rocket science）：
- 這個傢伙加入了許多開源項目，而且可能在項目中擔任全職工作，所以Email要短、要令人愉快。
- 這個傢伙根本不知道你是哪根蔥。所有運行開源項目的傢伙至少知道一件事情：好心未必有好報（Hell is paved with good intentions）。
- 展示你項目有關的知識，而不是你的激情。換句話說，向項目所有者證明你具有成爲項目一部分的資格。如果你加入了，你有足夠的時間來展示你的動力和激情
好的，我已經加入了，現在幹嘛？
根據經驗，有兩種類型的人將加入開源項目：一種是推動項目前進的人，一種是不會推動項目前進的人。
與展示實際的資格相比，那些不會推動項目前進的人總是更加傾向於展示自己的激情。他們加入項目，然後從不提交任何東西，或者提交新的代碼，或者提交新的功能，因此也不會帶來任何Bug。
當加入一個項目的時候，問問自己是否有足夠的動機去實際做一些事情是重要的，但不要做得太多也同樣重要。
一個新的程序員在某種意義上來說有點像一個新的經理，要想成功，必須具備相似的品質。
一個真正優秀的經理將謹慎的接受一個新的工作職位。即使他的最終目標是將公司顛覆過來和優化整個流程，他也會以完美的模仿前任經理來作爲開始。
爲什麼？
設身處地的想象一下：如果你是新經理的下屬，或者新經理的上級，他們得到一個新的經理：
A經理：加入公司，試圖將公司業務顛覆過來，打破正在運行的流程，阻止人們進行工作。但是經過一些列的困難工作後，前景將如此美好!
B經理：加入公司，完美地深入細節地工作，同時給工作流程帶來小的增量的改進，最終起草並向上級提交詳細、完整、通過顛覆原有流程來優化的計劃。
誰將有更大機會獲得成功？
很明顯是B經理，因爲首先他通過帶來一些微小的改進來證明他更有競爭力，然後在他嘗試去實施大的改進之前，提交一個清晰和完整的計劃。
給一個開源項目帶來很大改變不是不可能的，但首先你要證明你能夠完成它。
一個成功的開源項目很像一個成功的商業：如果不毀滅它，那麼很難帶來很大的成功的改變。
所以特別小心你的大的改變。
事實上當加入一個開源項目後最好的開始的地方是非常基礎的：在那些你只會帶來很小危害的地方開始!
改進項目的文檔或者註釋、添加單元測試、或者做一些檢視，這是一個瞭解項目、項目的缺點、項目的優點的好機會。項目維護者非常樂意你做這些，這也是獲得他們的信任以及展示你是認真幫助項目的好機會。
創建你自己的分支也是一個好主意，這樣你就是在一個沙箱（譯者注：供兒童在其中玩耍的一個環境，類似於在海灘上堆城堡，可以隨便推到從來，也不會帶來什麼危害）環境中，對項目來說，這樣你就幾乎沒有可能做錯事或者破壞項目。
儘管將主幹版本合併到你的分支，這樣就可以使得你的代碼與時俱進。
政治環境
我不認爲有任何成文的規定，但是你必須知道一些關於大部分開源項目的一個重要的事情：
沒有民主!
隨便你怎麼說，但最終只有一個權威：項目所有者。
不喜歡這樣？忘掉它吧（原爲是Fork it）。