在Github上，如何成為一個為開源服務的園丁

本文釋出在CM創始人，安卓全球定製之父，開源狂人Steve Klabnik的個人部落格上，闡述了他自己在Github上親身為Rails開源服務的經歷和看法，值得國內為開源做支援的人借鑑，尤其是其中對篩選問題的演算法值得一試。

筆者做了很多開源工作，但是我對開源最有價值的貢獻並不是寫程式碼。寫補丁是開源最簡單的一項工作，實際上，除了寫補丁以外，其他所有開源的工作都非常難，比如，跟蹤Bug，管理郵件列表（mailing list），開發文件（documentation），以及其他管理任務等等。本文將給大家介紹一下筆者在開源這條道路上學到的經驗和教訓。

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

但是，“問題處理”到底準確的意思又是什麼呢？好吧，在一個像Rails這麼大的專案裡面，會有許多小毛病得不到解決，有些問題最後就不了了之了，有些則需要提供更多資訊，等等，一般程式設計師不太喜歡幹這種“髒活累活”，所以，此時這個專案就需要一個“園丁”，他的工作的就是去“除草”，而且是經常、有規律地除草。

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

這些問題（Issues）是什麼？

如果你首次開始一個專案，那麼就需要搞清楚問題應該是什麼，對於不同專案來說，問題是不一樣的。舉個例子，在Rails專案倉庫裡，我們的問題只為解決Bug服務。我們把問題解決放在Stack Overflow（棧溢位）處理，新功能和要求則放在rails核心的mailing list裡面。而在Rust專案倉庫裡面，我們會在issues裡面處理各種問題，比如功能請求，元問題……等等。對於其他某些開源倉庫，解決所有的問題並不可行，可能還有一些開源倉庫，一個問題都沒有，比如Sequel。

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

定期照顧

那麼，現在的問題是，你如何處理800多個問題呢？我所能知道的唯一方法，就是把所有問題都過一遍。沒錯，我就是這麼做的：我會花上週六或週日一整天，進入到Issues問題列表，然後再右鍵點選，把所有問題逐個在新網頁標籤裡面開啟。我會在一個網頁裡面開啟31個標籤，裡面有30個不同的issues（問題），之後再重新開一個新頁面。接下來，我會進入到每個問題裡面，把內容全部閱讀一遍，包括評論。如果我完成了頁面最後一個的標籤，就會把當前頁面關閉，然後進入下一個頁面，搞定其他的問題，週而復始！

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

好了，不論以何種方式吧，一旦我把所有的問題都過了一遍，就會對當前Rails專案所遇到哪些型別的問題有一個大致的瞭解。好了，現在我手頭上有了一大堆常見疑問，評論，還有各種問題。

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

等一下，再來一遍？為什麼呢？好吧，現在我不是該去處理問題嗎？我不應該趕緊幹活，去解決實際問題嗎？問題是，在我真正著手解決問題的之前，面前是如此海量的問題，我可能會遇到許多重複問題，我可能不知道每個問題裡有哪些是無關痛癢的評論，我甚至也不知道哪些是普遍的常見問題，總之呢，需要我要搞定的事情，變得越來越困難了。

不過，現在我已經把所有的問題都過了一遍，為了解決上面的問題，我開發了一個演算法來搞定：

1、這個問題是否是一個功能請求？如果是的，複製/粘帖一個我曾經寫過的答案，然後把它們引入到Mailing list裡面，然後點選關閉。

2、這個問題是否是在請求幫助？如果是的，複製/粘帖一個我曾經寫過的答案，然後把它們引入到StackOverflowt裡面，然後點選關閉。

3、這個問題是否是Rails以往版本的問題，而非當前支援的版本？如果是的，複製/粘帖一個我曾經寫過的答案，然後詢問有沒有人知道該問題是否會應該Rails的可支援版本。

