盧 松, 楊 達(dá), 胡 軍, 張 瀟

1(中國科學(xué)院軟件研究所 基礎(chǔ)軟件國家工程研究中心, 北京 100190)2(中國科學(xué)院大學(xué), 北京 100190)

基于時(shí)間和影響力因子的Github Pull Request評(píng)審人推薦①

盧 松1,2, 楊 達(dá)1, 胡 軍1, 張 瀟1,2

1(中國科學(xué)院軟件研究所 基礎(chǔ)軟件國家工程研究中心, 北京 100190)2(中國科學(xué)院大學(xué), 北京 100190)

開源社區(qū)github提供了pull request的機(jī)制讓開發(fā)者可以把自己的代碼集成到github的開源項(xiàng)目中從而為項(xiàng)目做出貢獻(xiàn). Pull request 的代碼評(píng)審是github這類分布式軟件開發(fā)社區(qū)維護(hù)開源項(xiàng)目代碼質(zhì)量的非常重要的方式. 為一個(gè)新到來的pull request 指派合適的代碼評(píng)審人可以有效減少pull request從提交到開始審核的延遲.目前github是由項(xiàng)目核心成員人工來完成評(píng)審人的指派, 為了減少這種人力損耗, 我們提出代碼評(píng)審人的推薦系統(tǒng), 該系統(tǒng)基于信息檢索的方法, 并考慮了評(píng)審人的影響力因子以及評(píng)審的時(shí)間衰減的因素, 對(duì)新到來的pull request, 自動(dòng)推薦最相關(guān)的評(píng)審人. 我們的方法對(duì)top 1 的準(zhǔn)確度達(dá)到了68%, 對(duì)top 10的召回率達(dá)到了78%.

pull request; 代碼評(píng)審; 信息檢索; 時(shí)間因子; 影響力因子

1 概述

Github是當(dāng)前非常知名的一種分布式的版本控制系統(tǒng), 擁有140多萬開發(fā)者用戶的開源社區(qū). 開發(fā)者可以使用watch、fork、star、pull request等方式實(shí)現(xiàn)對(duì)感興趣的項(xiàng)目進(jìn)行社交化編程(social coding)[1].

隨著github的項(xiàng)目的發(fā)展, pull request成為了社交化編程以及代碼持續(xù)集成的行之有效的方式, 據(jù)統(tǒng)計(jì),目前github中采用這種社交化編程的協(xié)作式項(xiàng)目數(shù)量占到了一半以上[2], 而且采用pull request進(jìn)行代碼集成的項(xiàng)目的數(shù)量將來只會(huì)越來越多. Github的contributor為社區(qū)做出貢獻(xiàn)的流程可以分為如下5步:

1) 首先contributor找到一個(gè)感興趣的項(xiàng)目, 并follow一些該項(xiàng)目中的知名的開發(fā)者, watch該項(xiàng)目.

2) Fork該項(xiàng)目的一部分到本地, 相當(dāng)于克隆到本地; contributor在克隆的版本上實(shí)現(xiàn)一個(gè)新的特性或者修復(fù)了一些bug; 然后contributor使用pull request的方式, 把完善好的代碼發(fā)送給原始的項(xiàng)目;

3) 項(xiàng)目內(nèi)的所有的開發(fā)者都能夠在項(xiàng)目的pull request庫中評(píng)審已提交的pull request. 他們可以討論項(xiàng)目是否需要這個(gè)新特性, 提交的代碼是否符合規(guī)范,以及能否提升該pull request代碼的質(zhì)量;

4) contributor根據(jù)評(píng)審人的建議, 會(huì)完善并更新他的pull request, 接著評(píng)審人再次評(píng)審修改后的pull request;

5) 項(xiàng)目的核心負(fù)責(zé)人基于所有評(píng)審人的意見決定是把該pull request合并到項(xiàng)目代碼中還是拒絕它.

