本文发布在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相关子系统的维护员，这样他们就能找到属于各自处理的问题，
