開源社區問題解決過程人員參與積極性的影響因素分析

劉曄暉,趙海燕,曹 健,陳慶奎

1(上海市現代光學系統重點實驗室,光學儀器與系統教育部工程研究中心,上海理工大學光電信息與計算機工程學院,上海 200093)

2(上海交通大學 計算機科學與技術系,上海 200030)

E-mail:1092778656@qq.com

1 引 言

問題追蹤器已成為現代軟件開發項目中必不可少的協作工具[1],它們可以用于注冊和跟蹤新功能請求、開發任務和錯誤等.在開源項目如Github中,每個人都可以在項目的問題跟蹤器上打開一個新問題,關注該項目的開發人員看到該問題時可能會進行回答,問題被解決后提問者會關閉該問題,之后也有可能會重新開啟.

問題的回答者可能直接來自于項目的核心團隊成員或者是對該項目感興趣的外部貢獻者.等待相應的開發人員分析回答問題的過程并不總是迅速的,這將導致問題處理不夠及時甚至長久得不到解決,因此出現了一系列研究[2-6]旨在推薦能夠回答該問題的專家.一般來說,這些方法將過去類似問題的回答者作為推薦對象,因此,其推薦的質量依賴于所選擇的衡量問題相似性或者相關性的屬性.這種依據過去的直觀經驗進行推薦的方法在新問題上是無法奏效的.

顯然,了解哪些因素影響開發人員參與問題解決過程的積極性具有重要的意義.基于這些因素進行更為有效的人員分配,也可以設計更好的參與者推薦系統,避免無效的、不合理的推薦,從而導致問題長久得不到解決、延緩了項目的開發進度.

為了確定影響開發人員回答問題積極性的因素,我們圍繞以下兩個方面的問題進行了研究:

1)問題的特征如何影響開發人員回答問題的積極性？

2)開發人員的特性如何影響其回答問題的積極性？

本文的研究依托于開源軟件平臺Github產生的數據,從中獲取了開發人員角色、開發人員社交關系、問題難度、文本長度、是否包含代碼塊、問題種類、開發人員之間的配對關系等多種影響因素,并對這些因素的作用進行了深入分析.

本文組織如下:第2節介紹了開源軟件中問題解決過程的相關研究;第3節詳細闡述了我們的研究使用的數據和具體的方法;第4節對結果進行了詳細的量化分析和討論,最后進行總結并對后續工作進行展望.

2 相關工作

Github上,開源軟件的開發過程由5個步驟組成的工作流[7]組成:

1)討論問題:討論項目的一個新功能,商定需要做什么,主要是許多開發人員就一個新的功能或需要修改的功能進行溝通,并最終確定要增加或修改什么樣的功能;

2)指定事務:為討論出的功能創建一個分支;

3)執行事務:在指定事務工作流中創建的分支上建立一個功能分支以使其工作;

4)審查事務:功能完成后推送到遠程端,通過pull request進行代碼審查;

5)問題解決后迭代:在審查中發現問題,進行問題討論,直到問題被解決.代碼合并到主分支.可以看出,問題討論和解決在其中具有重要作用.

Github中項目開發人員的角色分為內部人員和外部人員,其中,內部人員(inner)指真正參與到項目的開發人員,包括項目的成員(Member)、協作者(Collaborator)以及貢獻者(Contributor),其他人則為外部人員(outer).而Member指的是成員,組織分組內權限最低的角色,按照不同的組織設置,有些Member只限于對某些子庫具備查看或寫的權限;Collaborator指的是合作開發者,被庫的所有者邀請共同開發某一項目,擁有對庫的讀寫權限;Contributor指的是貢獻者,對項目有所貢獻(如提交代碼,修復bug等)的開發者,但不具備合作開發者的訪問權限.

最近針對開源軟件中的問題解決過程,很多學者進行了研究.對于發布的問題的文本內容是否足以將問題分類,Antoniol等人進行了研究分析[8].Assar等人通過對問題文本進行聚類來預測問題解決時間[9].Bhattacharya等人基于Eclipse、Chrome、Firefox、 Seamonkey和Thunderbird這5個開源項目的512474個問題對問題解決時間的影響因素進行了分析,結果表明bug的修復時間與其修復的可能性和bug的提交者沒有相關性[10].為了找出影響問題修復的因素,Guo等人重點對Windows Vista和Windows 7中的問題相關的因素以及參與處理問題的開發人員之間的關系進行了分析,研究結果表明聲譽好的開發人員提交的問題更容易被解決,且開發人員間的人際關系對問題解決也有重要影響[11].Murgia對Github中34個開源項目的14000多個問題進行分析,發現問題解決時間取決于維護類型[12].Tian等人提出了一種基于機器學習的自動化方法,將問題的時間、文本、提交者和嚴重性等元素考慮進去,從而確定問題的優先級[13].

