CN108171485B - 一种基于软件关联库的跨项目审查者推荐方法 - Google Patents

Abstract

本发明属于软件协同开发领域，公开了一种基于软件关联库的跨项目审查者推荐方法，该方法包括：首先在Stack Overflow社区分析开发者的群体标记行为，利用软件间的应用场景同现性来构建基于场景同现的软件关联库；然后在GitHub社区中抽取项目间的贡献引用指向关系，利用项目间的技术依赖性来构建基于技术依赖的软件关联库；然后从软件关联库中为给定的项目搜索关联项目，并从关联项目中选取活跃贡献者以及核心开发者作为跨项目的贡献审查者。本发明能够推荐关联项目的利益相关者参与到该项目的贡献决策中，从而让审查者更全面地了解来自各个利益相关方的意见，做出更能兼容各方需求的决定。

Description

一种基于软件关联库的跨项目审查者推荐方法

技术领域

本发明属于软件协同开发领域，尤其涉及一种基于软件关联库的跨项目审查者推荐方法。

背景技术

基于PR(Pull-request，简称PR，中译：合并请求)的开发模式使得外围开发者更方便地参与到开源软件的开发中，大众开发者的贡献门槛被大大减低，任何开发者都可以对其感兴趣的项目提交PR。目前，在GitHub平台上已经产生了一亿多个PR，并且其近些年的数量呈现越来越明显的增长趋势。对于那些吸引了大量贡献者的流行项目来说，每月都要收到大量的PR，如Rails项目平均每个月就要收到来自大众社区的250多个PR。这些大众贡献在促进开源软件项目快速发展的同时，也给这些项目的质量管控和管理带来了巨大的挑战。为保证大众贡献的质量，每一个被提交的PR都要经过严格的审查才能被合并到主版本库中。GitHub平台(GitHub是一个面向开源及私有软件项目的托管平台，因为只支持Git作为唯一的版本库格式进行托管，故名GitHub)把贡献审查任务通过众包的形式开放给社区中的所有开发者，不论是核心开发者还是外围开发者，都可以对一个项目的任何一个PR进行审查并提供反馈意见。很显然，对于一次贡献审查，合适的审查者能够降低PR的审查延迟、提高其汇聚效率。因此，已经有很多的工作对贡献审查者的自动推荐展开了研究，这些方法能够降低项目管理者的工作压力，提高审查效率。

已有的审查者推荐方法主要是对一个项目的审查历史进行分析，从而为一个新的PR推荐合适的审查者。然而，这些方法并没有充分利用项目间的关联关系。事实上，项目间经常存在关联关系，或者是相互依赖，或者是经常处于相同的应用环境。这些相互关联的项目间，一个项目的更改很有可能会对另外一个项目产生影响。因此，在一个项目对PR进行审查的时候，不管是新功能的添加还是对已有Bug的修复，与其相关联项目的利益相关者都应该参与到对这些更改的讨论中，从他们的立场和角度发表审查意见，为一个项目的发展提供最全面的参考信息。如此一来，对项目做出的任何决定都是更加符合实际需求的。因此，本发明通过建立软件关联库为PR推荐跨项目的审查者，从而提高贡献审查的兼容性。

发明内容

为解决上述技术问题，本发明提供了一种基于软件关联库的跨项目审查者推荐方法。Stack Overflow是一个与程序相关的IT技术问答网站。用户可以在网站免费提交问题，浏览问题，索引相关内容，在创建主页的时候使用简单的HTML，在问题页面，不会弹出任何广告，销售信息，JavaScript窗口等。本发明是基于Stack Overflow、GitHub平台进行实现的，具体技术方案如下：

一种基于软件关联库的跨项目审查者推荐方法，包括以下步骤：

S1、分析Stack Overflow社区中开发者的群体标记行为，利用软件间的应用场景同现性构建场景同现软件关联库；

S2、在GitHub社区中抽取项目间的贡献引用指向关系，利用项目间的贡献引用指向关系构建技术依赖软件关联库；

S3、从所述场景同现软件关联库和所述技术依赖软件关联库中搜索给定项目的关联项目集合，并从关联项目集合中选取活跃贡献者和核心开发者作为跨项目的贡献审查者。

优选地，所述步骤S1中构建场景同现软件关联库的具体方法包括：基于显示关联关系方法和基于隐式关联关系方法，

基于显示关联关系方法具体为：利用Stack Overflow中标签的同现性来提取软件间的关联关系，如果一个问题对应的标签是两个软件的名称，则表明这两个软件存在关联关系，进而根据该关联关系构建场景同现软件关联库；

基于隐式关联关系方法具体为：利用Stack Overflow中用户对重复问题的标记，如果两个问题被标记为重复问题，则该两个问题所对应的标签间即具有隐式关联关系，进而根据该隐式关联关系构建场景同现软件关联库；