Github開發(fā)者以及項(xiàng)目的數(shù)量的迅速增長, 每天產(chǎn)生的pull request的數(shù)量是驚人的, 比較知名的項(xiàng)目每個(gè)月會(huì)產(chǎn)生幾百甚至上千個(gè)pull request. 這將導(dǎo)致github的更新迭代效率非常大的程度上依賴于pull request提交的代碼能否被及時(shí)評(píng)審. 從pull request提交到該pull request真正開始被評(píng)審人評(píng)審的時(shí)延我們稱之為評(píng)審時(shí)延. 實(shí)際情況中, 由于pull request的相關(guān)評(píng)審人很可能沒注意到該pull request而導(dǎo)致評(píng)審時(shí)延過大. 據(jù)已有的調(diào)查研究表明, 15%的contributor抱怨他們的pull request得不到評(píng)審人及時(shí)的反饋[3], 也有人專門做了關(guān)于評(píng)審時(shí)延的評(píng)估分析, 他們采用了線性回歸的模型來模擬pull request的評(píng)審時(shí)延, 得出平均的時(shí)延大小有364小時(shí), 當(dāng)然有的pull request一直得不到評(píng)審會(huì)拉高整體的平均時(shí)延時(shí)間, 于是統(tǒng)計(jì)了時(shí)延大小的中位數(shù)為15小時(shí)[4]. 我們的評(píng)審人推薦機(jī)制可以在新的pull request產(chǎn)生時(shí), 自動(dòng)匹配與該pull request最相關(guān)的評(píng)審人, 并給他們發(fā)送消息, 使得評(píng)審時(shí)延大大降低, 有效地提高了github項(xiàng)目的迭代效率.

現(xiàn)有的pull request代碼評(píng)審人的指派有2種方式,第一種是人工指派, 需要一位項(xiàng)目集成管理人指派給項(xiàng)目開發(fā)組的核心成員進(jìn)行代碼評(píng)審, 但使用這種指派方式的pull request所占的比重只有0.89%[5]. 另外一種更加通用的指派方式是使用@標(biāo)記. 比如評(píng)論中包含@張三, 則張三會(huì)收到關(guān)于這條評(píng)論的信息. 通過@某個(gè)人的方式, 不僅可以@項(xiàng)目的核心成員, 也可以@項(xiàng)目中的任何一個(gè)contributor, 讓他們得到通知并參與討論該pull request. 對(duì)pull request的討論可以是該pull request的代碼整體所實(shí)現(xiàn)功能的意義或做的貢獻(xiàn), 也可以是具體的某幾行代碼的正確與否、代碼是否規(guī)范等等的評(píng)論.

圖1 pull request中評(píng)審人進(jìn)行評(píng)審討論

圖1 展示了在一個(gè)的pull request下評(píng)審人進(jìn)行評(píng)審討論的過程, 該圖來自于Github中scikit-learn項(xiàng)目的一個(gè)pull request, 它的標(biāo)題名為Clustering algorithm– BIRCH, 它的提交者是MechCoder, 在提交pull request并進(jìn)行代碼修改之后, 他@jnothman并邀請(qǐng)jnothman評(píng)審他的思路以及代碼是否正確, 接著jnothman就給出了評(píng)論并發(fā)表了他的意見. agramfort是另外一位評(píng)審人, 并提出了他對(duì)當(dāng)前pull request的代碼修改意見, 最后, MechCoder @jnothman @agramfort并表達(dá)感謝他們的意見讓他的思路以及代碼可以不斷完善, 實(shí)現(xiàn)了他所想要的功能, 最后他的這部分代碼被merge到scikit-learn項(xiàng)目的主分支中.進(jìn)入該pull request中, 我門可以發(fā)現(xiàn)不僅是項(xiàng)目的核心成員進(jìn)行了評(píng)審, 項(xiàng)目中的普通成員如mblondel、coveralls等等也加入了討論, 只是由于圖片篇幅的原因, 沒在圖1中展示出這些的評(píng)論. 所有這些評(píng)審人說的話會(huì)影響最終的pull request的最終決策. 作為項(xiàng)目的pull request的持續(xù)集成負(fù)責(zé)人, 他需要對(duì)項(xiàng)目中的contributor有一個(gè)比較好的了解, 才能做一些比較適當(dāng)?shù)腀標(biāo)記, 讓負(fù)責(zé)該pull request這塊的人能更好的對(duì)pull request進(jìn)行評(píng)審, 提高效率. 而如果我們能自動(dòng)生成和該pull request相關(guān)的項(xiàng)目組成員名單, 則可以有效減少項(xiàng)目持續(xù)集成負(fù)責(zé)人的工作量; 同時(shí)沒有被@的項(xiàng)目成員可能和該pull request相關(guān)性也很高,但沒有收到消息會(huì)導(dǎo)致他對(duì)該pull request的評(píng)審延遲,我們的評(píng)審人推薦可以使用@推薦項(xiàng)目成員的方式通知和該pull request感興趣的項(xiàng)目成員, 從而減少評(píng)審時(shí)延, 有效地提高github的社交化編程效率.

總體來說, 本文的貢獻(xiàn)如下:

1) 使用了信息檢索(information retrieval)的方法在評(píng)審人相關(guān)性評(píng)估中, 我們加入了影響力因子這個(gè)重要的考量因素. 本文首次提出在github項(xiàng)目中基于follower的數(shù)量來對(duì)影響力因子的量化計(jì)算方法, 我們認(rèn)為follower數(shù)量越多的人, 他的評(píng)審的權(quán)重應(yīng)該比follower數(shù)量少的成員權(quán)重高.