上述研究主要關注了影響問題解決過程速度的因素,還缺少對人員參與問題解決過程的積極性的影響因素的研究.本文的主要研究目的是旨在找出影響開發人員加入問題討論的因素,通過調整這些因素可以使得問題解決的人員積極性更高.

3 數據和方法

在這項工作中,我們采用了關聯規則挖掘技術,以揭示數據中的隱含信息.具體而言,我們的研究采用了知識發現(Konwledge Discovery in Database,KDD)過程[14],即:1)數據選擇;2)預處理;3)數據轉換和填充;4)關聯規則提取;5)結果解釋與評價.在數據選擇中,我們使用GHTorrent[15]、Github API(1)https://developer.github.com/v3/以及直接從Github(2)https://github.com/爬取相關數據;在數據預處理過程中,我們對數據進行清洗和屬性選擇,以刪除缺少、不正確或不一致的數據項;在數據轉化和填充中,我們對一些數值屬性進行了離散化,以提高結果的語義;我們使用Apriori算法實現關聯規則提取[16];最后,對于結果解釋和評價,我們對每個研究問題所得結果都進行了具體分析.

為回答第一方面的問題,我們通過對問題的難易度、文本長度、是否含有代碼以及問題的類別進行關聯規則挖掘,我們總結分析了問題特征對開發人員回答問題的影響程度.結果將在第4.1節中討論.

為回答第二方面的問題,我們挖掘了包含問題提出者以及回答者角色屬性的關聯規則,比如開發人員對項目有沒有貢獻、有貢獻的開發人員是Member還是Contributor、問題提出者與回答者是否是熟人以及開發人員是否經常一起回答問題.除了對一些關聯規則進行置信度分析外,我們還進行了定性分析,以便更好地理解結果.第4.2節給出了分析結果.

3.1 問題及評論的數據

我們從Github中選擇了23個項目共57,244個問題進行了研究,其中流行的項目有10個,有效標簽多的項目有13個.為了從整體上提問者角色對開發人員積極性的影響,我們根據Github上的star數選取了最流行的10個項目;我們從這10個流行項目中隨機選取了5個流行項目(即jasmine、istio、realm-cocoa、elixir和metabase)研究開發人員角色、開發人員社交關系、問題難度、文本長度、是否含有代碼塊、開發人員之間的配對關系等影響因素.在研究問題類型對開發人員積極性的影響這一問題時,我們挑選了13個有效標簽較多的項目進行研究.

我們研究的項目包含了很多開發人員提交的問題,考慮到不同的開發人員提交的問題數量,我們使用了不同維度的屬性去試圖理解可能影響開發人員去回答問題的不同因素.涉及的屬性如表1所示.

在屬性預處理過程中,判斷開發人員是否是熟人首先需要先建立開發人員歷史交互信息表,通過統計分析,50%以上的開發人員只有一次交互信息,因此我們假設問題提問者與回答者交互次數大于1次為熟人.

表1 本文使用到的屬性

Table 1 Attributes used in this study

屬 性 描 述repoter_type提交問題的開發人員類型,其中inner指Member、Contributor或Collaborator,outer指除inner意外的其他人user_type對問題進行回答的開發人員類型,類型同repoter_typeacquaintance開發人員是否是熟人degree_type問題的難度等級,具體劃分為easy、normal和toughissueCleanedBodyLen去除停用詞、標點后的問題標題與內容總文本長度,共四個等級:short、medium、long以及longercode問題文本中是否有代碼issue_category問題類別,分為:adaptive、corrective、perfective以及preventive