优选地，所述步骤S2中抽取项目间的贡献引用指向关系的具体方法包括：主动引用关系方法和被动引用关系方法，

主动引用关系方法为：对于一个项目，获取其所有关于贡献引用关系的评论文本，利用正则表达式从评论文本中识别出指向其它项目的链接；

被动引用关系方法为：对于一个项目，依据该项目在其它项目的PR评论中被引用的关系，确定其它项目指向该项目的链接。

优选地，所述步骤S3具体过程为：

S31、给定需要推荐审查者的项目，从所述场景同现软件关联库和所述技术依赖软件关联库中搜索与给定项目发生关联的项目集合；

S32、对于关联项目集合中的每一个项目，根据活跃开发者和核心开发者的定义找出的符合条件开发者，将这些符合条件开发者推荐到给定项目中作为跨项目的审查者；

所述活跃开发者：指在设定的时间段内，提交代码量最多的用户；所述核心开发者；指在设定的时间段内，关闭或合并他人PR的用户。

与现有技术相比，本发明具有以下有益效果：1)本发明针对开源软件项目托管平台中存在的大众贡献审阅，提出了一种跨项目的审查者推荐方法。该方法能够推荐关联项目的利益相关者参与到该项目的贡献决策中，从而让审查者更全面地了解来自各个利益相关方的意见，做出更能兼容各方需求的决定。2)本发明从Stack Overflow社区利用开发者的群体标记行为建立了基于场景同现的软件关联库，该关联库能够较好地揭示软件之间在实际应用场景下的关联性。3)本发明从GitHub社区中利用贡献间的互相引用关系建立了基于技术依赖的软件关联库，该关联库能够较好地揭示软件之间在技术依赖方面存在的关联性。4)本发从其相关软件中定位出核心开发者和活跃贡献者作为给定软件的跨项目审查者，进一步加强了贡献审查的有效性和全面性。

附图说明

图1为本发明方法流程示意图；

图2为本发明实施例中产生的跨项目的贡献审查者推荐结果图。

具体实施方式

下面将结合附图和实施例对本发明技术方案进行清楚、完整地说明。如图1所示，本发明提供了一种基于软件关联库的跨项目审查者推荐方法，该方法包括如下步骤：

S1、构建场景同现软件关联库；

首先利用Stack Overflow标签的同现性来提取软件的关联关系。两个标签的同现性体现在两个标签共同标注了哪些问题。由于一个问题的标签反映了该问题涉及到的软件或者技术问题，因此，如果一个问题的标签恰好是两个软件的名称，那说明了这两个软件在现实的使用中存在着关联关系，这种关联关系体现了这两个软件共同出现在同一个应用场景中。假设列表<t₁，t₂，t₃，...，t_k＞是某个问题的k个标签，这个列表中的每两个标签都算是同现了一次，当把Stack Overflow所有问题遍历完后，就可以统计出两个标签的同现次数。最终，每一对标签和它们的同现性以三元组<t₁，t₂，value＞的形式被存储起来，在这个三元组中，t₁和t₂代表的是两个标签,value是这两个标签间的关联值。给定两个标签，他们之间关联值的计算方式为：

在上述的式子中，Rv_co(t₁，t₂)是标签t₁和标签t₂的关联值，该关联值主要由两个标签的同现次数来确定。函数count_pst(t)返回的是由标签t所标注的所有问题数量，函数co-occure(t₁，t₂)返回的是被标签t₁和t₂共同标记的问题的数量。因此，在上面的式子中，分子是两个标签同现次数的平方，分母是两个标签标记的问题数的乘积。如果两个标签总是标记相同的问题，那么它们的关联值等于1，如果他们从来没有标记过相同的问题，那么它们的关联值等于0。

虽然Stack Overflow社区鼓励用户在遇到问题的时候先对已有的资源进行充分的搜索(“search and research”)，如果搜索不到所需要的信息再创建新的问题，然而用户总是会因为各种原因创建重复的问题。Stack Overflow允许拥有相应权限的用户对重复的问题进行标记，并会显示地在其标题的尾部打上“duplicate”标明其重复性，被重复的问题的链接也会被列在该问题的页面中。很明显，被标记为重复的两个帖子实际上是在讨论同样的问题，因此这两个帖子的标签列表反应的关注点重合度也应该很高，这种现象揭示的是标签间的隐式关联关系。给定一对重复帖子：源帖子(记为ps)和目标帖子(记为pt)，它们的标签列表分别是：ts<ts₁，ts₂，...，ts_m>和tp＜tp₁，tp₂，...，tp_n＞，m和n分别表示ps和pt的标签个数。

