希望各位參與過知名開源項目的朋友們給出一些自身的經驗和體會。
回複內容：
最近幾個月開始參與 mruby，不算知名項目，不過後來越想越覺得這個項目適合我這種菜鳥：
- 開發比較活躍，matz 在晚上基本上都會看
- matz 脾氣特別好，回複也挺快的
- 代碼規模較小，相對容易上手
- 還沒有正式發布，所以不很穩定，bug 比較多
- 前景目測還不錯
在參與之前只是簡單過了一下它的垃圾收集部分，湊巧看到一處重複代碼就刪掉提了個 pr，很快就被merge了。膽大之後一邊看代碼一邊發 pr 給垃圾收集部分加註釋。慢慢對代碼比較熟悉了一些，開始在 github 上 Watch 它，如果有人報了 bug 會收到郵件，報的 bug 基本上 100% 可複現，所以比較容易定位修複。但動作要快，不然讓 matz 看見就被秒修了。修複之後盡量加上 regression test。
目前的遺憾是還沒提交過 feature，但有幾個小 idea醞釀中。使用該軟體
閱讀原始碼和文檔
跟蹤郵件清單
解答新手問題
提交BUG報告和重現BUG代碼
提交Patch和測試代碼，反覆修改Patch
討論新功能需求和設計1. find interesting project
2. fix issues of this project
3. fork and pull request
4. congratulations !
轉載。源地址： 一步一步教你怎樣給Apache Spark貢獻代碼
本文將教大家怎樣用10個步驟完成給Apache Spark貢獻代碼這個任務
- 到 Apache Spark 的github 頁面內點擊 fork 按鈕
- 你的github帳戶中會出現 spark 這個項目
- 本地電腦上， 使用
git clone [你的 spark repository 的 github 地址]例如：git clone git@github.com:gchen/spark.git
首先說說參與開源的好處,
- * 開闊眼界. 就像學畫畫要多看名家名作一樣. 如果想提高自己的技術水平, 那眼光就不能只局限在在自己工作中開發維護的那一塊代碼. 高手的代碼到處都有, 但活躍的開源項目無疑是一個非常好的途徑. 紙上得來終覺淺, 如果能參與進去, 修複bug, 貢獻代碼, 那學習的效率比光看又高了一個量級. 從參與這個角度講, 隨書源碼之類的無法和開源的代碼比. 除了代碼, 可以學到東西還有很多, 比如 設計模式, 開發流程, etc.
- * 職業加分. 開源項目可以和工作相關, 也可以和工作無關. 比如像想換方向, 但是又不想以新人的身份去求職, 那麼先在開源項目上積累經驗無疑是一個可行的辦法. 如果和工作相關, 那麼開原始碼誰都能看到, 在求職的時候也更容易被人考察,認可. 想象一下簡曆裡面這麼一句會不會比較拽: "詳細實現請fork: http://github.com/nnnbbb/"
- * 認識牛人的機會. 一個好的老師是無價的, 有時候一句話, 一個推薦也許就改變了你的職業生涯. 能和各種牛人戰鬥在一個戰壕裡, 這種機會不是隨便一個公司能提供的.
- * 學英語. 鑒於大部分的開源項目還是用英語溝通, 所以也是一個見識地道程式員英語的好辦法. 告別那些絞盡腦汁而又蹩腳的變數名和函數名吧.
- * 好吧, 我承認上面提到的都太功利了. 其實, 分享的樂趣, 代碼被廣泛使用的成就感, 也是很迷人的.
根據上面列表, 分析你的需求, 好好想想什麼樣的項目適合自己. 然後就是如何參與進去了, 要融洽的加入一個開源社區, 有一些要注意的地方:
- * 首先, 尊重他人的時間. 牛人都很忙, 不要用低級的問題, 低級的錯誤去麻煩他們. 先把文檔都好好看了, 有什麼看不懂的先搜尋一下, 其他的關於提問的注意事項, 參見很多技術論壇都有置頂的 "提問的藝術"
- * 如果你不是很牛, 那麼可以從使用, 測試開始做起. 再牛的開源項目也不會拒絕別人的bug report, 當然請注意提bug的方式, 通常, 版本, 環境, 重現步驟是不可少的. 還有一些其他的打雜的任務也是入門和混臉熟的好辦法, 包括但不限文檔翻譯, 代碼整理...
- * 然後就可以開始改改小bug了. 通常小步快走比一口吃成一個大胖子要靠譜. 等你熟悉項目了, 自然會發現自己的patch越來越大, 越來越重要.
- * 提交patch,或是 request pull之前先自己好好把代碼整理, 測試了, 新手犯錯是允許的, 但是老犯錯就有問題了.
- * 代碼風格和項目已有代碼保持一致. 這個就像鐵軌寬度一樣, 沒有對錯, 1.4米寬的比1.3的好? 不一定, 但大家都1.4, 那就請你也1.4吧. 等你自己開個項目的時候, 你就可以愛怎麼定就怎麼定.
來自 來自 github:shop
閱讀代碼，參與討論，提交補丁，報告 bug，協助重現 bug，修複 bug，協助測試，協助 Code Review，迭代你的補丁，報告基礎測試資料，協助回答其他人的問題，協助補充文檔。從修複一個拼字錯誤，增加一個測試案例，到提交一個功能，你可以做的很多。具體還要根據自己的興趣和項目的需要了。gh上很多開發人員都很nice，自己主動一點，可以不從痛點入手，先從一些小地方開始。gh上很多開發人員都很nice，自己主動一點，可以不從痛點入手，先從一些小地方開始。 如果說“加入”一個項目，使用它也是一種加入。
如果說加入的意思是加入“開發人員團隊”，每個開源社區的文化和風格各不相同，最行之有效方法是主動聯絡他們。 2008年，我開始使用FreeSWITCH（http://www.freeswitch.org
），加入郵件清單http://lists.freeswitch.org
，潛水
後來，我在http://wiki.freeswitch.org
上建立了一個帳號，更新文檔
後來，在http://jira.freeswitch.org
上建立了一個帳號，彙報Bug
後來，申請了一個貢獻者SVN上的許可權（freeswitch-contrib目錄，現已不用），在裡面提交自己的一些指令碼等
後來，項目庫轉到了Git，又申請了Git提交許可權，可以更新核心代碼。但一般更新前會跟相關模組或核心代碼的原作者通過郵件或IM交流。如果是明顯的錯誤（如筆誤或編譯錯誤等）或是自己負責的部分，就可以直接提交了。