4、這個問題是否提供了足夠的資訊，去重現錯誤？如果沒有，複製/粘帖一個我曾經寫過的答案，然後詢問有沒有人能夠提供一個錯誤重現。

5、如果這個問題已經有了錯誤重現，而且它並非發生在在最新的Rails上面，嘗試一下HEAD請求，如果之後還發生這個問題，那麼就留一個評論，告訴該問題釋出人這個仍將是個問題。

6、如果我們到了這一步，可以判斷出，現在這個問題絕對是一個很明確的問題了。我會留一個評論，告訴該問題釋出人我會處理解決，然後把這個問題抄送給Rails相關子系統的維護員，這樣他們就能找到屬於各自處理的問題，

此時，我會做這麼一件事兒，點選Github介面上“Watching”按鍵，如下圖所示：

之後，我會設定一個Gmail過濾器，把所有Rails標籤的電子郵件過濾進我自己的收件箱內，如下圖所示：

為什麼要這麼做呢？好吧，我並沒有一次把全部800多個問題都導進我的收件箱，我決定每天匯入一個頁面的問題，也就是30個。這樣我自己也能較好的管理相關問題，而且不會讓我把自己全部的時間都花在解決問題上面。不過，我還是需要上面設定的電子郵件和過濾器的，因為我覺得作為一名“園丁”，這項工作非常重要，那就是，定期照料自己的花園。

每天早上，在我去上班之前，我會倒杯咖啡，然後檢視一下自己的電子郵件。在工作前，我不會去解決這些問題，但是我首先會去處理Rails的相關郵件。每天早上，我會收到大概20到25封新的電子郵件，其中大部分問題都會有一個新評論，我會花上15分鐘左右快速瀏覽一下。而在午飯時間，我會再看一下電子郵件，然後花上10分鐘過一遍，最後在臨睡前再花15分鐘處理下剩下的20個通知。基本上，我每天會花不到一小時的時間跟蹤問題，這樣我就會對整個專案問題的狀況有所掌控。

一旦把所有問題過濾一遍之後，我就會把所有問題按照優先順序過濾，然後處理解決。在解決問題這一階段，我通常花費的時間大概在兩週左右。為什麼是兩週時間呢？因為兩週時間可以讓我們確定是否能搞定某個問題，而且這段時間也能讓維護人員做個判斷，看自己是否有能力處理這些問題。看到沒有，要讓一個問題得以解決，除了維護人員之外，也需要該問題提交人的幫助，因為許多提交的bug並沒有足夠的資訊，所以往往需要問題提交人重現問題，這樣才能真正解決相關問題。

在兩週之後，每天晚上我還會做一件事兒，我會利用“最新更新”功能過濾一些問題，看看是否有什麼問題最後不了了之。此時，我會把這些問題挑出來，看看支援人員是否能在“兩週時間”內搞定，如果他們無法得到相關問題提交人的回覆，那麼就會把這些問題關閉。當然啦，問題不會永遠被關閉，在合適的時間裡，這些問題還可以被重新啟用。

按照上述流程，我們的問題已經從800多個下降到了450個左右。Rails核心團隊的成員開玩笑的對我說，他們應該專門為我開發一個電子郵件過濾器，這樣我在處理問題的時候就可以準確定位到問題了。

對於我工作的每一個開源專案程式碼倉庫，我都會用本文介紹的方法來處理Issues（問題），但是我的方法必須要持之以恆，才能有效果，如果你不願意照顧好自己的花園，那麼自然雜草叢生。最近這段時間，我沒有太多時間處理Rails上的問題，上面的問題數量又上升到了800多個。

開源工作就是這樣，如果沒有人關心相關問題，那麼問題就會越來越多，如果你希望為一個開源專案提供幫助，我可以告訴你，這份工作並不迷人，你需要把這份工作培養成自己的一種習慣。

via  Steveklabnik 

via: http://www.leiphone.com/how-to-be-an-open-source-gardener.html