这项功能能做什么
交付页面按所选条件汇总团队 PR。合并率和平均耗时描述的是这些 PR 的状态，不能单独说明等待发生在哪个环节。
适用场景
- 调查合并耗时增加的原因。
- 比较评审流程调整前后的数据。
开始步骤
- 1选择团队、日期和仓库。
- 2比较创建的 PR 数与其中已合并的数量。
- 3查看每周活动，再到 Git 平台打开具体 PR，了解等待情况。
使用示例
情况: 合并率为 65%，平均耗时也有所上升。
- 1检查期间内创建的 PR 还有多少处于打开状态。
- 2查看几个 PR 的创建和合并时间，并向团队询问等待原因。
能确认什么: 可以区分未完成和已合并的工作，再核实可能的原因。
常见问题
计算范围是什么？
包括所选期间内创建的 PR，也包括草稿。合并率是其中当前已合并的比例；平均耗时只使用这些已合并 PR。期间前创建的 PR 不计入。
活动小时数等于工作时间吗？
不等于。系统按规范化后的同一作者和同一 UTC 日期分组，将间隔不超过 60 分钟的事件连成区间。区间结束于最后事件后 15 分钟或当天午夜，重叠部分只计一次。每人每天最多 24 小时，团队合计可以超过 24 小时。它不能用作考勤或工时记录。
能和 DORA 的耗时直接比较吗？
这里从 PR 创建算到合并，DORA 从首次提交算到生产部署。两者的起点和统计对象不同。
使用建议
- 比较时保持筛选条件一致，并记录休假、团队调整和发布日期。