我今年不知是機緣巧合，還是所謂的注定，有多次機會和大家講《開發者與開源社群的關係》的演講。那麼開源的生產方式，是高效的、高質量的，那麼這些是怎麼來的呢？其中，人是最主要的，那麼我談到的開發者是廣義的開發者，包括專案生產過程中全部的過程參與者。那麼從小白該如何晉級為高手？不妨按照文中作者的指引去做做。
儘管有很多人認為開源專案只是需要程式設計師，而且是那種特別有經驗的，然而，事實上是開源專案所需要的人才遠遠不止這些。比如測試人員、技術支援、文件工程師、營銷人員等等。
不過本篇文章要說的是為開源專案做貢獻，不僅可以提高技術技能，而且還能結識更多「臭味相投」的人，參與開源專案的乙個障礙是不知道如何加入並開始使用，本篇文章就是為大家講講如何為開源專案做貢獻。
我來舉幾個社群的榜樣，參與社群一開始未必必須是程式設計師，比如con kolivas，他是一名來自澳大利亞的麻醉師，他針對linux核心開發了適合自己的任務排程器，因為現存的任務排程是通用的，並不能滿足kolivas的需求。
又比如alexey kuznetsov，一名理論物理學家，但是卻也是一名linux hacker，系統程式設計師。
lesya novaselskaya，本來打算是成為一名汽車修理工的，現在參與了開源專案的測試工作，還有很多很多這樣的例子，個人通過在開源專案中找到自己的興趣，同時獲得經驗和樂趣。
參與乙個專案未必從一開始就必須得是專家，假如你對程式語言有一定對掌握，那麼可以試著去提交一些新的特性，並讓專案的其它成員看到。有些開源專案新手是比較容易上手的，但是有些則擁有很高的門檻。在門檻較低的專案中，一般是初學者、菜鳥較多，這個時候，如果你能夠幫助到其他人，那麼你的貢獻就不會被忽視。
每個開源的專案內部的流程都是特別的，所以在做貢獻之前一定要自己先熟悉他們的流程。舉例來說，在postgresql專案中，所有的流程都是被嚴格監管的，任何**的更改，都要將補丁傳送給所有的主要開發者做深入的研究。然而在專案parrot中，就允許提交到主分支。還有，如果專案使用的是github，那麼就會提倡使用pull request。總而言之，世上沒有完全相同的開源專案貢獻法則。
在你每次更改**的時候，你一定要記住，你是整個團隊的一部分，並盡力使你的編碼風格符合專案所採用的編碼風格。你所新增和編輯的**不應和其它部分格格不入，你可以在**樣式方面擁有自己的偏好，但是你提交的內容必須遵循常規規則。否則的話，你這麼做的意思無疑是在挑釁：「我不喜歡你的風格。我更好，所以像我這樣做。」 這會導致很多衝突的，相信社群經理或其它相關的人員會站出來解決的。
毫無疑問，**是任何軟體專案的基石。然而，撰寫**並不是唯一可以參與開源專案的事情。技術支援往往被忽視，因為每個人都專注於新增新功能和修復錯誤。但是，技術支援往往是乙個新的貢獻者入門上手的好的開始。
舉例來說，openvz在站點bug.openvz.org實現了完整的 bug 追蹤，它會收集所有的已知的問題——已經修復的和尚未修復的——近十多年的 bug 都在，因為專案已經很多年了。bug 系統是在開發者和使用者之間建立溝通的良好渠道。對當前請求的持續工作提供了巨大的機會。請記住，您可能需要專案經理提供的某些訪問許可權（通常以精英為基礎）。
對測試感興趣的同學，面對開源軟體可能完全不知道該如何開始，但是，要知道，絕大多數的開源專案，無論是否具有商業背景，都是非常缺乏測試人員的。發現並將 bug 排定優先順序，可以大大幫助開發人員節省時間。
根據我個人的經驗，開源專案一般都會比較缺乏資源來測試全部的功能特性，所以在主幹作出重大變化之前，專案會試圖發出號召，讓大家盡可能多的去做測試。沒有那個開源擁有充足的軟、硬體配置的，正因為如此，諸如 openbsd、openvz 才會召喚測試人員幫忙測試新的功能特性。
你可以幫助開發者測試軟體在不同的平台下是如何工作的，如果你使用的是非標準的硬體的話，你的反饋是非常有價值的。如果您確認構建工作即使在這樣的環境中，您也可以使專案經理更容易地評估專案當前的發布狀態。
多數專案針對**測試都會使用軟體套件，當然，也會讓使用者去做一些測試，使用諸如可定位 c 的源** lcov 這樣的工具，無法通過預設測試進行檢查。然後建立自定義測試以覆蓋這些**部分。
為開源專案做貢獻，一直以來最為常見的莫過於工程師提交乙個補丁，補丁要麼是用來修復 bug 的，要麼是用來增加乙個新的特性的。odin 的首席技術官 james bottomley 曾經撰文：linux 核心開發者30個星期的經歷中寫道：「那些不知道如何加入 linux 專案的人們，建議去修改bug和提交新功能。」他還專門舉例說明，他自己曾經遇到 android 下沒有 sip 客戶端，然而他自己需要這個功能，於是寫了補丁，並提交給了 sipdroid 專案。
當你建立新的功能特性時，在所更改的**中撰寫相應的測試是乙個非常好的行為。有一些專案要求所有錯誤修復都必須是有相應的測試用例的。在檢視未知**時記下筆記。即使是你無法修復的 bug，在提交的 ticket 中盡可能的去詳細的將之描述，因為這對於後面跟進的人會有很大的幫助。
你是否對 devops 感興趣？一名優秀的 devops 工程師，是非常難求的（我之所以這麼說是根據我自身的經驗），一名 devops 可以通過開放的基礎設施開發可以學習、改進其自身的技能，如維基百科、fedora，openvz 也有類似的基礎設施維護，為專案元件設定持續整合、為 linux 發行版建立元件包、開發者環境的自動配置這些統統都是 devops 的任務。
維護文件對於任何專案都是非常重要的部分，但是就這麼一點卻是經常性的被忽視。還有更加常見的情形：文件是針對軟體非常熟悉的資深人群的，而不是面對初學者和剛入門的。閱讀諸如此類的文章，你的感覺是好像我應該什麼都會似的。除此之外，迅速發展專案中的文件會變得過時，所以需要定期更新。
將文件視為不重要是犯大忌的事情，所有對開源專案的貢獻都是重要的。文件甚至在某種程度上超越了**。舉例來說，來自 cern 的 ingo schwarze，是一名openbsd 的開發者，建立了專案 mandoc，現在此專案已經不至於用在openbsd 下，它還被廣泛的應用於各個 bsd 發行版，如 freebsd、 netbsd、以及 dragonflybsd，他還整理了專案中現有手冊頁的格式。
因此，如果您有興趣為專案做一些重要的事情，請幫助改進其文件。
隨著專案的日益成長、進化，回答日常問題，尤其是針對新手的問題，就顯得越發的重要。將時間花費在這裡是值得的，哪怕是已經有了完善的文件。如果你能夠成功的招募一名新的、活躍的成員，那真是善莫大焉！社群的每一位成員，幾乎都是這麼過來的。還有，任何專案都是由眾多的人所完成的！
為未來的貢獻者創造了相應的背景知識。
描述你的技術成果，研究和專業知識的部落格也是分享在專案中獲得的實際經驗的好方法，以及在技術問題上發現的解決方案。（這對於你尋找下個工作機會會非常的有幫助）。
許多專案採用貢獻者部落格帖子聚合器，通常稱為planet，常見的開源社群有：
來自愛好者的文章，有的時候真的很有意思，哪怕是這位愛好者本身並非是專案的貢獻者。
設計是開源專案中永遠的痛！這可能是很多專案失敗的最大原因。令人厭煩的web站點，毫無生氣的logo，都是困擾專案的主要原因，僅僅是貢獻者們都將精力集中在了專案本身的功能上了，而不在乎它的外觀如何，所以開源社群是非常歡迎設計師的。
如果讀者您有意為開源專案貢獻力量的話，正在尋找有興趣的專案或者是幫助改進專案，都是非常受歡迎的。當然，每個專案有著不同的流程，一般情況下，專案都會設定如何參與貢獻專案的指南和嚮導，請你仔細讀一下，這裡筆者為大家列出三個專案的貢獻指南頁面：
github貢獻開源專案的流程
請使用chrome 或者ie10以上瀏覽器 github 是目前世界上最大的開源專案的託管交流平台。貢獻開源專案的流程也是 github 全力支援的，也一樣是遵循 github flow，雖然跟前面團隊合作流程會有一點差別。在團隊內部，大家都是有寫許可權的。但是網上的開源專案參與者眾多。如果你一上去...
開源專案貢獻
一 github的開源專案 github 是目前世界上最大的開源專案的託管交流平台。貢獻開源專案的流程也是 github 全力支援的，也一樣是遵循 github flow，雖然跟前面團隊合作流程會有一點差別。在團隊內部，大家都是有寫許可權的。但是網上的開源專案參與者眾多。如果你一上去就跟專案的擁有者...
如何加入開源專案的小手冊
參與開源專案，可以快速提高自己的技術水平，學到很多學校中學不到但在工作中會非常有幫助的技巧。乙份參與過開源專案的履歷，也越來越受到用人單位 的重視。所以最近幾年，我們技術愛好者對開源專案投入的關注是越來越多了。可仍會看到很多對開源專案充滿興趣和熱情的同學，用了錯誤的方式方法以至於不得 其門而入。這段...