基于時間和影響力因子的Github Pull Request評審人推薦①

盧 松, 楊 達, 胡 軍, 張 瀟

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

基于時間和影響力因子的Github Pull Request評審人推薦①

盧 松1,2, 楊 達1, 胡 軍1, 張 瀟1,2

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

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

pull request; 代碼評審; 信息檢索; 時間因子; 影響力因子

1 概述

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

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

1) 首先contributor找到一個感興趣的項目, 并follow一些該項目中的知名的開發者, watch該項目.

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

3) 項目內的所有的開發者都能夠在項目的pull request庫中評審已提交的pull request. 他們可以討論項目是否需要這個新特性, 提交的代碼是否符合規范,以及能否提升該pull request代碼的質量;

4) contributor根據評審人的建議, 會完善并更新他的pull request, 接著評審人再次評審修改后的pull request;

5) 項目的核心負責人基于所有評審人的意見決定是把該pull request合并到項目代碼中還是拒絕它.

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

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

圖1 pull request中評審人進行評審討論

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

總體來說, 本文的貢獻如下:

1) 使用了信息檢索(information retrieval)的方法在評審人相關性評估中, 我們加入了影響力因子這個重要的考量因素. 本文首次提出在github項目中基于follower的數量來對影響力因子的量化計算方法, 我們認為follower數量越多的人, 他的評審的權重應該比follower數量少的成員權重高.

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

2 相關工作

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

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

本文所做的工作是基于信息檢索的方法對pull request進行建模, pull request的標題和描述信息總結了它的代碼所做的貢獻以及修改的主題. 所以我們把訓練集中的pull request作為歷史的document, 而新的pull request的標題和描述信息作為query, 構建信息檢索系統. 并且在評審人推薦的過程中加入了評審人影響力因子的考量和時間維度衰減的考量.

3 基于信息檢索的pull request 評審人推薦

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

3.1 pull request的向量空間模型

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

其中:

t: 1個單詞 (term)

pr: 1個pull request

PR: 給定項目中的所有pull request的倉庫

nt: 在pull request pr中單詞t所出現的次數

Npr: pr中的所有詞的個數

NpR: 給定項目中所有pull request的個數上述計算tfidf的公式表達的含義是:

3.2 pull request相似度

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

其中:

對新到來的pull request, 獲得與其相似度最高的top k個pull request之后, 我們將這k個pull request的評審人作為新到來的pull request的評審人候選集合. 并且乘以評論的次數求得每位候選評審人與新到來的pull request的相關性得分, 最終返回得分最高的top 10個評審人作為評審人推薦的結果.

4 基于時間和影響力因子的評審人推薦

第三部分描述的是用于pull request評審人推薦的傳統信息檢索方法. 這部分則描述了本文提出的基于時間和影響力因子的pull request評審人推薦對傳統信息檢索方法的改進.

4.1 基于時間和影響力因子的候選評審人的得分

本文基于評論的次數、評審時間維度、評審人的影響力因子這三個方面求得每位候選評審人與新到來的pull request的相關性得分.

4.1.1 評論次數

評論次數即候選評審人在相關的歷史pull request中評論了多少次. 評論次數越多, 候選評審人相關性的得分應該越高. 對評論次數我們進行log平滑, 公式如下:

其中:

nj,i: 評審人j在pri下的評論次數

Nj,i: 評審人j在pri下基于評論次數獲得的權重

4.1.2 評審時間維度

評審時間因素是我們重點考慮的維度之一, 比如與新到來的pull request 最相關的top k個歷史pull request中, 1年前的歷史pull request和1周內的歷史pull request所占的權重應該是不一樣的, 我們認為評審人在一段時間內的興趣是集中的, 所以最近的pull request顯然應該賦予更高的權重[11], 我們采用了時間歸一化的公式來進行時間維度的權重分配.

其中:

: 第i個相關的歷史pull request

timestamp(pri):pri的提交時間

baseline: 訓練集中提交最早的pull request的提交前一天

deadline:訓練集中提交最晚的pull request的提交當天

但是上述時間歸一化會導致最早的歷史pull request的評審人在該pull request即使相關度非常高的情況下, 也會因為上述時間歸一化而大大衰減這部分的得分. 所以我們采用線性模型進行時間維度的參數訓練, 以獲得最終的時間權重計算公式:

其中tpri是上述時間歸一化的結果. 經過模型的訓練, 我們得出α=0.6, β=0.4 的時候, 返回推薦結果的準確率比直接對時間進行歸一化要好得多.

4.1.3 評審人的影響力因子

評審人在github項目中的影響力因子同樣也是非常重要的維度, github中有些很優秀的人, 他們在某些項目領域經驗豐富, 為開源社區的項目貢獻了很多高質量、優秀的代碼, 也是項目的核心成員, 他們在pull request的評審中給出的意見也非常有效而準確, 這些杰出的人會吸引很多人follow他們. 這樣基于follow和被follow的關系, 我們可以構建github中開發者的關系網, 它是一張以開發者為節點的圖, 從而利用著名的pagerank算法我們就可以獲得github中任何一位開發者的影響力因子的得分. 但是本文的評審人推薦應用情境是在一個具體項目中的評審人(開發者)的影響力. 因此計算整個github中所開發者在整個github下的影響力是非常費時而沒有意義的. 而如果具體到1個項目內使用pagerank計算影響力, 由于開發者的所有follower可能在不同的項目中都有分布, 所以會造成項目內的follow關系圖很難確定. 于是本文提出基于follower數量來對影響力因子的量化計算方法,這種方法實際上是對pagerank方法的簡化, 我們認為follower數量越多的人, 他的評審的權重應該比follower數量少的成員權重要高. 具體的計算公式如下:

