本文发布在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