本文發(fā)布在CM創(chuàng)始人，安卓全球定制之父，開源狂人Steve Klabnik的個人博客上，闡述了他自己在Github上親身為Rails開源服務(wù)的經(jīng)歷和看法，值得國內(nèi)為開源做支持的人借鑒，尤其是其中對篩選問題的算法值得一試。

[[111945]]

CM創(chuàng)始人：如何在Github上成為一個為開源服務(wù)的園丁

筆者做了很多開源工作，但是我對開源最有價值的貢獻(xiàn)并不是寫代碼。寫補(bǔ)丁是開源最簡單的一項工作，實(shí)際上，除了寫補(bǔ)丁以外，其他所有開源的工作都非 常難，比如，跟蹤Bug，管理郵件列表（mailing list），開發(fā)文檔（documentation），以及其他管理任務(wù)等等。本文將給大家介紹一下筆者在開源這條道路上學(xué)到的經(jīng)驗和教訓(xùn)。

讓 我們先回到RailsConf 2012大會上，筆者作為一名與會者參加了小組討論，當(dāng)時在Github的 rails/rails開源目錄下有許多小毛病（issues），數(shù)量大概有 800個，而且不少一直都沒有得到解決。因此，他們非常希望能解決兩個問題，一個是如何讓這些問題的數(shù)量有所下降，另一個就是如何讓開源社區(qū)提供幫助。***，他們覺得***的辦法，就是能組織一個“問題排除團(tuán)隊”，這個團(tuán)隊的工作，就是優(yōu)先解決問題。筆者也自愿加入了這個團(tuán)隊。

但是，“問題 處理”到底準(zhǔn)確的意思又是什么呢？好吧，在一個像Rails這么大的項目里面，會有許多小毛病得不到解決，有些問題***就不了了之了， 有些則需要提供更多信息，等等，一般程序員不太喜歡干這種“臟活累活”，所以，此時這個項目就需要一個“園丁”，他的工作的就是去“除草”，而且是經(jīng)常、 有規(guī)律地除草。

不過，在我們討論如何“除草”之前，先來搞清楚自己手頭上到底是個什么樣的“花園”吧。

這些問題（Issues）是什么？

如果你***開始一個項目，那么就需要搞清楚問題應(yīng)該是什么，對于不同項目來說，問題是不一樣的。舉個例子，在Rails項目倉庫里，我們的問題只為 解決Bug服務(wù)。我們把問題解決放在Stack Overflow（棧溢出）處理，新功能和要求則放在rails核心的mailing list里面。而在Rust項目倉庫里面，我們會在issues里面處理各種問題，比如功能請求，元問題……等等。對于其他某些開源倉庫，解決所有的問題 并不可行，可能還有一些開源倉庫，一個問題都沒有，比如Sequel。

我個人比較喜歡的處理開源問題的方式，就是Rails這種。理想情況下，你的項目是無瑕疵的，你也可以專門找一個地方去討論一下項目功能。但事實(shí)上，在Issues上提前規(guī)劃好，是開源的***步。

定期照顧

那么，現(xiàn)在的問題是，你如何處理800多個問題呢？我所能知道的唯一方法，就是把所有問題都過一遍。沒錯，我就是這么做的：我會花上周六或周日一整 天，進(jìn)入到Issues問題列表，然后再右鍵點(diǎn)擊，把所有問題逐個在新網(wǎng)頁標(biāo)簽里面打開。我會在一個網(wǎng)頁里面打開31個標(biāo)簽，里面有30個不同的 issues（問題），之后再重新開一個新頁面。接下來，我會進(jìn)入到每個問題里面，把內(nèi)容全部閱讀一遍，包括評論。如果我完成了頁面***一個的標(biāo)簽，就會 把當(dāng)前頁面關(guān)閉，然后進(jìn)入下一個頁面，搞定其他的問題，周而復(fù)始！

看看吧，人們都說開源是一個富有魅力的工作，但事實(shí)上完全不是這么一回事兒。要是為開源工作，你需要把自己整個周末都搭進(jìn)去，閱讀800個問題。

好了，不論以何種方式吧，一旦我把所有的問題都過了一遍，就會對當(dāng)前Rails項目所遇到哪些類型的問題有一個大致的了解。好了，現(xiàn)在我手頭上有了一大堆常見疑問，評論，還有各種問題。

那么下一步我要做的，就是把所有工作再做一遍。

等一下，再來一遍？為什么呢？好吧，現(xiàn)在我不是該去處理問題嗎？我不應(yīng)該趕緊干活，去解決實(shí)際問題嗎？問題是，在我真正著手解決問題的之前，面前是 如此海量的問題，我可能會遇到許多重復(fù)問題，我可能不知道每個問題里有哪些是無關(guān)痛癢的評論，我甚至也不知道哪些是普遍的常見問題，總之呢，需要我要搞定 的事情，變得越來越困難了。

不過，現(xiàn)在我已經(jīng)把所有的問題都過了一遍，為了解決上面的問題，我開發(fā)了一個算法來搞定：

1、這個問題是否是一個功能請求？如果是的，復(fù)制/粘帖一個我曾經(jīng)寫過的答案，然后把它們引入到Mailing list里面，然后點(diǎn)擊關(guān)閉。

2、這個問題是否是在請求幫助？如果是的，復(fù)制/粘帖一個我曾經(jīng)寫過的答案，然后把它們引入到StackOverflowt里面，然后點(diǎn)擊關(guān)閉。

3、這個問題是否是Rails以往版本的問題，而非當(dāng)前支持的版本？如果是的，復(fù)制/粘帖一個我曾經(jīng)寫過的答案，然后詢問有沒有人知道該問題是否會應(yīng)該Rails的可支持版本。

4、這個問題是否提供了足夠的信息，去重現(xiàn)錯誤？如果沒有，復(fù)制/粘帖一個我曾經(jīng)寫過的答案，然后詢問有沒有人能夠提供一個錯誤重現(xiàn)。

5、如果這個問題已經(jīng)有了錯誤重現(xiàn)，而且它并非發(fā)生在在***的Rails上面，嘗試一下HEAD請求，如果之后還發(fā)生這個問題，那么就留一個評論，告訴該問題發(fā)布人這個仍將是個問題。

6、如果我們到了這一步，可以判斷出，現(xiàn)在這個問題絕對是一個很明確的問題了。我會留一個評論，告訴該問題發(fā)布人我會處理解決，然后把這個問題抄送給Rails相關(guān)子系統(tǒng)的維護(hù)員，這樣他們就能找到屬于各自處理的問題。

原文鏈接：www.leiphone.com/how-to-be-an-open-source-gardener.html