考慮到一個簡單問題可能會被很多用戶回答,而一個困難問題可能只有幾個人回答,參與回答問題的人數可以成為表征問題難易程度的因素之一;此外,將問題解決的時間間隔作為問題難易程度影響的因素之一,考慮到衡量問題難度的計算中,問題耗費的時間越長表示該問題越難,反之則問題越容易.這里,當問題狀態為closed則認為問題被解決.我們使用公式(1)和公式(2)來計算問題qid的難度值qdqidqdqid.

(1)

(2)

其中,Aqid是問題qid的答案,|Aqid|表示答案集合的大小(也就是對問題qid進行回復的答案個數);Tavg是問題qid的平均耗費時間,單位是分鐘,Tai是問題qid關閉的時間,Tqid則是問題qid發布的時間;τ是一個調節參數,為避免計算時結果下降太快在這里被設置為1/3600.

在將問題映射上到維護類型的時候,我們根據Github開發人員為問題打的標簽,采用Murgia等人的方法對問題的維護類型進行劃分[12].我們沒有映射任何不清楚或不屬于維護類型的標簽,例如,標簽GUI和Mobile是通用標簽,不提供關于所執行的維護類型的提示,因此不會劃分到四大維護類型中.出于同樣的原因,我們沒有考慮使用不同維護類型的標簽,將這些標簽映射為糾正性、完善性、適應性和預防性維護都會對我們的分析的有效性造成影響.由于大部分問題有效標簽較少,我們從眾多流行項目中挑選了13個項目,因為它們至少有一個問題含有與維護類型相關的標簽.

3.2 關聯規則

關聯規則的提取是數據挖掘中的一項重要任務,其目的是找出數據庫中屬性之間的關系[17],關聯規則表示應用程序領域中以特定頻率發生的數據項之間的關系模式.

本文運用的方法采用了多維關聯規則的概念[17]:給定一個關系數據庫D,多維關聯規則X→Y表示為:X1∩X2∩…∩Xn→Y1∩Y2∩…∩Ym,其中n≥1,m≥1,而Xi(1≤i≤n)和Yj(1≤j≤m)是D不同屬性的條件定義.

關聯規則X→Y在一定程度上表明:先導X的出現意味著后繼Y的出現.關聯規則的相關性主要通過兩個度量指標來評估:支持度和置信度[18].支持度由滿足先導條件和后繼條件的實例的百分比定義,計算如下:Sup(X→Y)=TX∩Y/T,其中TX∩Y表示滿足條件X和Y的實例的數量,T是D中實例數量;置信度表示在先導發生的條件下后繼發生的概率,計算公式如下:Conf(X→Y)=TX∩Y/TX,其中TX表示滿足先導X發生的實例數量.支持度和置信度在關聯規則挖掘中充當過濾器的作用,即只有滿足最小支持度閾值和置信度閾值的規則才會被提取.

另一個度量指標是規則X→Y的Lift,它表示給定X條件發生的概率,Y條件發生的概率會怎樣變化.Lift是由規則的置信度以及其結果的支持度的比值,即:Lift(X→Y)=Conf(X→Y)/Sup(Y),其中Sup(Y)表示滿足Y條件的數據集中的實例數.當Lift=1時,X和Y之間條件獨立,也就是說,先導的出現并不會影響后繼的出現.另一方面,Lift>1表示先導和后繼之間存在正相關,這意味著X的出現增加了Y發生的幾率.相反,當Lift<1時,先導和后繼之間存在負相關,這表明X的出現會降低Y發生的幾率.

為了說明支持度和置信度度量的作用,我們假設規則為D中的Sup(user_type=″Memer″)=50%(對結果的支持度滿足條件user_type=″Memer″的實例數量).根據這條規則得到的Lift=1.5,因為Lift(R)=75/50=1.5,其中75%是規則的置信度.在本例中,結果表明當提交問題的人是″Memer″時,被″Memer″的開發人員回答的幾率增加50%.

我們還對一些規則進行了置信度分析,以確定是先導影響后繼還是后繼影響先導,當規則在方向(X→Y)上的置信度顯著高于在方向(Y→X)上的置信度時,我們說X影響Y而不是Y反過來影響X.

我們使用Apriori算法來提取關聯規則[16].考慮到數據中的大量實例和回答問題的開發人員較少,我們使用0.1%的最低支持度挖掘規則.因此我們從jasmine、istio、realm-cocoa、elixir和metabase項目中分別獲得了2,5,4,4,6項.考慮到只有2個issue提供的證明較弱,我們在本文中只展示5個項目中至少有4個問題支持的關聯規則,這一決定能確保它們不是隨機發生的.

