Page 49 - 《软件学报》2021年第11期

胡渊喆 等:响应时间约束的代码评审人推荐 3375

配、或评审人没有足够时间 [1,4] ,这延长了评审周期、降低了参与人员的积极性和项目的发展速度.因此,本文提
出响应时间约束的代码评审人推荐问题,即推荐的评审人能否在约定时间内进行评审,目标是为代码评审推荐
合适且响应速度快的评审人,加速评审过程,提升社区活跃性.

1.2 人员响应时间分析
图 1 给出 flutter/fluttert 和 ohmyzsh/ohmyzsh 两个项目的代码评审人的响应时间分布,其他项目的趋势和这
两个项目相同,篇幅限制不再列出.

(a) flutter/flutter (b) ohmyzsh/ohmyzsh
Fig.1 Code reviewer average response time
图 1 代码评审人的平均响应时间

从图 1 可以看出,项目中不同代码评审人的平均响应时间存在很大差异.例如,在 flutter/flutter 项目中,响应
时间为 0.02h~912.7d,有 6.7%的评审人的平均响应时间小于 2h,有 10.9%的评审人的平均响应时间大于 3 个月;
ohmyzsh/ohmyzsh 项目中,83.7%的评审人的平均响应时间大约 1d.
已有研究 [1,4] 指出,快速响应是 pull-based 开发模型中支持贡献的关键组成部分.快速的响应能够很好地鼓
励开源项目贡献者,有效地减少新贡献者加入项目的障碍;相反,代码贡献者往往都会对迟迟无法得到评审人响
应而担忧,甚至影响他们后续对项目的参与和贡献.对于那些响应很慢的评审人,即便他们有经验、有能力,他们
的评审结果对于待评审的代码,也是远水不解近渴,不能及时有效地帮助项目管理者了解代码质量,或者帮助开
发人员改进质量.所以,需要将响应时间纳入评审人推荐问题中,考虑评审人在历史代码评审中的响应时间,以
便推荐出响应速度快的代码评审人.
1.3 人员活跃性分析

我们取 2018 年 1 月~2019 年 1 月的评审数据,按照每半月为一个区间(作为横坐标的 24 个时间区间),统计
该区间上某代码评审人是否有评审活动,有评审活动记为 1,没有评审活动记为 0(作为纵坐标).图 2 给出了
flutter/flutter 和 ohmyzsh/ohmyzsh 两个项目上随机选取的 6 个评审人员的活动情况,其他项目的趋势和这两个
项目相同,篇幅限制不再列出.

(a) flutter/flutter (b) ohmyzsh/ohmyzsh
Fig.2 Review activity distribution of code reviewer
图 2 代码评审人的评审活动分布