2) 我們還引入了時(shí)間維度衰減的策略, 基于信息檢索方法獲得與新到來pull request最相關(guān)的歷史pull request, 這些歷史pull request的評(píng)審人構(gòu)成了候選評(píng)審人集合. 在計(jì)算候選評(píng)審人與新到來的pull request相關(guān)性得分時(shí), 引入對(duì)歷史pull request評(píng)審的時(shí)間衰減因子. 在歷史pull request獲得相關(guān)性相同的情況下,距離新到來pull request時(shí)間越長, 該歷史pull request下的評(píng)審人所獲得的相關(guān)性得分越低.

2 相關(guān)工作

我們的工作借鑒了開源社區(qū)中代碼bug的分類報(bào)告和代碼評(píng)審的組織方式. 開源社區(qū)的大型項(xiàng)目比如Bugzilla是一個(gè)開源的缺陷跟蹤系統(tǒng), 它可以管理軟件開發(fā)中缺陷的提交(new), 修復(fù)(resolve), 關(guān)閉(close)等整個(gè)生命周期. 每天都會(huì)有幾十個(gè)新bug report提交給bug追蹤系統(tǒng), 而分配bug report給適合的bug修復(fù)者是一件很耗精力的事情. 同樣的, 代碼評(píng)審系統(tǒng)每天也會(huì)有很多提交請(qǐng)求, 需要進(jìn)行組織并指派相關(guān)人員進(jìn)行評(píng)審.

前人做了很多研究來進(jìn)行bug report分類或代碼評(píng)審, 有機(jī)器學(xué)習(xí)的方法(如: SVM), 也有信息檢索(Information Retrieval)的方法. Cubranic等[6]提出文本分類的方法, 目的是將bug對(duì)應(yīng)的文本分到已經(jīng)定義好的bug report分類標(biāo)簽的集合中去, 利用bug report的標(biāo)題、描述和關(guān)鍵詞信息來進(jìn)行bug指派. Canfora和Cerulo[7]使用歷史的bug report的文本描述作為document來標(biāo)識(shí)開發(fā)者, 而新的新的bug report的描述作為query, 如此可以構(gòu)建一個(gè)信息檢索系統(tǒng). Kagdi和Linares-Vasquez[8]提取出源代碼的評(píng)論和描述信息,并通過隱性語義索引(LSI)的方法把這些數(shù)據(jù)索引起來.對(duì)于一個(gè)新的bug report, 這些索引可以用于鑒別誰在之前的一段時(shí)間有修復(fù)相似的bug. Tamrawi等[9]對(duì)人進(jìn)行建模, 認(rèn)為擁有相同興趣的人對(duì)各自的bug report互相評(píng)論的次數(shù)會(huì)越多. Y Yu等[10]將這種對(duì)人的建模方法進(jìn)一步深入探討并引入到pull request的代碼評(píng)審人推薦的情境中, 他們構(gòu)建了評(píng)審人的社交網(wǎng)絡(luò), 網(wǎng)絡(luò)的點(diǎn)就是開發(fā)者, 網(wǎng)絡(luò)的邊的權(quán)重就是評(píng)論人的相關(guān)性, 并且認(rèn)為提交pull request的人和評(píng)審pull request的人對(duì)該pull request所屬領(lǐng)域具有共同的興趣.

本文所做的工作是基于信息檢索的方法對(duì)pull request進(jìn)行建模, pull request的標(biāo)題和描述信息總結(jié)了它的代碼所做的貢獻(xiàn)以及修改的主題. 所以我們把訓(xùn)練集中的pull request作為歷史的document, 而新的pull request的標(biāo)題和描述信息作為query, 構(gòu)建信息檢索系統(tǒng). 并且在評(píng)審人推薦的過程中加入了評(píng)審人影響力因子的考量和時(shí)間維度衰減的考量.

3 基于信息檢索的pull request 評(píng)審人推薦

我們旨在推薦和新到來的pull request最相關(guān)的評(píng)審人, 用于減少評(píng)審時(shí)延并有效提高github的社交化編程的開發(fā)效率. 已有的bug分類研究[11-13]所采用的信息檢索的方法適用于我們的pull request推薦的場景. Pull request的標(biāo)題和描述信息作為標(biāo)記pull request的document; 新到來的pull request的標(biāo)題和描述信息作為query. 以此對(duì)pull request建模, 找出和目標(biāo)pull request最相關(guān)的top k 個(gè)pull request, 這top k個(gè)pull request下的評(píng)審人構(gòu)成推薦的候選評(píng)審人集合, 并基于評(píng)論次數(shù)對(duì)每位候選人進(jìn)行相關(guān)性打分, 返回得分最高的top 10個(gè)候選人作為最終的評(píng)審?fù)扑]人.

