背景
许多开源软件 (OSS) 项目将代码审查 (code review) 作为开发过程的重要组成部分。软件机器人通过充当用户和其他工具之间的接口并减少维护者和贡献者的工作量，在代码审查过程中发挥着重要作用。
作者的目标是了解在采用代码审查机器人后 GitHub 项目的 PR (PullRequest) 动态如何变化。
案例研究
由于对采用代码审查机器人在 PullRequest 动态中的影响知之甚少，作者进行了探索性案例研究，制定假设以在我们的主要研究中进一步调查。
案例选择：
- 编程语言 Julia
- web框架 CakePHP
研究指标：
- Merged/non-merged pull requests
- Comments on merged/non-merged pull requests
- Time-to-merge/time-to-close pull requests
- Commits of merged/non-merged pull requests
研究结果：
作者在案例研究中提出了文章后续评估验证的4个假设。
H1.1 引入代码审查机器人后，每月合并拉取请求的数量增加。
H1.2 引入代码审查机器人后，每月非合并拉取请求的数量减少。
H2.1 采用代码审查机器人与合并拉取请求的每月评论数量增加有关。
H2.2 采用代码审查机器人后，非合并拉取请求的每月评论数量增加。
H3.1 引入代码审查机器人后，每月合并拉取请求的时间有所增加。
H3.2 在采用代码审查机器人后，每月拒绝拉取请求的时间有所增加。
H4.1 采用代码审查机器人后，每月提交合并拉取请求的数量有所增加。
H4.2 采用代码审查机器人后，非合并拉取请求的每月提交数量有所增加。
方法论
考虑到案例研究中提出的假设，在我们的主要研究中，我们采用时间序列分析来解释机器人采用的纵向影响。 我们采用了回归不连续性设计 (RDD) 。RDD 是一种用于对干预时和干预后很长时间内的不连续程度进行建模的技术。 该技术基于这样的假设，即如果干预不影响结果，则不会出现不连续性，并且结果将随着时间的推移是连续的。 RDD的统计模型如下。
数据集
GHTorrent 数据集
G. Gousios and D. Spinellis,GHTorrent: GitHub’s data from a firehose.MSR.2012.
评估设计
对上述案例分析中提出的4个假设进行评估分析。
- 采用代码审查机器人后，每月合并的拉取请求更多，每月的非合并拉取请求更少。
- 平均而言，在采用代码审查机器人后，每月关于合并拉取请求的沟通较少。 但是，非合并拉取请求的每月通信不会随着时间的推移而改变。
- 采用代码审查机器人后，维护人员平均需要更少的时间来审查和拒绝拉取请求。 但是，在代码审查机器人采用后，审查和接受拉取请求所需的时间不会改变。
- 采用代码审查机器人后，合并和未合并的拉取请求的拉取请求提交中位数的月度趋势不会改变。
若有收获，就点个赞吧
0 人点赞