4 結果和分析

4.1 問題1:問題的特征是否會影響開發人員回答問題的積極性？

在本小節中,我們討論問題的特征對回答者的影響,這些特征包括問題的難度、文本長度、是否含有代碼以及問題的類別.此外,在某些情況下,我們還對一些特殊模式進行了定性分析.

4.1.1 問題的難易程度是否影響回答者的積極性？

表2顯示了簡單問題對回答者的影響.結果表明,簡單的問題會激勵某些開發人員去討論.例如規則1中,如果是一個簡單的問題,那么被”cwbeck”回答的機會增加357%.由于(Y→X)方向的置信度遠遠大于(X→Y)方向的置信度,說明開發人員對問題難度等級有明顯偏好.在項目elixir中開發人員”mguimas”回答的問題有90.91%是簡單問題.

表2degree_type=easy→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 2 Association rules of typedegree_type=easy→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1metabasecwbeck0.10.58804.572metabasezaiddabaeen0.150.8666.673.813metabaseMarcGJA0.10.5866.673.814realm-cocoabryan1anderson0.10.3481.822.75jasminejoshuacc0.231.01602.696istionmnellis0.110.8629.632.427istioymesika0.534.3125.482.088istiogyliu5130.322.5924.742.029realm-cocoaGreatApe0.240.856.761.8710elixirmguimas0.130.2790.911.8611realm-cocoawebmagnets0.10.3452.941.7512jasminejaapz0.190.8438.461.7213elixirNobbZ0.330.6875.761.5514elixirwojtekmach0.450.9375.561.5415jasmineamavisca0.190.8433.331.49