3.1 pull request的向量空間模型

在一個(gè)項(xiàng)目的場景下, 每個(gè)pull request采用它的標(biāo)題和描述信息來標(biāo)識(shí)為該pull request的document.該pull request下發(fā)表評(píng)論的開發(fā)者就是該pull request的評(píng)審人. 首先將pull request的停用詞和特殊符號(hào)去掉, 對(duì)剩下的詞做詞干還原. 我們采用向量空間模型將pull request通過標(biāo)題和描述信息映射成高維空間下的一個(gè)向量, 向量空間模型下的每一個(gè)維度代表一個(gè)詞, 而該pull request中的單詞出現(xiàn)的次數(shù)越多, 該維度獲得的權(quán)重越大. 我們利用tf-idf來計(jì)算每個(gè)詞的權(quán)重, 公式如下所示:

其中:

t: 1個(gè)單詞 (term)

pr: 1個(gè)pull request

PR: 給定項(xiàng)目中的所有pull request的倉庫

nt: 在pull request pr中單詞t所出現(xiàn)的次數(shù)

Npr: pr中的所有詞的個(gè)數(shù)

NpR: 給定項(xiàng)目中所有pull request的個(gè)數(shù)上述計(jì)算tfidf的公式表達(dá)的含義是:

3.2 pull request相似度

我們利用向量空間模型對(duì)pull request建模, 用tfidf對(duì)每一個(gè)pull request進(jìn)行向量空間的表示, 通過計(jì)算余弦相似度可以獲得任何兩個(gè)pull request的相似度得分, 由此, 當(dāng)新到來一個(gè)pull request的時(shí)候, 可以找到歷史上和該pull request語義上最相似的top k個(gè)歷史pull request. 余弦相似度的計(jì)算方法如下公式:

其中:

對(duì)新到來的pull request, 獲得與其相似度最高的top k個(gè)pull request之后, 我們將這k個(gè)pull request的評(píng)審人作為新到來的pull request的評(píng)審人候選集合. 并且乘以評(píng)論的次數(shù)求得每位候選評(píng)審人與新到來的pull request的相關(guān)性得分, 最終返回得分最高的top 10個(gè)評(píng)審人作為評(píng)審人推薦的結(jié)果.

4 基于時(shí)間和影響力因子的評(píng)審人推薦

第三部分描述的是用于pull request評(píng)審人推薦的傳統(tǒng)信息檢索方法. 這部分則描述了本文提出的基于時(shí)間和影響力因子的pull request評(píng)審人推薦對(duì)傳統(tǒng)信息檢索方法的改進(jìn).

4.1 基于時(shí)間和影響力因子的候選評(píng)審人的得分

本文基于評(píng)論的次數(shù)、評(píng)審時(shí)間維度、評(píng)審人的影響力因子這三個(gè)方面求得每位候選評(píng)審人與新到來的pull request的相關(guān)性得分.

4.1.1 評(píng)論次數(shù)

評(píng)論次數(shù)即候選評(píng)審人在相關(guān)的歷史pull request中評(píng)論了多少次. 評(píng)論次數(shù)越多, 候選評(píng)審人相關(guān)性的得分應(yīng)該越高. 對(duì)評(píng)論次數(shù)我們進(jìn)行l(wèi)og平滑, 公式如下:

其中:

nj,i: 評(píng)審人j在pri下的評(píng)論次數(shù)

Nj,i: 評(píng)審人j在pri下基于評(píng)論次數(shù)獲得的權(quán)重

4.1.2 評(píng)審時(shí)間維度

評(píng)審時(shí)間因素是我們重點(diǎn)考慮的維度之一, 比如與新到來的pull request 最相關(guān)的top k個(gè)歷史pull request中, 1年前的歷史pull request和1周內(nèi)的歷史pull request所占的權(quán)重應(yīng)該是不一樣的, 我們認(rèn)為評(píng)審人在一段時(shí)間內(nèi)的興趣是集中的, 所以最近的pull request顯然應(yīng)該賦予更高的權(quán)重[11], 我們采用了時(shí)間歸一化的公式來進(jìn)行時(shí)間維度的權(quán)重分配.

其中:

: 第i個(gè)相關(guān)的歷史pull request

timestamp(pri):pri的提交時(shí)間

baseline: 訓(xùn)練集中提交最早的pull request的提交前一天

deadline:訓(xùn)練集中提交最晚的pull request的提交當(dāng)天

