一些參與開源項目的建議

　 一直很是想增長到一個開源項目中去，目的很是easy：分享思路。接受衆人的考驗，但是卻沒成行。

   看到這篇文章。受到必定的啓示。遂轉之。

注：有刪減。http://www.php100.com/html/itnews/it/2012/0420/10275.html

　 人們常下面3個緣由而打消了參與到開源項目的念頭：

　　1. 我還不足夠優秀

　　2. 我沒有足夠的是時間

　　3. 我不知道什麼樣的項目適合我

　　尋求機會參與到開源項目中去，應該知道的三個基本原則：

　　1. 項目需要各類能力層次的專業人才。

　　2. 哪怕是微不足道的貢獻也比沒有好。

　　3. 從你正在使用的項目做爲參與到開源的第一步

　　某些項目中的成員看起來就像明星。沒錯，他們確確實實是一個極具天賦的程序猿，然而，他們中的絕大部分不是的。

    項目需要的不過那些能把任務完畢的人。有時付出的不需太多，有時需要花大把的時間。有時它就是編程。而有時它不是。

　　下面是一些參與開源項目的建議或者經驗，假設你有興趣，最好仍是試試：

　　0. 增長郵件列表：

       對於大多數項目，郵件列表仍然是項目開發溝通基本的渠道。

       在一個規模比較大的項目中一般有很是多郵件列表可以選擇，好比：PostgreSQL項目就有很多於12個面向用戶的郵件列表和6個面向開發人員的。

       我建議你關注最基本的幾個面向用戶郵件列表以及核心的開發人員列表。

　　1. 關注並編寫博客：

       博客通常由核心開發人員維護，一般博客中包括項在將來版本號的一些信息。

       怎樣獲取這些信息呢?一般一個星級站點有包括來自很是多相關項目的新聞或者博客詞條。假設有一個星級站點，

       如：http://plant.gnome.org 或者 http://planet.mysql.com ,那麼你要作的不過用Google搜索」planet <項目名>」。

       同一時候你也可以用博客寫下你使用項目的一些經驗。記錄你碰到的問題及解決辦法。

　　2. 增長到IRC頻道：

       不少開源項目都有專門的互聯網中繼聊天(IRC)頻道，用來爲開發人員和用戶討論開發問題。

       細緻查找項目站點中IRC頻道叫什麼。

　　3. 代碼診斷：

       Bug一般很是難報告出來，診斷高速處置bug有助於節省開發人員的時間。

       假設用戶提出報告：「當我操做XX功能時，系統沒法工做」。你得花些時間解決這些問題。

       仍是不是會反覆出現?好比該類問題是否不過發生在某種瀏覽器不兼容?

只在發行版有這種問題仍是其餘的緣由。

　　4. 關閉已修復的bug：

       一般bug在代碼庫中修復了，但是在問題追蹤系統中還沒更新。

       清理掉這些雜亂的東西儘管耗時，但是對整個項目來講是值得的。

　　5. 測試beta版或者候選版本號：

       不論什麼項目設計用於執行在多個平臺時就有可能存在各類兼容性問題。

       當一個beta版或者候選版公佈時，項目帶頭人但願能在不一樣的人和不一樣的平臺上獲得測試反饋結果，你就可以是當中之中的一個。

　　6. 修復bug：

       修復bug通常是貢獻者開始接觸代碼的地方，很是easy，在問題追蹤系統中找到感興趣的bug。修復之，假設合適的話爲代碼的修復撰寫文檔。

　　7. 寫測試：

       絕大多數項目都有測試套件用來測試代碼。很是難想象測試套件中不能附加不少其餘的測試在其上。

       使用測試覆蓋工具諸如基於c的gcov、基於Perl的Devel::Cover，用來標識源碼無法經過測試套件測試到的範圍，而後增長一個套件覆蓋它。

　　8. 理性對待編譯警告：

       不少基於C項目的構建過程當中經常會出現很是多古怪的編譯警告。這些警告一般不是錯誤，但是看起來像，

       太多的警告讓編譯器聽起來就像在發假警報，細緻檢查代碼是否的確隱藏有bug。

　　9. 附上凝視：

        當你在深刻研究代碼時。你可能發現有疑惑的地方。這對你來是一個機會，別人也可能碰到相同的問題，給他們貼上凝視提交補丁。

　　10. 建立樣例：

        通常項目都沒有太多入門的樣例，不管是web API、普通程序庫、或者是GUI應用如Gimp、仍是命令行工具，

         比起長篇的文檔，一個恰當的樣例可以更清晰更高速解釋軟件的使用方式。

　　11. 問題回答：

        參與到社區最好的方式是幫助別人。回答問題，尤爲是那些初次涉及的。這對於一個項目的成長很是關鍵，

        即便你回答不過簡單地」RTFM」(read the fxxk manual)。每個人都要行動起來，項目假設要變得強大起來的話每個人需要動員起來。

　　

　　12. 改進站點：

        很是多程序猿在圖形設計方面顯得很是糟糕，尤爲是那些不能從設計部門獲得幫助的項目站點。

        假設你有網頁設計方面的技能，最好仍是改進下站點。站點做爲項目的招牌，是值得花時間的。

        也許項目界面需要完全改造，抑或不過一個logo，這些是社區缺少的技能，假設我能提供一些圖形設計上的幫助，別人會很是喜歡的。

　　有太多的方式參與到開源項目中，哪怕是咱們寫一個新產品的特性的歷史回想。

    每個使用開源項目的人都可以把技術帶到社區和幫助開源成爲IT產業中重要的一部分。

    一句話：溝通交流。重在行動。