首先扩劝，我想說的是，看到這篇文章职辅，我想說棒呛，其實(shí)任何一個(gè)你觀察到的有點(diǎn)意思的現(xiàn)象都可以拿來研究，稍微往里面挖深一些域携，就都是有些意思意義的簇秒。所以idea這種事情，觀察能力起到了很大的作用秀鞭。
本文即是從developer technical support出發(fā)趋观，分析2種代表性的support方式扛禽，一種是傳統(tǒng)的mailing list，另一類是Q&A user-driven 的Stack Overflow皱坛。作者觀察到有些project由傳統(tǒng)的mailing list技術(shù)支持部分或者全部轉(zhuǎn)向了stack overflow编曼。作者列舉了20個(gè)這樣的項(xiàng)目。然后作者就想探究的是他們?yōu)槭裁磿?huì)從mailing list等轉(zhuǎn)向stack overflow呢剩辟，按照我讀論文的思路掐场，我想無非要考慮2大塊，那就是stack overflow的優(yōu)勢需要體現(xiàn)出來贩猎，那概括起來就是2方面（文章也確實(shí)如此思路來描述熊户，突然覺得自己好像讀文章有點(diǎn)進(jìn)步了。）一個(gè)是effective吭服，一個(gè)是efficient嚷堡。前者即是用戶提了個(gè)編程相關(guān)的問題，你給的answer質(zhì)量高不高夠不夠給力即effective噪馏，后者則是描述給出answer的時(shí)間即response time麦到。2者缺一不可。而作者們確實(shí)對(duì)這2方面都拿出了數(shù)據(jù)統(tǒng)計(jì)欠肾，由于data 獲取限制的緣故瓶颠，作者只搞了4個(gè)project，在后面搞response time時(shí)甚至只搞到2個(gè)project刺桃。統(tǒng)計(jì)發(fā)現(xiàn)stack overflow在effective和efficient上均勝出粹淋。當(dāng)然，effective的質(zhì)量度量給的都是project的主觀描述high low等瑟慈，并沒有具體的metric來衡量桃移。文章的related work對(duì)quality有些硬性指標(biāo)，如果感興趣可以好好看看葛碧，推薦一個(gè)借杰。
當(dāng)然，作者還發(fā)現(xiàn)有的project move to stack overflow后又move回來了进泼，至于為什么蔗衡，看了下project 相關(guān)人員的言論后，發(fā)現(xiàn)乳绕，stack overflow是只回答programming 問題绞惦，非programming問題一般都會(huì)直接close掉，所以有些項(xiàng)目將自己認(rèn)為合理但stack overflow不接受的問題就只能再move回去搞了洋措。但stack overflow確實(shí)為programming問題的搞定提供了一個(gè)不錯(cuò)的平臺(tái)济蝉，這個(gè)其實(shí)也很像現(xiàn)在比較火的眾包的思維。看來王滤，以后估計(jì)都要靠群體智慧了贺嫂，只要相關(guān)機(jī)制做的好，那會(huì)是比較贊的出路淑仆。
這篇文章涝婉，如前所說哥力，比較有意思的現(xiàn)象都可以拿來研究蔗怠，此文往大方向說嘞，可以說是project technical support將來形式的發(fā)展趨勢探討吩跋，往小里說說嘞寞射，又可以說是比較有意思的研究現(xiàn)象。
以上锌钮！
zou@Home
2015-07-18