首先计算两个标签列表ts和tp的合集tm：tm＝ts∩tp，然后用tm得到两个新的集合ts_m＝ts-tm和tp_m＝tp-tm。对于ts_m和tp_m，对其两两元素之间建立关联关系，并对每一对关联关系计数。当所有的重复帖子遍历完之后，每一对建立了关联关系的标签都对应着一个关联次数值。通过这种方式，较好地利用包含在ts_m和tp_m中的信息。实际上，隐式关联关系可以看成是显示关联关系的补充，两个标签间的隐式关联次数可以纳入到他们的关联值的计算中，因此，更新后的关联值计算公式为：

函数count_dpl(t₁，t₂)返回的是标签t₁，t₂被隐式关联关系关联的次数。至此，基于应用场景的软件关联库构造完毕，这个软件关联库中存储的是两个软件领域术语(标签)的关联关系。因为许多软件的名字在Stack Overflow上都是一个标签，因此这个软件关联库可以用来发现关联项目。

在判断Stack Overflow中一个标签和GitHub平台中项目的对应关系时，本发明采取的是搜索与筛选相结合的方式。给定一个标签，首先在GitHub平台依据关键字进行搜索，然后对关键字搜索结果的第一个软件进行分析判断。位于第一个搜索结果表明它和搜索关键字的文本匹配度是最高的，并且其在GitHub上的流行度也是相对较高的。进一步地，对比此项目的名字是否和标签名是完全一样的，如果它们的文本是完全一样的，并且其流行度达到一定的阈值(如：流行度star数>200)，就认为这个项目和标签名是对应一致的，否则就认为该标签在GitHub上没有对应的项目。

S2、构建技术依赖软件关联库；

为提取技术依赖关系，对于一个项目，首先获取其所有issue(问题)或者PR的评论文本，从文本中利用正则表达式来识别指向其它项目issue或者PR的链接。该正则表达式如下所示：

https://github.com/((？:[\w\.-]+/)+)(？:pull|issue)/

从该链接中，提取出项目的名字并对其计数。待项目的所有评论都被处理后，可以获得一组项目以及该项目被链接引用的次数，利用该次数就可以获得项目间的关联度。假设一个项目抽取得到的关联项目有:<S1,S2,S3,…,SN>，那么该项目与其关联项目的关联度计算公式为：

在上式中，函数ref_count(S，S_k)返回的是项目S_k在项目S中被引用的次数，而max_ref是N个相关项目被引用次数的最大值，k的取值范围为1,2,3，…，N。

上述方法为从主动引用关系得到的关联项目。对于一个项目，仅仅从它的PR的评论中不足以定位出所有与它有关联的项目，因为它有可能会在其他项目的PR评论中被引用，在本发明中称这种引用为此项目的被动引用关系。虽然通过遍历GitHub托管的所有项目的评论来抽取对一个项目的被动引用关系是可行的，但是这种方法的时间消耗是非常高的。在GitHub平台上，一个PR的主页面会按照时间顺序展示出GitHub平台上其它PR或者issue对这个PR的引用信息，因此利用这种页面显示信息来抽取被动引用关系。

对于一个项目，首先要获取PR的原始html页面，这个过程由Python提供的urllib2库实现，提供给该库一个PR的url链接就可以下载到它的html源代码。然后，再在下载的页面中利用XPath语法定位到所有这种形式的引用链接，具体用到的定位XPath为：

//*/h4[@class＝”discussion-item-ref-title”]/a

其次，会对这些被识别出的链接进行判断，如果他们是来自其他项目的PR或者issue的引用，那么这些链接就会被判定为被动引用链接。最后，和上一节的处理一样，会对这些链接中包含的项目名进行计数，当这些被动引用关系被扫描处理完毕之后，函数ref_count(S，S_k)会被更新，返回的是项目S_k在项目S中被引用的次数与项目S在项目S_k中被引用的次数之和。

S3、搜索关联项目以及审查者。

首先从软件关联库(场景同现软件关联库和技术依赖软件关联库)中分别搜索给定项目的关联项目集合RS_CO和RS_TD，集合中的每个元素具有这样的形式:＜rs，rv＞，rs指的是关联项目，rv指的是该关联项目与给定项目的关联度。接下来，两个集合进行合并，合并后集合中的每一个元素为：<rs，rv_co+rv_td>，rv_co是项目rs在基于场景同现关联库的集合RS_CO中的关联值，而rv_td是项目rs在基于技术依赖的关联项目集合RS_TD中的关联值。最终，基于这两个软件关联库，得到了一个关联项目列表，该列表中的元素按照关联度值从大到小进行排序。