其中:

Fi: 評審人i的影響力;

P: 項目P, 評審人推薦的作用范圍就是某個特定的項目P;

N（followers of i）∈P: 評審人i在項目P中的follower的個數;

NMAX_followers: 項目P中, follower數的最大值.

該公式的右側相當于對follwer的數目進行了歸一化, 如果一個開發者在項目P中follower數為0, 則他在項目P中的影響力是最低的1; 開發者在P中的follower數越多, 則他在P中的影響力越大, 影響力最大可以為2.

4.2 候選人的得分計算

結合評論的次數、評審時間維度、評審人的影響力因子這三個方面, 最終的候選評審人與新到來的pull request的相關性得分計算公式如下:其中:

Scorej: 候選評審人j的最終得分

k: 與新到來的pull request最相關的k個歷史pull request

prnew: 新到來的pull request

pri: 第i個相關的歷史pull request

Nj,i: 評審人j在pri下評論的次數的權重

Tpri: 第i個相關的pull request評論的時間維度所獲得的權重

Fj: 候選評審人j的影響力因子

5 實驗

5.1 數據集的選取

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

1) 首先對每個項目抓取最近的 1500條pull request的數據, 對項目中的pull request標題和描述信息,去除停用詞并進行詞干還原之后, 將那些標題和描述部分的單詞總和小于10個詞的pull request去掉, 因為小于10個詞會導致描述該pull request的信息量過少.

2) 停用詞并進行詞干還原之后, 將那些標題和描述部分的單詞總和小于10個詞的pull request去掉, 因為小于10個詞會導致描述該pull request的信息量過少.

3) 然后, 我們去掉評審人少于2個的pull request,因為至少2個評審人進行評審才能使評審可信[14,15].

4) 對這1500個pull request過濾之后, 用最新的1000個pull request作為最終的數據集. 并劃分訓練集和測試集, 前900個作為訓練集, 后100個作為測試集.

候選評審人過濾: 訓練集中的候選評審人如果只對1個pull request進行過評審, 則將這個候選評審人排除掉. 我們認為候選評審人更有可能是進行過多次評審的開發者, 而不是偶然對1個pull request進行過評審的開發者. 因為github的開發者以及評審人都希望為自己所在的項目做出貢獻, 所以他們會自發的利用自己在項目領域內的經驗, 不斷的多次對項目做出貢獻, 所以我們不難發現大型項目中, 大多數評審人都會對多個pull request進行多次的評審, 而核心成員擔任評審人角色時, 他自主發起評審數目甚至會達到數十甚至上百個. 評審人經過上述的過濾之后, 通過要余弦相似度的計算, 可以得到與新到來的pull request最相關的歷史pull request, 在這些歷史pull request下進行評審的開發者于是構成了候選評審人的集合.

5.2 評估方式

本文采用準確率(precision)和召回率(recall)對評審人推薦結果進行評估, 對返回的10個推薦結果, 分別計算top 1到top 10的準確率和召回率. 計算方法如下公式:

5.3 實驗效果對比

這部分我們對比了三組實驗的結果, 分別是baseline、傳統的信息檢索方法(IR-base)的效果和本文提出的優化后的考慮了影響力和時間因子的信息檢索方法(IR-optimal)的效果.

5.3.1 實驗的baseline

Github中的大部分pull request是由各項目組的核心成員評審的. 因為他們對項目更加了解, 而且具備豐富的編程經驗以及項目相關經驗. 所以他們經常能給出重要、準確而且有效的評審意見, 并幫助pull request提交者改善他的代碼. 為了評估本文提出的實驗方法的效果, 我們采用了對比的baseline, 在訓練集中評審了pull request數最多的top k個開發者成為活躍評審人集合, 每個新到來的pull request都被分配給活躍評審人集合. 這些最活躍的開發者所獲得的推薦效果就構成了我們的baseline.

5.3.2 推薦效果評估

三組實驗的準確率、召回率曲線如圖2所示, 我們描繪了10個項目中top 1 到top 10的平均準確率以及平均召回率曲線.

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

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

此外, 我們通過計算本文提出的優化后的信息檢索方法的F值, 發現在top 4的時候F值最大, 達到了0.514. 而且曲線表明推薦top 5到top 10的準確率下降非常明顯, 這和我們的預期也相符, 實際上大多數pull request的評審人一般是少于5個的, 假設一個pull request只有3位評審人, 而我們推薦系統推薦top 10位評審的時的準確率可想而知是會大大降低的. 前5個準確率能得到保證是因為基于信息檢索的推薦方法效果比較好, 但正因為實際評審人少于5個, 所以top 5到 top 10的候選評審人相關性得分會比較低, 造成這部分的推薦不能做到top1 到 top 4那么準確, 從而造成p@k的準確率下降明顯. 所有方法在top 1到 top 4上召回率上升速度比較快. 當我們推薦top 10個評審人時, 三種方法的召回率都達到了78%, 說明三種方法當推薦到10位候選評審人時, 都能保證比較好的召回.

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

圖2 評審人推薦的準確率、召回率曲線

表1 三組實驗top 1 到top5的效果對比

6 結論和未來工作

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

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

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

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

2016-03-24;收到修改稿時間:2016-04-14

10.15888/j.cnki.csa.5455