想參與開源又不想寫代碼的八種做法

前幾天看了個帖子才了解要把一個項目開源，前期需要做很多工作，比單純的開發要耗更多精力。而開源之后，需要面對的可能是無人問津，或者是只有索取沒有貢獻。事實上除了寫代碼之外，還有很多其他方式融入到開源里。

很多開發者好像認為參與開源就意味著寫代碼和提交代碼。但我認為不只是這樣，以下告訴你為什么。

當然，開源運動最終是分享代碼，但開源項目可以看作是一個生態系統，參與開源不只有寫代碼和提交代碼這么簡單。還有其它方式只是你沒注意而已：

1. 報告問題

遇到問題時，放棄使用或自行修補，都不能真正解決問題，我們必須讓維護項目的人知道才行。大多數項目都樂于接報問題。另外，不要小看寫報告。好的報 告可能很費時，它應包括錯誤的代碼，預期結果和實際結果，系統概況，版本，甚至還有調用棧。我還喜歡寫上我對維護者的感謝，當然這非必要。記住，我們不僅 可以報告問題，還可以提優化建議和新功能。

2. 寫文檔

文檔很重要，而人們卻不喜歡寫。它能幫助人們了解一個項目。如果你發現某個項目很難懂，請試試給它寫個指南，那么后來者可能會受益。我就為Ruby提交過東西——文檔。

3. 改善網站

很多開源項目都有自己的網站。有些可能做得不夠吸引，或者有些沒怎么更新。以前的oldshoe網難看至極，但如今，在wpp的幫助下，變得相當友善。wpp提交的不是代碼，但他的貢獻同樣偉大。

4. 幫忙設計

很多項目想有一個時尚的圖標，也想在網站里加入一些插圖之類的東西。如果你擅長這方面，或者可以到你心儀的項目去問問是否需要幫忙做設計。

5. 嘗鮮

開發者頻繁發布alpha、預覽版，以期了解是否符合大家要求。所以，參與嘗鮮，能幫助開發者發現問題。

6. 參與討論

維護者一般都歡迎用戶參與討論API的變更和功能改進。我就試過花了一整天來跟人討論一個架構問題。討論能引導項目的發展方向。EricWatson為shoes4制定的路線圖就為該項目發展帶來極大幫助，甚至超過了他編程的貢獻。

7. 解答問題

人們對項目總有疑問。參與解答問題能給他們帶來更好的體驗。而且記住每個問題都可能揭示出項目的缺陷。這功能的文檔能更新下嗎？這東西能做成自動的嗎？有沒好用點的API？也許你能幫忙解答這類問題。

8. 幫項目做演講

沒有推廣的話，一個項目再優秀也難以被大眾采納。如果你真愛某個項目，試著拿它來做個演講。這樣有助于提升該項目的使用率和參與率，對項目和用戶都有好處。

結束

如果你有做過以上某點，那么，感謝你，你為開源項目貢獻過！請繼續參與，若沒做過，請試試。我的另外一篇文章可作為入門開源項目的指引。我也因為參與開源而收獲了不少朋友。

原文： http://opensource.com/business/14/12/8-ways-contribute-open-source-without-writing-code 作者： Tobias Pfeiffer

譯文： http://code.csdn.net/news/2823008 譯者： dncszp