CM創始人：在 Github 上成為一個開源服務的園丁
本文發布在CM創始人，安卓全球定制之父，開源狂人Steve Klabnik的個人博客上，闡述了他自己在Github上親身為Rails開源服務的經歷和看法，值得國內為開源做支持的人借鑒，尤其是其中對篩選問題的算法值得一試。
CM創始人：如何在Github上成為一個為開源服務的園丁
筆 者做了很多開源工作，但是我對開源最有價值的貢獻并不是寫代碼。寫補丁是開源最簡單的一項工作，實際上，除了寫補丁以外，其他所有開源的工作都非 常難，比如，跟蹤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相關子系統的維護員，這樣他們就能找到屬于各自處理的問題。
來自: 雷鋒網