进一步，从关联项目列表中选取排名前q的项目RS_top-q。对于RS_top-q中的每一个项目，选取目标审查者作为给定项目的跨项目审查者。被选取的目标审查者有两种角色:(1)关联项目的核心开发者(2)关联项目的活跃贡献者。关联项目的核心开发者更关心一个项目的发展规划以及整体设计，因此对由项目更改带来的影响传递更为敏感。而活跃贡献者由于开发在本文中，项目的核心开发者指的是能够关闭或者合并其他人的PR或者issue的用户，而活跃贡献者是代码提交量比较大的用户。为获取这两类开发者列表，采取了在线数据获取方法。虽然利用离线数据来遍历开发者的贡献历史也可以获取这两个开发者列表，但是这种方式需要把GitHub平台上项目的开发数据都下载并存储，这样的资源利用率是极低的。况且，本发明希望得到的是“最近一段时间内”的核心开发者和活跃贡献者，而不是对整个项目周期而言的，因为有些贡献者前期的开发活动非常频繁，而后期却不怎么参与到项目的管理和开发中了，限定一个窗口期来选取“最近一段时间内”的核心开发者和活跃贡献者能保证他们对项目处于比较熟悉的状态。在线获取核心开发者和活跃开发者的方法具体如下:

获取核心开发者：GitHub为每个项目提供了“Pulse”功能用于显示最近一段时间内有哪些PR或者issue被关闭或者合并。以这个列表信息为入口，可以进入到每一个被处理过的PR的主页面。类似于上被动关系的抽取过程，再从这个PR的主页面获取执行合并或者关闭动作的开发者信息。另外，核心开发者的观察窗口大小被设置为一个月，也就是只处理最近一个月有合并或者关闭动态的PR。

获取活跃贡献者：GitHub还为每个项目提供了“Contributos”来展示每一位贡献者的贡献历史，该页面可以显示出开发者一定时期内的代码提交量。分析该页面的源代码后，发现利用GitHub后台提供的数据可以获得一组Json数据，这个Json数据包含每一个开发者以周为最小单位的代码提交量。在解析这个数据后，可以获取每个开发者在给定时间内的代码提交量。另外，给活跃开发者设置的观察窗口为三个月，也就是只统计用户在最近三个月内的代码提交量。

图2以Rails项目为例，图中显示了本发明为其所推荐的跨项目审查者。该页面中的每一个审查者要包括四个数据属性。审查者用户名是该用户在GitHub的用户名，关联项目指的是该审查者是根据哪一个关联项目被推荐的，关联项目类型指的是关联项目和目标项目的关联关系，最后的审查者角色指的是该审查者在关联项目中的角色。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (2)

1.一种基于软件关联库的跨项目审查者推荐方法，其特征在于，包括以下步骤：

S1、分析Stack Overflow社区中开发者的群体标记行为，利用软件间的应用场景同现性构建场景同现软件关联库；所述构建场景同现软件关联库的具体方法采用：基于显示关联关系方法或基于隐式关联关系方法，

所述基于显示关联关系方法具体为：利用Stack Overflow中标签的同现性来提取软件间的关联关系，如果一个问题对应的标签是两个软件的名称，则表明这两个软件存在关联关系，进而根据该关联关系构建场景同现软件关联库；

所述基于隐式关联关系方法具体为：利用Stack Overflow中用户对重复问题的标记，如果两个问题被标记为重复问题，则该两个问题所对应的标签间即具有隐式关联关系，进而根据该隐式关联关系构建场景同现软件关联库；

S2、在GitHub社区中抽取项目间的贡献引用指向关系，利用项目间的贡献引用指向关系构建技术依赖软件关联库；所述抽取项目间的贡献引用指向关系的具体方法采用：主动引用关系方法或被动引用关系方法，

所述主动引用关系方法为：对于一个项目，获取其所有关于贡献引用关系的评论文本，利用正则表达式从评论文本中识别出指向其它项目的链接；

所述被动引用关系方法为：对于一个项目，依据该项目在其它项目的合并请求评论中被引用的关系，确定其它项目指向该项目的链接；

S3、从所述场景同现软件关联库和所述技术依赖软件关联库中搜索给定项目的关联项目集合，并从关联项目集合中选取活跃贡献者和核心开发者作为跨项目的贡献审查者。

2.根据权利要求1所述的一种基于软件关联库的跨项目审查者推荐方法，其特征在于，所述步骤S3具体过程为：

S31、给定需要推荐审查者的项目，从所述场景同现软件关联库和所述技术依赖软件关联库中搜索与给定项目发生关联的项目集合；

S32、对于关联项目集合中的每一个项目，根据活跃开发者和核心开发者的定义找出的符合条件开发者，将这些符合条件开发者推荐到给定项目中作为跨项目的审查者；

所述活跃开发者：指在设定的时间段内，提交代码量最多的用户；所述核心开发者：指在设定的时间段内，关闭或合并它人合并请求的用户。

Images