但是上述時(shí)間歸一化會(huì)導(dǎo)致最早的歷史pull request的評(píng)審人在該pull request即使相關(guān)度非常高的情況下, 也會(huì)因?yàn)樯鲜鰰r(shí)間歸一化而大大衰減這部分的得分. 所以我們采用線性模型進(jìn)行時(shí)間維度的參數(shù)訓(xùn)練, 以獲得最終的時(shí)間權(quán)重計(jì)算公式:

其中tpri是上述時(shí)間歸一化的結(jié)果. 經(jīng)過模型的訓(xùn)練, 我們得出α=0.6, β=0.4 的時(shí)候, 返回推薦結(jié)果的準(zhǔn)確率比直接對(duì)時(shí)間進(jìn)行歸一化要好得多.

4.1.3 評(píng)審人的影響力因子

評(píng)審人在github項(xiàng)目中的影響力因子同樣也是非常重要的維度, github中有些很優(yōu)秀的人, 他們?cè)谀承╉?xiàng)目領(lǐng)域經(jīng)驗(yàn)豐富, 為開源社區(qū)的項(xiàng)目貢獻(xiàn)了很多高質(zhì)量、優(yōu)秀的代碼, 也是項(xiàng)目的核心成員, 他們?cè)趐ull request的評(píng)審中給出的意見也非常有效而準(zhǔn)確, 這些杰出的人會(huì)吸引很多人follow他們. 這樣基于follow和被follow的關(guān)系, 我們可以構(gòu)建github中開發(fā)者的關(guān)系網(wǎng), 它是一張以開發(fā)者為節(jié)點(diǎn)的圖, 從而利用著名的pagerank算法我們就可以獲得github中任何一位開發(fā)者的影響力因子的得分. 但是本文的評(píng)審人推薦應(yīng)用情境是在一個(gè)具體項(xiàng)目中的評(píng)審人(開發(fā)者)的影響力. 因此計(jì)算整個(gè)github中所開發(fā)者在整個(gè)github下的影響力是非常費(fèi)時(shí)而沒有意義的. 而如果具體到1個(gè)項(xiàng)目內(nèi)使用pagerank計(jì)算影響力, 由于開發(fā)者的所有follower可能在不同的項(xiàng)目中都有分布, 所以會(huì)造成項(xiàng)目內(nèi)的follow關(guān)系圖很難確定. 于是本文提出基于follower數(shù)量來對(duì)影響力因子的量化計(jì)算方法,這種方法實(shí)際上是對(duì)pagerank方法的簡化, 我們認(rèn)為follower數(shù)量越多的人, 他的評(píng)審的權(quán)重應(yīng)該比follower數(shù)量少的成員權(quán)重要高. 具體的計(jì)算公式如下:

其中:

Fi: 評(píng)審人i的影響力;

P: 項(xiàng)目P, 評(píng)審人推薦的作用范圍就是某個(gè)特定的項(xiàng)目P;

N（followers of i）∈P: 評(píng)審人i在項(xiàng)目P中的follower的個(gè)數(shù);

NMAX_followers: 項(xiàng)目P中, follower數(shù)的最大值.

該公式的右側(cè)相當(dāng)于對(duì)follwer的數(shù)目進(jìn)行了歸一化, 如果一個(gè)開發(fā)者在項(xiàng)目P中follower數(shù)為0, 則他在項(xiàng)目P中的影響力是最低的1; 開發(fā)者在P中的follower數(shù)越多, 則他在P中的影響力越大, 影響力最大可以為2.

4.2 候選人的得分計(jì)算

結(jié)合評(píng)論的次數(shù)、評(píng)審時(shí)間維度、評(píng)審人的影響力因子這三個(gè)方面, 最終的候選評(píng)審人與新到來的pull request的相關(guān)性得分計(jì)算公式如下:其中:

Scorej: 候選評(píng)審人j的最終得分

k: 與新到來的pull request最相關(guān)的k個(gè)歷史pull request

prnew: 新到來的pull request

pri: 第i個(gè)相關(guān)的歷史pull request

Nj,i: 評(píng)審人j在pri下評(píng)論的次數(shù)的權(quán)重

Tpri: 第i個(gè)相關(guān)的pull request評(píng)論的時(shí)間維度所獲得的權(quán)重

Fj: 候選評(píng)審人j的影響力因子

5 實(shí)驗(yàn)

5.1 數(shù)據(jù)集的選取

我們選取了github中比較熱門的10個(gè)項(xiàng)目用于實(shí)驗(yàn), 他們是scikit-learn、scala、rails、swift、ipython、jquery、akka、node、xbmc和homebrew. 這些項(xiàng)目都擁有大于1500個(gè)pull request, 數(shù)據(jù)集足夠充分用于進(jìn)行實(shí)驗(yàn). 同時(shí)我們做了如下過濾:

