英语原文共 14 页，剩余内容已隐藏，支付完成后下载完整资料
探索软件开发人员如何在GitHub中使用提及机器人
摘要
最近，主要的软件开发平台已经开始提供自动审阅人推荐(ARR)服务，为了拉取代码请求以改进协同编码审阅过程。然而，ARR的贡献者体验还有待研究。在本文中，我们使用两阶段混合方法来研究软件开发人员如何看待和使用Facebook提及机器人，它是GitHub中最流行的ARR机器人之一。具体来说，在第一阶段，我们对使用提及机器人的项目进行了档案分析，并对贡献者进行了调查，以调查该机器人的性能。一年后，在第二阶段，我们重新访问这些项目，并对三个用户组(项目拥有者、贡献者和审阅者)进行额外的调查和访谈。结果表明，开发人员很喜欢提及机器人，但它的不稳定设置和不平衡的工作负载分配使开发人员感到困扰。最后，我们总结了改进ARR服务的设计考虑。
关键词：自动审阅人推荐服务，混合方法，贡献者体验，软件开发平台
1.简介
越来越多的开发人员在诸如GitHub这样的在线平台上进行协同软件开发。当项目的贡献者将他们对代码的更改推入项目存储仓库之时，拉取代码请求（PRs）会被记录，并且在新代码合并到代码库之前，必须对这些拉请求进行审阅和批准(图1)。为了保持项目开发的流程，及时的、合格的公关审阅是迫切需要的(Yu等人,2016年)。根据2014年的一项调查，15%的贡献者抱怨他们的拉请求很难得到及时的回馈(Gousios等人,2016年)。将拉请求分配给适当的审阅人一直是一个挑战(Balachandran,2013年)。一方面，尽管贡献者可以在他们的PRs中要求审阅人，他们中的许多人，特别是那些初接触项目的人，很少知道谁有资格并且愿意审阅他们的代码(Xia等人，2015)。另一方面，审阅人处理大量PRs的时间和能力有限(Gousios等人，2015;Pham等人，2013)。为了提高协作代码审阅过程的效率，一些开发人员将提供自动审阅推荐(ARR)服务的机器人引入到他们的项目中。例如，Balachandran(2013)实现了“ReviewBot”，它通过代码更改历史来筛选潜在的审阅人，然后通过代码审阅历史来选择最合适的审阅人。最近，各大软件开发平台开始为贡献者提供他们自己的ARR服务。例如，GitHub中的开发人员对项目的存储库具有写访问权，他们可以根据git的blame数据 (即，修改文件的每一行)(Github 2017b) 来要求审阅人。
现有对ARR服务的研究主要集中在推荐准确性方面的性能(Jiang等人，2015年;Yu等人，2016年;Zanjani 等人，2016年;Fejzer 等人，2018年)。然而，在此过程中涉及的不同利益相关者之间的贡献者体验与交互还有待研究(图1)。特别是，很少有人研究(1)开发人员在实践中如何看待和使用ARR，以及(2)对于设计ARR服务的不同类型贡献者来说，最关键的需求是什么。为了填补这一空白，在2015年10月至2018年4月期间，我们对一个在GitHub上活跃的ARR机器人Facebook提及机器人进行了案例研究，作为一个镜头来洞察在协作软件开发平台中更好的ARR服务设计。
在本文中，我们使用两阶段混合方法来解决上述两个问题。在第一阶段(2015.11-2016.06)，我们对当时使用Facebook机器人的155个GitHub项目进行了档案分析。更具体地说，对于每个项目，我们比较了使用和不使用提及机器人建议的审阅人员的拉请求的响应速度和响应时间，以评估在实践中该ARR bot的有效性和效率。我们进一步分析了这些项目中与提及机器人相关的评论，并对52名提及机器人贡献者进行了调查，以了解贡献者需求。在第二阶段(2016.07至2017.08)，我们重新审视这些项目，分析年内出现的新贡献者评论，看看在第一阶段确定的贡献者需求是否得到满足。为了更深入地了解为什么开发人员使用/不使用提及机器人，以及他们希望从ARR服务中得到什么，我们将ARR贡献者分为三组:项目拥有者、贡献者和审阅人。然后我们对36个有效回复进行了额外的调查，并采访了GitHub上的6名开发人员，以了解每个小组的需求。两阶段的调查结果显示，虽然开发人员很欣赏提及机器人，节省了力气，但不同的贡献者群体对ARR服务有不同的需求。项目拥有者需要的简单性和稳定性，贡献者需要的透明性，以及审阅者需要的选择性。我们将研究结果总结为未来ARR服务设计的考虑因素。
图1：基于GitHub分支的工作流(GitHub 2013)
2.背景和相关工作
在本节中，我们首先介绍了在GitHub中拉取代码请求(PR)和审阅流程的概念，然后总结了一些现有的ARR服务的机制。
2.1 GitHub的拉请求和审阅流程
基于Pull的开发是分布式软件开发的最新模型(Gousios等人，2014年)。为了接收外部贡献，存储库由fork共享(即克隆)，并由PRs修改。通常有三种类型的开发人员参与拉请求过程:
bull;在项目中拥有PRs的项目拥有者。
bull;提交需要审阅的PRs的贡献者。
bull;帮助审阅拉取代码请求的审阅人。
拉请求过程如图1所示。贡献者创建一个主分支，并将更改提交给他们的本地分支(Gousios等人，2014年，2016 b, 2015)。为了对主分支做出贡献，贡献者通过创建拉取代码请求来提交一组变更。所有者检查拉取代码请求，项目拥有者决定是否合并变更。在此过程中，项目拥有者、审阅人和贡献者通常需要讨论提议的更改。最后，拉取代码请求结束了。
在拉请求打开后，任何具有读权限的人都可以审阅并评论它提出的更改。GitHub允许开发人员对拉请求中提出的更改进行评论、批准更改或在合并拉请求之前请求进一步的更改。
当提交拉请求时，它们将在短时间内被审查。然而，在现实中，项目拥有者在受欢迎的项目收到太多的拉取代码请求。他们很难自己审查这些PRs或为他们确定其他合适的审阅人(Balachandran 2013;Gousios 等人，2015;jiang等人，2015;Thongtanunam 等人，2015;Tsay等人，2014;Xia等人，2015;Yu等人，2015;Yu等人，2016;Zanjani 等人，2016)。
2.2拉请求的自动审阅推荐
为了减少项目拥有者的努力，一些研究人员提出了自动审阅人推荐(ARR)服务(Balachandran 2013;jiang等人，2015;Thongtanunam 等人，2015;Xia等人，2015;Yu等人，2016;Zanjani 等人，2016)。由于任何审查的关键是文本和变化的理解(Bacchelli和Bird 2013)，这些ARR服务打算引入符合PRs条件并愿意提供帮助的审阅人。他们通常使用代码变更和审阅的历史信息来识别合适的审阅人员(Balachandran 2013;jiang等人，2015;Thongtanunam 等人，2015;Xia等人，2015;Yu等人，2016;Zanjani 等人，2016)。Balachandran提出的“ReviewBot”通过责任信息将潜在的审阅人列出，然后选择修改相关代码最多的最合适的审阅人(Balachandran 2013)。Thongtanunam 等人(2015)提出了“RevFinder”，它不仅基于代码审阅历史，还基于文件路径的相似性来推荐审阅人。然后，提出了“Tie”，通过对拉请求中的文件路径和文本信息使用不同的相似性度量来增强“RevFinder”(Xia等人，2015)。jiang等人(2015)开发了“CoreDevRec”，利用一个支持的向量机来训练预测模型。这个模型使用了三个特性，即文件路径、评论者和贡献者之间的社会交互和评论者的活动性。开发人员的配置文件也用于审查推荐。例如，Rahman等人(2016)对除了跨项目经验，还建议使用开发人员在与PR相关的特定专业技术方面的经验来确定作为潜在代码审阅人的专业知识。在数据集上的实验表明，该方法可以达到85%以上的推荐精度。Fejzer 等人(2018)采用了程序员个人资料和待审核的变更建议之间的相似性函数来给出建议，并在分类指标和性能方面得到了改进。在Badampudi等人的文章中可以找到不同PR审阅人推荐技术的综述。(2019)。
虽然以上的ARR服务是软件开发平台之外的工具，但GitHub已经提供了自己的ARR服务。“代码所有者文件”(Github 2017a)用于定义负责存储库中代码的个人或团队。如果有人修改了他们所拥有的代码，这些开发人员将被自动请求进行审查。“建议审阅人”功能(Github 2017b)可以根据git的blame数据自动推荐审阅人。每次提交PR时，组织成员、存储库所有者和协作者可以在PR的右边栏中看到建议的审阅人，他们可以决定是否向这些审阅人请求审阅。
然而，很少有工作涉及软件开发人员如何在实践中理解和使用这些ARR服务。许多因素会影响这些服务的效率，正如在音乐、数码相机等领域探索推荐服务的用户体验的著作所建议的那样(Chen等人，2013;Ferwerda 等人，2015;Lee等人，2015;Sinha和Swearingen 2002; Stolze和Nart 2004)。例如，Sinha和Swearingen(2002)研究了透明度在音乐推荐系统中的作用。Stolze和Nart(2004)发现，与特征导向推荐相比，数码相机的需求导向推荐更有帮助。chen等人(2013)研究了个性对用户推荐多样性需求的影响。Ferwerda 等人(2015)测试了用户个性对其音乐选择方式的影响。然而，在上述场景中研究用户体验的方法只涉及到一个特定方面或不超过两个用户组。对于在线软件开发平台来说，ARR服务领域的用户体验研究仍然是一个挑战，可能涉及到项目所有者、贡献者和审阅者三种用户群体。
2.3 Facebook 提及机器人
Facebook的“提及机器人”可以使用两种试探法来推荐任何开发者成为审查者:(1)如果某一行被删除或修改，最后接触这一行的人可能会关心这个拉请求。(2)如果一个人最后修改了文件中的许多行，他可能希望得到提示(Facebook 2015)。
自其2015年10月推出以来，截至2016年6月，提及机器人已经为205个GitHub项目提供了服务，处理了12060个拉请求。GitHub项目的所有者可以使用webhook服务(webhook 2017)部署提及机器人，而无需任何额外设置。一旦在项目中使用了提及机器人，就会向新发出的拉请求添加建议注释，如图2所示。默认情况下，创建PR后，提及机器人会直接提到推荐的审阅人，但是项目所有者可以手动个性化bot，通过添加一个“.提及机器人”文件到存储库的基本目录(Facebook 2015)。例如，他们可以配置一些推荐和通知规则，例如推荐的最大候选数量、来自提及机器人的消息和某些审阅者的黑名单。
图2：提及机器人评论的一个例子(Facebook 2015)
3.研究方法概述
在本节中，我们将首先介绍facebook 提及机器人，然后介绍我们的两阶段混合方法方法。
3.1 Facebook 提及机器人
在这项工作中，我们使用facebook开发的提及机器人作为一个镜头，来研究开发人员如何在实践中使用它，以及不同的涉众的关键需求是什么。Facebook的“metion bot”可以使用两种试探法来推荐任何开发者成为审查者:(1)如果某一行被删除或修改，最后接触这一行的人可能会关心这个拉请求。(2)如果一个人最后修改了文件中的许多行，他可能希望得到通知(Facebook 2015)。
自其2015年10月推出以来，截至2016年6月，提及机器人已经为205个GitHub项目提供了服务，处理了12060个拉请求。GitHub项目的所有者可以使用webhook服务(webhook 2017)部署提及机器人，而无需任何额外设置。一旦在项目中使用了提及机器人，就会向新发出的拉请求添加建议注释，如图2所示。默认情况下，创建PR后，提及机器人会直接提到推荐的审阅人，但是项目所有者可以手动个性化bot，通过添加一个“.提及机器人”文件到存储库的基本目录(Facebook 2015)。例如，他们可以配置一些推荐和通知规则，例如推荐的最大候选数量、来自提及机器人的消息和某些审阅者的黑名单。
3.2 两阶段混合方法
为了更好地了解软件开发人员是如何看待和使用Facebook的提及机器人加班的，我们通过档案数据、调查和访谈两个阶段来进行我们的研究。在第一阶段，我们分析了205个使用提及机器人的项目，调查了53个关于提到机器人的问题评论，并对52个提到机器人用户进行了调查。在这一阶段，我们重点关注的是在一定时期(2015年11月至2016年6月)提及机器人在实践中的表现。通过分析这些项目中的拉请求，我们度量了推荐审阅人的响应速度和响应时间。我们使用问题评论来调查用户对提及机器人的需求，而调查是用来了解用户如何看待它的有用性。在第一阶段结束时，我们总结了三个潜在的特性来改进提及机器人和满足用户需求。在第二阶段，我们重新审视这些项目，并分析年内出现的另外90条相关评论，以确定在第一阶段确定的用户需求是否得到了满足。此外，为了更深入地了解人们为什么使用/不使用提及机器人，以及他们对ARR服务的期望，我们进行了一项调查，从三个用户组(即、项目所有者、贡献者和审阅人，然后采访6名开发人员。然后，我们探讨了对每个用户组的ARR服务的用户体验至关重要的因素。注意到以上研究方法可能相互冲突或相互支持，我们将两个阶段的研究结果进行整合，讨论如何在自动审阅人推荐服务中提供更好的用户体验。
4.第一阶段
4.1研究设定
4.1.1数据收集
在第一阶段，我们跟踪Facebook 提及机器人一直到2016年6月的公共活动，并在GitHub上找出205个使用该机器人的项目。我们使用GitHub API (GitHub 2016)来
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[236009]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
