首先，我想说的是，看到这篇文章，我想说，其实任何一个你观察到的有点意思的现象都可以拿来研究，稍微往里面挖深一些，就都是有些意思意义的。所以idea这种事情，观察能力起到了很大的作用。
本文即是从developer technical support出发，分析2种代表性的support方式，一种是传统的mailing list，另一类是Q&A user-driven 的Stack Overflow。作者观察到有些project由传统的mailing list技术支持部分或者全部转向了stack overflow。作者列举了20个这样的项目。然后作者就想探究的是他们为什么会从mailing list等转向stack overflow呢，按照我读论文的思路，我想无非要考虑2大块，那就是stack overflow的优势需要体现出来，那概括起来就是2方面（文章也确实如此思路来描述，突然觉得自己好像读文章有点进步了。）一个是effective，一个是efficient。前者即是用户提了个编程相关的问题，你给的answer质量高不高够不够给力即effective，后者则是描述给出answer的时间即response time。2者缺一不可。而作者们确实对这2方面都拿出了数据统计，由于data 获取限制的缘故，作者只搞了4个project，在后面搞response time时甚至只搞到2个project。统计发现stack overflow在effective和efficient上均胜出。当然，effective的质量度量给的都是project的主观描述high low等，并没有具体的metric来衡量。文章的related work对quality有些硬性指标，如果感兴趣可以好好看看，推荐一个。
当然，作者还发现有的project move to stack overflow后又move回来了，至于为什么，看了下project 相关人员的言论后，发现，stack overflow是只回答programming 问题，非programming问题一般都会直接close掉，所以有些项目将自己认为合理但stack overflow不接受的问题就只能再move回去搞了。但stack overflow确实为programming问题的搞定提供了一个不错的平台，这个其实也很像现在比较火的众包的思维。看来，以后估计都要靠群体智慧了，只要相关机制做的好，那会是比较赞的出路。
这篇文章，如前所说，比较有意思的现象都可以拿来研究，此文往大方向说嘞，可以说是project technical support将来形式的发展趋势探讨，往小里说说嘞，又可以说是比较有意思的研究现象。
以上！
zou@Home
2015-07-18