1) 首先對(duì)每個(gè)項(xiàng)目抓取最近的 1500條pull request的數(shù)據(jù), 對(duì)項(xiàng)目中的pull request標(biāo)題和描述信息,去除停用詞并進(jìn)行詞干還原之后, 將那些標(biāo)題和描述部分的單詞總和小于10個(gè)詞的pull request去掉, 因?yàn)樾∮?0個(gè)詞會(huì)導(dǎo)致描述該pull request的信息量過少.

2) 停用詞并進(jìn)行詞干還原之后, 將那些標(biāo)題和描述部分的單詞總和小于10個(gè)詞的pull request去掉, 因?yàn)樾∮?0個(gè)詞會(huì)導(dǎo)致描述該pull request的信息量過少.

3) 然后, 我們?nèi)サ粼u(píng)審人少于2個(gè)的pull request,因?yàn)橹辽?個(gè)評(píng)審人進(jìn)行評(píng)審才能使評(píng)審可信[14,15].

4) 對(duì)這1500個(gè)pull request過濾之后, 用最新的1000個(gè)pull request作為最終的數(shù)據(jù)集. 并劃分訓(xùn)練集和測(cè)試集, 前900個(gè)作為訓(xùn)練集, 后100個(gè)作為測(cè)試集.

候選評(píng)審人過濾: 訓(xùn)練集中的候選評(píng)審人如果只對(duì)1個(gè)pull request進(jìn)行過評(píng)審, 則將這個(gè)候選評(píng)審人排除掉. 我們認(rèn)為候選評(píng)審人更有可能是進(jìn)行過多次評(píng)審的開發(fā)者, 而不是偶然對(duì)1個(gè)pull request進(jìn)行過評(píng)審的開發(fā)者. 因?yàn)間ithub的開發(fā)者以及評(píng)審人都希望為自己所在的項(xiàng)目做出貢獻(xiàn), 所以他們會(huì)自發(fā)的利用自己在項(xiàng)目領(lǐng)域內(nèi)的經(jīng)驗(yàn), 不斷的多次對(duì)項(xiàng)目做出貢獻(xiàn), 所以我們不難發(fā)現(xiàn)大型項(xiàng)目中, 大多數(shù)評(píng)審人都會(huì)對(duì)多個(gè)pull request進(jìn)行多次的評(píng)審, 而核心成員擔(dān)任評(píng)審人角色時(shí), 他自主發(fā)起評(píng)審數(shù)目甚至?xí)_(dá)到數(shù)十甚至上百個(gè). 評(píng)審人經(jīng)過上述的過濾之后, 通過要余弦相似度的計(jì)算, 可以得到與新到來的pull request最相關(guān)的歷史pull request, 在這些歷史pull request下進(jìn)行評(píng)審的開發(fā)者于是構(gòu)成了候選評(píng)審人的集合.

5.2 評(píng)估方式

本文采用準(zhǔn)確率(precision)和召回率(recall)對(duì)評(píng)審人推薦結(jié)果進(jìn)行評(píng)估, 對(duì)返回的10個(gè)推薦結(jié)果, 分別計(jì)算top 1到top 10的準(zhǔn)確率和召回率. 計(jì)算方法如下公式:

5.3 實(shí)驗(yàn)效果對(duì)比

這部分我們對(duì)比了三組實(shí)驗(yàn)的結(jié)果, 分別是baseline、傳統(tǒng)的信息檢索方法(IR-base)的效果和本文提出的優(yōu)化后的考慮了影響力和時(shí)間因子的信息檢索方法(IR-optimal)的效果.

5.3.1 實(shí)驗(yàn)的baseline

Github中的大部分pull request是由各項(xiàng)目組的核心成員評(píng)審的. 因?yàn)樗麄儗?duì)項(xiàng)目更加了解, 而且具備豐富的編程經(jīng)驗(yàn)以及項(xiàng)目相關(guān)經(jīng)驗(yàn). 所以他們經(jīng)常能給出重要、準(zhǔn)確而且有效的評(píng)審意見, 并幫助pull request提交者改善他的代碼. 為了評(píng)估本文提出的實(shí)驗(yàn)方法的效果, 我們采用了對(duì)比的baseline, 在訓(xùn)練集中評(píng)審了pull request數(shù)最多的top k個(gè)開發(fā)者成為活躍評(píng)審人集合, 每個(gè)新到來的pull request都被分配給活躍評(píng)審人集合. 這些最活躍的開發(fā)者所獲得的推薦效果就構(gòu)成了我們的baseline.

5.3.2 推薦效果評(píng)估