當分析以degree_type=easy為前提的規則時,我們還驗證了其他程度的問題與回答者之間是否存在關聯.圖1和圖2說明了這種模式,其中標識符(#1、#2和#3)表示每個項目具有最高Lift值的規則.degree_type=normal和degree_type=tough對開發人員的影響與degree_type=easy的影響結果類似.值得注意的是,盡管istio項目中存在Lift>1的規則,但是當問題degree_type=normal和degree_type=tough發生時,開發人員回答問題的幾率并沒有顯著增加.

圖1 degree_type=normal→user類型的Lift

我們的結果表明,開發人員喜歡挑戰問題的難易程度不同,這可能與其專業知識、技能水平有關.

4.1.2 問題的長度對回答者的積極性有影響嗎？

Github中的Issue通常包含標題和內容,其文本長度也許會影響開發人員閱讀興趣,太長的問題可能會讓開發人員喪失閱讀耐心,我們假設問題的文本長度對回答者有影響,通過將問題的標題和內容合并到一個文本中,計算其純文本長度,從而將問題長度分成4個范圍.表3顯示了短文本問題對開發人員的影響.

圖3、圖4和圖5分別顯示了文本長度變化時項目jasmine、istio、realm-cocoa、elixir和metabase中的規則Lift值.標識符(#1、#2和#3)表示項目中Lift值最高的規則.值得注意的是,當文本長度變得特別長時,特定的開發人員回答該問題的機會顯著增加,這表明有些人對長文本有著較強偏好.

圖2 degree_type=tough→user類型的Lift

結果表明,不同的文本長度對開發人員回答的積極性有影響.一些開發人員傾向于回答簡潔明了的問題,而有些開發人員喜歡回答內容詳實的問題.

圖3 issueCleanedBodyLen=medium→user類型的Lift

4.1.3 問題中含有代碼是否影響回答者的積極性？

開源社區的存在是為了加快項目的開發進程,往往涉及到編程技術問題,因此很多問題會含有代碼塊,對編程感興趣的專業開發人員可能會傾向于回答含有代碼的問題.因此我們對問題中是否含有代碼與開發人員之間進行關聯規則挖掘.表4顯示了挖掘結果,結果表明,一些開發人員回答含有代碼的問題的機會更高.例如在項目elixir中,開發人員” ianrumford”、”c0b”和”lau”回答含有代碼的問題的機會增加了79%(Lift=1.79)、70%(Lift=1.7)和68%(Lift=1.68).在項目jasmine、istio、realm-cocoa和metabase上可以推算出類似的模式.此外,我們還對這個場景進行了規則置信度分析.從表4可以看出,在每種情況下,(Y→X)方向的置信度遠遠大于(X→Y)方向的置信度,這表明這些開發人員傾向于選擇評論含有代碼的問題.

表3issueCleanedBodyLen=short→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 3 Association rules of typeissueCleanedBodyLen=short→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1jasminemightyiam0.140.651004.672jasminedwt0.140.6585.7143jasminefetis0.120.5483.333.894elixironeeman0.140.861.113.525realm-cocoashmidt0.130.6461.113.096istiosakshigoel120.321.7754.963.057istiosebastienvas0.341.8754.293.018realm-cocoawebmagnets0.130.6754.762.779elixirdevinus0.432.4747.552.7410metabasekdoh1.397.0751.422.6211elixirorenbenkiki0.150.8741.382.3912realm-cocoabigfish240.190.9540.242.0413Istioldemailly1.659.1536.682.0414metabasemazameli1.598.126.051.3315metabasetlrobinson1.638.3223.321.19

圖4 issueCleanedBodyLen=long→user類型的Lift

圖5 issueCleanedBodyLen=longer→user類型的Lift

我們的結果指出,部分開發人員對回答含有代碼的問題有明顯偏好.在問答者推薦系統中,根據問題中是否含有代碼將其推薦給相應的開發人員可以提高用戶對問題的積極性.

4.1.4 問題的類別對回答者的積極性有影響嗎？

軟件維護是任何成功的軟件項目的關鍵組成部分,在強調迭代和增量開發的現代開發過程中也是如此.本節我們研究了維護活動類型與開發人員之間的關系.在我們的實證研究中,Github存儲的問題可歸為糾正、適應、完善或預防性維護問題.表5顯示了各種維護問題與開發人員之間的規則.從這些規則可以得出這樣的結論:一些開發人員傾向于回答預防性的問題,如規則1、規則3和規則4顯示,當問題為預防性問題時,開發人員” SimonVT”、” ezequiel”和” madrobby”回答該類問題的可能性分別提高17.55倍(Lift=18.55)、14.28倍(Lift=15.28)和11.15倍(Lift=12.15).其他類型的問題對開發人員的影響也可以從表中推斷出.

結果表明,問題的類型對開發人員的參與有明顯影響,這可能和開發人員擅長的領域有關.我們的問題分類基于Murgia等人的工作進行的,其分類并不全面,如果通過人工打標簽或者通過半監督學習將問題分類,結果可能更明顯.

4.2 問題2:開發人員的特征是否會其回答問題的種類？

本節中,我們討論了開發人員的特征(如:是否為貢獻者、是否是熟人等)對其回答問題的影響.

4.2.1 問題提出者的角色是否影響回答者的積極性？

開發人員的一些特征在提交問題以及回答問題時就已經知道了,例如是否為”Member”或者是”Contributor”.我們的結果表明提出問題的人的角色可能會影響開發人員的回答.首先我們從項目整體出發,判斷問題提問者的角色是否會對回答者有影響.表6顯示當問題提問者是inner時被inner回答的關聯規則(升序遞減).例如,規則1中顯示在uikit項目中,如果inner提出一個問題,被inner回答的概率增加17%.規則證明,從整體上看在所有被調查的項目中inner回答inner的可能性更高.但是這并不意味著所有inner都傾向于回答inner提出的問題,規則1顯示uikit項目中inner回答的問題只有2.13%是inner提出的.類似的信息可以從其余規則中推斷出來.

同時,我們挖掘了當問題提問者是inner時被outer回答的關聯規則.整體上inner提出的問題對outer有負影響,即inner提問會降低outer回答的概率.

我們同樣挖掘了當問題提問者是outer時被inner回答的關聯規則.整體上outer提出的問題對inner有負影響,但這種負影響非常小,幾乎可以忽略不計.

表4code=true→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 4 Association rules of typecode=true→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1elixirianrumford0.130.221001.792elixirc0b0.120.21951.73elixirlau0.310.5694.341.684realm-cocoamarlowcharite0.140.221001.635realm-cocoaArEnSc0.250.411001.636realm-cocoaadomanico0.10.161001.637istioyutongz0.310.598.591.618istiolichuqiang0.20.3297.831.599istioloewenstein0.180.391.111.4810jasmineUziTech0.260.381001.4811jasmineljwall0.190.281001.4812jasminejoezimjs0.280.421001.4813metabasepratapsingh0.10.121001.1814metabaseMixMe0.10.121001.1815metabaseHelenMertes0.10.121001.18

表5issue_category→user類型的關聯規則

Table 5 Association rules of typeissue_category→user

#Antecedent(X)Consequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1preventiveSimonVT0.14.7440.4818.552perfectiveredaxmedia0.6420.4752.2416.763preventiveezequiel0.14.7433.3315.284preventivemadrobby0.136.1326.5112.155perfectivemadrobby0.165.2632.5310.446perfectivemislav0.154.8729.419.437correctiveDhilan0070.10.171001.768correctivedumganhar0.180.3293.751.659correctiveandyque0.150.2692.311.6310adaptivejdragojevic0.180.4648.331.2711adaptivebtford0.671.7746.251.2212adaptiveStevenPuttemans0.290.7546.081.21

表6 10大流行項目repoter_type=inner→user_type=inner類型的關聯規則

Table 6 Association rules of typerepoter_type=inner→user_type=innerin top 10 popular projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1uikitinner1.7696.942.131.172swagger-uiinner26.2295.2730.311.13pandocinner31.3796.0634.861.074react-navigationinner17.1897.2218.711.065seleniuminner45.4994.5349.631.036istioinner79.0396.4983.331.027realm-cocoainner61.8594.6466.641.028elixirinner79.1995.9583.691.019metabaseinner56.7998.3358.271.0110servoinner83.3299.1184.31.00

表7顯示當問題提問者是outer時被outer回答的關聯規則.可以看出整體上outer提出的問題會促進outer回答的概率,且大部分outer傾向于回答outer提出的問題,如規則4中項目realm-cocoa中的outer回答的問題中有51.31%是outer提出的問題.

為了更直觀地看出提問者的角色對回答者角色的影響,我們將上述表格轉化為圖的形式,如圖6所示.從上述表格可以看出,大部分規則在方向(Y→X)上的置信度顯著高于在方向(X→Y)上的置信度,所以我們從個體出發研究了問題提出者與回答者之間的關聯規則.

表7 10大流行項目repoter_type=outer→user_type=outer類型的關聯規則

Table 7 Association rules of typerepoter_type=outer→user_type=outerin top 10 popular projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1istioouter2.2812.6244.252.452servoouter0.412.5935.482.233elixirouter2.0411.6937.942.174realm-cocoaouter3.6910.6551.311.485metabaseouter1.573.7161.981.476pandocouter8.2112.8285.081.337seleniumouter5.7111.0168.451.328swagger-uiouter12.1716.890.351.259react-navigationouter7.659.393.971.1410uikitouter17.4417.7699.681.02

圖6 repoter_type→user_type類型的Lift

表8顯示了從jasmine、istio、realm-cocoa、elixir以及metabase中抽取的repoter_type=Member→user類型的關聯規則(升序遞減).例如,規則1表示當提出問題的人是Member時,讓”sabino”回答該問題的概率增加621%.規則證明,在所有被調查的項目中,某些開發人員回答Member提出的問題的可能性更高.但這并不意味著在所有的開發人員中,只有他們評論Member提出的問題,只是這些實例的機會更高.當我們分析每個規則(Y→X)的置信度時,發現除了規則8、9、10意外,其他規則明顯大于(X→Y)上的置信度.例如,規則5意味著” sandeshsoni”回答的問題94.44%是Member提出的問題.類似的知識可以從其余規則的分析中推斷出來.

盡管一些規則的支持度較低,但是考慮到開發人員回答的問題的絕對數量,所揭示的行為非常重要.例如,表8中的規則2只提供了0.11%的支持度,這表示” gbaufake”回答了5個由Member提出的問題,但是開發人員” gbaufake”總共回答的問題只有6個,所以(Y→X)的置信度為80.77%,這表明他/她傾向于回答由Member提出的問題.盡管該規則并不代表所有開發人員的模式,但它顯示了一些特定開發人員的模式.如果在推薦系統中想要為Github上的issue推薦相應的開發人員,那么應該充分利用這種模式.

表8repoter_type=Member→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 8 Association rules of typerepoter_type=Member→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1metabasesabino0.112.4733.337.212istiogbaufake0.110.5180.773.643istiorosenhouse0.110.5180.773.644istiotheganyo0.261.1974.243.345elixirsandeshsoni0.110.3594.443.016elixirrafaelfranca0.160.5186.212.747elixirlackac0.120.3785.712.738metabasecamsaul1.6736.0811.952.599metabasesenior0.36.610.062.1810jasmineslackersoft0.3746.881.41.76

當我們分析以repoter_type=Member為前提的規則時,我們還驗證了其他身份的提問者與回答者之間是否存在關聯.表9和表10說明了這種模式.可以看出,當問題提問者是Contributor或者其他非貢獻者時,被某些開發人員回答問題的機會大大增加,而且很多開發人員傾向于回答這類人提出的問題.例如在表9中所研究的開發人員幾乎回答的全部問題都是非貢獻者提出的問題.

表9repoter_type=Contributor→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 9 Association rules of typerepoter_type=Contributor→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1jasminedeckar010.12210016.122jasminekevinoid0.12210016.123jasmineUziTech0.25490.9114.654realm-cocoadismory0.131.1185.197.155realm-cocoaSandyChapman0.10.8781.826.876realm-cocoaJadenGeller0.544.5759.014.957metabaseVikramTiwari0.844.2273.333.698metabasejoebordes0.261.2967.53.49metabaseVarunram0.281.3967.443.3910elixirianrumford0.120.36952.7911elixirKronicDeth0.10.394.122.7712elixirPragTob0.110.3294.442.7713istiojnativio0.220.4695.35214istiojmuk0.440.9193.11.9515istiorobertpanzer0.140.2992.861.95

表10repoter_type=others→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 10 Association rules of typerepoter_type=others→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1istiovinayvenkat0.110.381003.332istiojanevalleye2e0.150.51003.333istiojohnzheng19750.170.5794.123.134elixirmguimas0.270.781002.95elixirericbmerritt0.210.61002.96elixirmartin-langhoff0.160.471002.97metabaseLeen150.10.131001.328metabasegajus0.10.141001.329metabasezaiddabaeen0.180.241001.3210realm-cocoagithub2016a0.140.161001.1411realm-cocoaAndrewBarba0.140.161001.1412realm-cocoastaticdreams0.110.131001.1413jasminejoelmccracken0.120.131001.0814jasminemgol0.10.111001.0815jasminefloverdevel0.10.111001.08

表11acquaintance=true→user類型在項目jasmine、istio、realm-cocoa、elixir和metabase的關聯規則

Table 11 Association rules of typeacquaintance=true→userin jasmine,istio,realm-cocoa,elixir and metabase projects

#ProjectConsequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1istioStono0.365.4383.9612.582istioprune9980.131.9375.411.33elixirslashmili3.51251007.124elixircdegroot1.7512.51007.125metabasepratapsingh0.120.611005.126istiogyliu5130.233.430.644.597realm-cocoaArEnSc0.190.821004.348realm-cocoamhergon0.120.511004.349metabasethat0n3guy0.120.6184.384.3210metabaseanki-code0.63.0683.334.2711realm-cocoagithub2016a0.10.44964.1612elixirriverrun5.2637.533.332.38

我們的結果表明,提問者的身份不同會對開發人員回答問題有影響.一些開發人員傾向于回答對項目有貢獻的人提出的問題,而其他人傾向于回答非貢獻者提出的問題.在問答者推薦系統中,我們可以根據問題提問者的角色推薦相應的開發人員去回答該問題.

4.2.2 問題提出者與回答者之間的關系是否影響回答者的積極性？

在本節中,我們將討論開發人員之間的顯式關系,更具體地說,是提問者和回答者之間的關系.Github提供了社交網絡資源,允許開發人員之間有彼此的社交關系,我們認為社會關系反映了提問者和回答者之間的顯式關系,因此我們研究這些因素對回答者的影響.

表12repoter→user類型的關聯規則

Table 12 Association rules of typerepoter→user

#ProjectAntecedent(X)Consequent(Y)Sup X->Y(%)Conf X->Y(%)Conf Y->X(%)Lift1jasmineragaskardwt3.392.0266.6719.692elixiralcoknewter3.032.9858.3319.223istioldemaillymattdelco3.874.7161.1115.784istiorshriramprune9983.472.3941.6712.025realm-cocoatgoyneanlaital5.32.8762.511.796jasmineinfewswyuenho8.931.1510011.27realm-cocoabdashliuxuan306.351.7664.7110.28metabasetlrobinsontomkanjam7.041.1862.58.889elixirericmjtony6126.040.85508.2710istiostalejohn-a-joyce9.531.0466.67711realm-cocoajpsimpeterpaulis15.410.721006.4912metabasecamsaulLukeAbell11.81.0671.436.0513metabasesalsakranhugocar11.090.8357.895.2214jasmineslackersoftmyitcv22.570.451004.4315elixirjosevalimKabie33.540.311002.98

我們從acquaintance=true→user中提取規則,即當回答者與提問者是熟人時,回答者回答該問題的機會大大增加.表11顯示了istio、realm-cocoa、elixir和metabase項目的規則及其度量.結果表明,這種模式不僅存在,還非常顯著.此表僅說明每個項目排名前三的最重要規則,例如規則1顯示,在項目istio中,當” Stono”與提問者是熟人時,他回答該熟人提出的問題的機會增加了11.58倍(Lift=12.58).規則2到12表示相同的模式,但Lift相對較小.

可以得出結論,當由熟人提交問題時,被一些開發人員回答的機會會增加(最多11.58倍).對于給定提問者,部分開發人員可能會與其存在利益沖突,挖掘這個規則可以幫助我們替換提問者和回答者的配對來緩解這種沖突.

4.2.3 回答者之間是否經常以配對的形式出現去回答問題？

開發人員之間的關系可能由于在項目中沒有明確建立而被隱藏,例如技術能力或共有興趣等,我們認為這些關系是隱式的,但對分析提問者對回答者的影響同樣重要.

如上所述,有些關系可能是隱式的,為了得到這樣的關系,我們尋找由一個給定開發人員回答的問題,這些問題被其他開發人員回答的幾率,即某些開發人員是否經常一起回答同一個問題.我們從項目jasmine、istio、realm-cocoa、elixir和metabase中挖掘了repoter→user類型的規則.表12顯示了挖掘的規則及其興趣度量,其中repoter是先導,user是后繼.結果表明,回答者經常以配對的形式出現在問題討論中.

我們的分析表明,開發人員經常成對出現在問題討論中,這對問答者推薦具有重要指導意義.如果已知某問題的部分回答者,可以根據其配對情況推薦其他開發人員回答問題.

5 總結與展望

在本文中我們進行了一個關于影響開發人員回答問題因素的研究,以便加速開源項目的開發進程.我們的結果可能為日后推薦相關開發人員回答問題提供依據,這些結果有助于解釋不同的開發人員對問題積極性為什么不同.

根據我們的研究結果,可以得出以下七個結論.首先,提出問題的人是否對項目有過貢獻會影響開發人員回答的積極性.例如,一些開發人員偏好Contributor提出的問題,置信度從52%到100%不等.其次,提問者和回答者之間的社會關系可能會影響開發人員的回答,一些開發人員經常(多達11.58倍)評論熟人提出的問題.第三,問題的難易程度對開發人員會產生影響,根據問題的難易程度,當問題比較簡單時特定的開發人員去回答該問題的可能性最多可增加4倍.第四,問題的純文本長度是影響開發人員回答問題的重要因素之一,我們發現某些開發人員傾向于回答長度較短的問題(置信度最高達100%).第五,問題中是否含有代碼是衡量開發人員技術偏好的因素之一,含有代碼的問題被部分開發人員回答的概率最多可增加79%.第六,問題的維護類型對開發人員積極性同樣有影響,當開發人員看到自己偏好的維護類型的問題時,他評論此類問題的可能性會大大增加.第七,我們發現回答者之間經常一起評論問題,即開發人員以配對的形式出現在問題的討論中,我們可以根據當前已回答該問題的開發人員尋找其配對人員,從而完成推薦.

此外,我們指出,除了確定與開發人員回答問題相關的影響因素外,采用的方法還允許我們量化這種影響程度.我們的研究還考慮了定性因素,例如整個項目歷史中提交的問題數量和開發人員的技術領域,用于描述觀察到的模式.

在未來的研究中,我們打算根據研究的影響因素對問題進行回答者推薦,此外我們打算分析特征組合是否會增加問題回答者的回答幾率,并將其用到推薦系統中.