开源社区问题解决过程人员参与积极性的影响因素分析

刘晔晖,赵海燕,曹 健,陈庆奎

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%.第六,问题的维护类型对开发人员积极性同样有影响,当开发人员看到自己偏好的维护类型的问题时,他评论此类问题的可能性会大大增加.第七,我们发现回答者之间经常一起评论问题,即开发人员以配对的形式出现在问题的讨论中,我们可以根据当前已回答该问题的开发人员寻找其配对人员,从而完成推荐.

此外,我们指出,除了确定与开发人员回答问题相关的影响因素外,采用的方法还允许我们量化这种影响程度.我们的研究还考虑了定性因素,例如整个项目历史中提交的问题数量和开发人员的技术领域,用于描述观察到的模式.

在未来的研究中,我们打算根据研究的影响因素对问题进行回答者推荐,此外我们打算分析特征组合是否会增加问题回答者的回答几率,并将其用到推荐系统中.