三組實(shí)驗(yàn)的準(zhǔn)確率、召回率曲線如圖2所示, 我們描繪了10個(gè)項(xiàng)目中top 1 到top 10的平均準(zhǔn)確率以及平均召回率曲線.

由圖2可以看出隨著推薦的人數(shù)增多, 準(zhǔn)確率呈下降趨勢(shì), 召回率呈現(xiàn)上升趨勢(shì). 圖中顯示傳統(tǒng)信息檢索方法以及本文考慮了影響力和時(shí)間因子的信息檢索方法的推薦效果明顯好于baseline.

相對(duì)于傳統(tǒng)信息檢索方法而言, 本文提出的基于影響力因子和時(shí)間維度衰減的信息檢索方法在top 1到top 4上效果提升比較明顯. 我們列出了top 1到top 5的效果對(duì)比表格. 如表1所示. 我們的方法在top 1上準(zhǔn)確率達(dá)到68%, 比傳統(tǒng)信息檢索方法提升了8%,召回率達(dá)到18%.

此外, 我們通過計(jì)算本文提出的優(yōu)化后的信息檢索方法的F值, 發(fā)現(xiàn)在top 4的時(shí)候F值最大, 達(dá)到了0.514. 而且曲線表明推薦top 5到top 10的準(zhǔn)確率下降非常明顯, 這和我們的預(yù)期也相符, 實(shí)際上大多數(shù)pull request的評(píng)審人一般是少于5個(gè)的, 假設(shè)一個(gè)pull request只有3位評(píng)審人, 而我們推薦系統(tǒng)推薦top 10位評(píng)審的時(shí)的準(zhǔn)確率可想而知是會(huì)大大降低的. 前5個(gè)準(zhǔn)確率能得到保證是因?yàn)榛谛畔z索的推薦方法效果比較好, 但正因?yàn)閷?shí)際評(píng)審人少于5個(gè), 所以top 5到 top 10的候選評(píng)審人相關(guān)性得分會(huì)比較低, 造成這部分的推薦不能做到top1 到 top 4那么準(zhǔn)確, 從而造成p@k的準(zhǔn)確率下降明顯. 所有方法在top 1到 top 4上召回率上升速度比較快. 當(dāng)我們推薦top 10個(gè)評(píng)審人時(shí), 三種方法的召回率都達(dá)到了78%, 說明三種方法當(dāng)推薦到10位候選評(píng)審人時(shí), 都能保證比較好的召回.

此外, 通過深入研究我們發(fā)現(xiàn), pull request推薦結(jié)果會(huì)傾向于推薦那些歷史上進(jìn)行過多次評(píng)審的活躍的評(píng)審人, 這些人在開源項(xiàng)目中具有很多follower, 這與實(shí)際的github社區(qū)的評(píng)審情況相符合, 也從側(cè)面印證了baseline的有效性. 但本文提出的方法還考慮了pull request的之間的相關(guān)性, 評(píng)審人的影響力因子, 以及評(píng)審的時(shí)間維度衰減, 使得最終的推薦準(zhǔn)確率相對(duì)于傳統(tǒng)信息檢索方法以及baseline都有比較好的提升.

圖2 評(píng)審人推薦的準(zhǔn)確率、召回率曲線

表1 三組實(shí)驗(yàn)top 1 到top5的效果對(duì)比

6 結(jié)論和未來工作

在本文中, 首先我們將應(yīng)用于bug分類的信息檢索方法, 拓展應(yīng)用于pull request的評(píng)審人推薦中. 對(duì)新到來的pull request, 基于標(biāo)題和描述信息, 獲得和該pull request最相關(guān)top k個(gè)的歷史pull request. 這top k個(gè)歷史pull request下的評(píng)審人構(gòu)成了我們的候選評(píng)審人集合. 然后, 我們基于評(píng)審人的評(píng)論次數(shù)、github評(píng)審人的影響力因子以及基于pull request評(píng)審時(shí)間維度的衰減計(jì)算每位候選評(píng)審人相對(duì)于新到來的pull request的相關(guān)性得分, 最終返回得分top 10的評(píng)審人作為評(píng)審人推薦結(jié)果.

本文主要討論了github評(píng)審人的影響力因子量化度量方法, 以及基于pull request評(píng)審時(shí)間維度的衰減.并將這兩者結(jié)合到信息檢索方法中, 得出優(yōu)化后的信息檢索方法用于評(píng)審人推薦. 并對(duì)baseline、傳統(tǒng)信息檢索方法、優(yōu)化后的信息檢索方法進(jìn)行效果評(píng)估, 實(shí)驗(yàn)表明, 優(yōu)化后的信息檢索方法推薦的準(zhǔn)確率提升比較明顯, 尤其是top 1 到top 4的推薦效果明顯優(yōu)于其他兩種方法. 未來, 我們會(huì)對(duì)評(píng)審人的影響力因子量化進(jìn)行更深入的探索, 分析開發(fā)者之間的有效評(píng)論,基于語義評(píng)估評(píng)審人的評(píng)論對(duì)該pull request所做的貢獻(xiàn). 并構(gòu)建開發(fā)者之間的評(píng)論關(guān)系網(wǎng), 由此獲得影響力因子評(píng)估的更精確的量化方法, 使得本文提出的信息檢索方法的準(zhǔn)確率和召回率效果進(jìn)一步提升.

