❏ 站外平台:

在Github上,如何成为一个为开源服务的园丁

| 2014-04-21 13:39   分享: 2    

本文发布在CM创始人,安卓全球定制之父,开源狂人Steve Klabnik的个人博客上,阐述了他自己在Github上亲身为Rails开源服务的经历和看法,值得国内为开源做支持的人借鉴,尤其是其中对筛选问题的算法值得一试。

Steve_Kondik

笔者做了很多开源工作,但是我对开源最有价值的贡献并不是写代码。写补丁是开源最简单的一项工作,实际上,除了写补丁以外,其他所有开源的工作都非常难,比如,跟踪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”按键,如下图所示:

e2rhsedvszk54q_small

之后,我会设置一个Gmail过滤器,把所有Rails标签的电子邮件过滤进我自己的收件箱内,如下图所示:

oyuljxmbfqieia_small

为什么要这么做呢?好吧,我并没有一次把全部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



最新评论


返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。