本文發佈在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
相關內容
開源文化在國內該如何發展