1 Begel A, Bosch J, Storey MA. Social networking meets software development: Perspectives from GitHub, MSDN, stack exchange, and TopCoder. Software IEEE, 2013, 30(1): 52–66.

2 Gousios G, Zaidman A, Storey MA, et al. Workpractices and challenges in pull-based development: The integrator’s perspective. 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (ICSE). IEEE Computer Society. 2015. 358–368.

3 Gousios G, Bacchelli A. Work practices and challenges in pull-based development: The contributor’s perspective. IEEE Software, 2015, 32(1).

4 Yu Y, Wang H, Filkov V, et al. Wait for it: Determinants of pull request evaluation latency on GitHub. 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories (MSR). IEEE. 2015. 367–371.

5 Vasilescu B, Yu Y, Wang H, et al. Quality and productivity outcomes relating to continuous integration in GitHub. Proc. of the 2015 10th Joint Meeting on Foundations of Software Engineering. ACM. 2015. 805–816.

6 Cubranic D, Murphy GC. Automatic bug triage using text categorization. Seke: Sixteenth International Conference on Software Engineering & Knowledge Engineering. 2004. 92–97.

7 Canfora G, Cerulo L. Supporting change request assignment in open source development. Proc. of the 2006 ACM Symposium on Applied Computing. ACM. 2006. 1767–1772.

8 Linares-Vásquez M, Hossen K, Dang H, et al. Triaging incoming change requests: Bug or commit history, or code authorship? 2012 28th IEEE International Conference on Software Maintenance (ICSM). IEEE. 2012. 451–460.

9 Tamrawi A, Nguyen TT, Al-Kofahi JM, et al. Fuzzy set and cache-based approach for bug triaging. Proc. of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering. ACM. 2011. 365–375.

10 Yu Y, Wang H, Yin G, et al. Who should review this pull-request: Reviewer recommendation to expedite crowd collaboration. 2014 21st Asia-Pacific Software Engineering Conference (APSEC). IEEE. 2014, 1. 335–342.

11 Anvik J, Hiew L, Murphy GC. Who should fix this bug? Proc. of the 28th International Conference on Software Engineering. ACM. 2006. 361–370.

12 Bhattacharya P, Neamtiu I, Shelton CR. Automated, highly-accurate, bug assignment using machine learning and tossing graphs. Journal of Systems and Software, 2012, 85(10): 2275–2292.

13 Jeong G, Kim S, Zimmermann T. Improving bug triage with bug tossing graphs. Proc. of the the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering. ACM. 2009. 111–120.

14 Sauer C, Jeffery DR, Land L, et al. The effectiveness of software development technical reviews: A behaviorally motivated program of research. IEEE Trans. on Software Engineering, 2000, 26(1): 1–14.

15 Rigby PC, Bird C. Convergent contemporary software peer review practices. Proc. of the 2013 9th Joint Meeting on Foundations of Software Engineering. ACM. 2013. 202-212.

Code Reviewer Recommendation Based on Time and Impact Factor for Pull Request in Github

LU Song1,2, YANG Da1, HU Jun1, ZHANG Xiao1,212
(Institute of Software, Chinese Academy of Sciences, Beijing 100190, China) (University of Chinese Academy of Sciences, Beijing 100190, China)

The pull request mechanism is widely used for integrating developers’ code in github, so that developers can make contribution for open source projects. The code review of pull request is an essential method to maintain the high quality of code in github. Assigning appropriate reviewers for a newly coming pull request can effectively reduce the delay between the submission of a pull request and the actual review of it. At present, the pull request is assigned manually by core developers in the project. To reduce this cost, we propose a reviewer recommender system based on information retrieval. This method can automatically recommend highly relevant reviewers for a newly coming pull request. Our method has also taken the impact factor and time decaying factor into consideration, and has received good performance that the top 1 precision can reach 68% and top 10 recall rate can reach 78%.

pull request; code review; information retrieval; time factor; impact factor

國家自然科學(xué)基金(91218302,91318301)

2016-03-24;收到修改稿時(shí)間:2016-04-14

10.15888/j.cnki.csa.5455