MariaDB 基金会董事会主席 Eric Herman 最近提出请求，希望在我生成并发表博客的季度贡献者指标中加入拉取请求的首次有意义响应时间。我认为这是一个非常好的主意。但这样做存在一些问题，首先就是对“有意义响应”的定义。
有意义的响应
“有意义的响应”可能是一种能够增加价值并表明拉取请求正在被评审的响应。最准确的方法是使用一套定义哪些类型的响应有意义的标准手动记录。这会很快变成一个复杂的手动过程，我们没有这方面的资源。我们需要一种更自动化的方法。
我建议，至少作为该功能的初步版本，我们记录从首次拉取请求开启到 MariaDB 团队中某位成员（但非拉取请求作者）在 GitHub 上首次评论之间的时间。虽然这不能保证一定是有意义的响应，但可能性很高。
实际开发
我们决定将执行此操作的代码添加到我们常规的拉取请求指标代码中，因为它已经与 GitHub 对接以获取每周报告。
在拉取请求指标代码中开发对此功能的支持时，遇到了一些问题：
- 代码评审评论在 GitHub API 中不计为评论。
- 并非所有拉取请求在关闭或合并前都有评论。
- 草稿拉取请求很可能没有有意义的评论。
- Otto（MariaDB 基金会前首席执行官）是 MariaDB 团队成员，但他的大多数评论不会归入与 MariaDB plc / MariaDB 基金会评审相同的类别。
- 当前避免达到 GitHub 速率限制的方法导致处理速度非常慢。
这些问题逐一通过各种方式解决。首先，拉取请求评审实际上使用了与评论完全不同的 API 调用。当 GitHub 的 UI 渲染拉取请求的时间线时，它似乎将这两个调用合并了。这很容易解决，只需添加额外的 API 调用，然后代码会判断有意义的响应是先来自评论还是评审。
对于在关闭或合并前没有评论的拉取请求，我增加了两个计数器。第一个计数器统计原始作者在没有任何评论之前关闭的拉取请求。实际上，这通常发生在用户错误地创建了拉取请求时，例如提交到了错误的版本，或者他们发现代码不再需要，需要以不同的方式实现。
还增加了一个额外的计数器，统计由作者（MariaDB 团队成员）合并但没有其他成员评论或评审的拉取请求。现在，这可能有几个原因，例如它是某个紧急问题的修复，或者评审发生在 GitHub 之外。无论如何，我们确实应该区别处理这些情况。因此，它们是一个指标，表明我们在流程方面可以改进的地方。
接下来是草稿拉取请求。这些通常是为了向他人展示正在进行的工作，或是在 CI 系统上运行正在进行的工作以确保一切都能正确通过。草稿现在包含在指标计数中，但在有意义响应指标中不计数。
正如列表中提到的，Otto Kekäläinen，MariaDB 基金会前首席执行官，是 GitHub 上的 MariaDB 团队成员。他仍然代表 Amazon 为 MariaDB Server 做了很多有用的工作。对于我们设定的标准，他可能不应被包含在内。为此，我们添加了一个排除用户列表。
GitHub 的速率限制有点奇怪。搜索在 60 秒内被限制为 30 次。其他 API 调用有更大的限制。为了避免达到限制，我们之前在每次调用之间暂停 2 秒。在这些更改之前，这没问题，因为我们每周只进行几次搜索。现在我们要深入处理大多数拉取请求，这增加了许多不必要的延迟。为了解决这个问题，我们监控剩余的速率限制，当检测到较低时，系统会暂停 30 秒。这通常在 6 个月内只会导致一两次 30 秒的暂停。
新指标
脚本的新部分是这样工作的：
首先，获取所有 MariaDB 团队成员列表并过滤掉 Otto。这样做的不利之处在于，任何已离开 MariaDB 的人将不再列为团队成员，这可能会影响指标的准确性。此外，之前评论过拉取请求的人可能会被 MariaDB plc 或基金会雇用。这也会影响统计数据。但目前来说这已经足够好了。
接下来进行标准的拉取请求搜索，并额外搜索以统计草稿拉取请求的数量。所有这些搜索都按周分组。
现在真正的新功能来了。系统会生成该周所有未关闭、非草稿状态的拉取请求列表。对每个拉取请求进行评论和评审搜索。然后做出如下判断：
- 如果该拉取请求有非作者的 MariaDB 团队成员的评论或评审，则计算从拉取请求开启到该评论/评审之间的天数，将其加到该周的总天数中，并增加有意义响应计数器（用于计算平均值）。
- 如果该拉取请求由同一用户开启和关闭，并且没有 MariaDB 团队成员的评论或评审，则增加“自行关闭”计数器。
- 如果该拉取请求由同一用户开启和合并，并且没有其他 MariaDB 团队成员的评论或评审，则增加“自行合并”计数器。
- 如果不符合上述任何条件，则增加“无有意义响应”计数器。
代码还增加了新的 --verbose 模式，您可以在其中查看对每个独立拉取请求做出的判断。
示例输出
话虽如此，这里展示的是几周数据的示例输出，原始数据为 CSV 格式，我在此将其转换为表格以便于查看。
| 周结束日期 | 2023-06-18 | 2023-06-25 | 2023-07-02 | 2023-07-09 |
| 新增拉取请求 | 7 | 4 | 5 | 6 |
| 草稿拉取请求 | 1 | 0 | 0 | 0 |
| 已关闭拉取请求 | 3 | 0 | 4 | 1 |
| 已合并拉取请求 | 0 | 4 | 0 | 5 |
| 拉取请求总数 | 2661 | 2665 | 2670 | 2676 |
| 仍开放的拉取请求 | 155 | 155 | 156 | 156 |
| 首次响应天数 | 1.5 | 10 | 0.3 | 1 |
| 获得响应的新增拉取请求 | 4 | 3 | 3 | 3 |
| 未获得响应的新增拉取请求 | 2 | 1 | 1 | 3 |
| 自行合并且无评审的拉取请求 | 0 | 0 | 1 | 0 |
| 自行关闭且无评审的拉取请求 | 0 | 0 | 0 | 0 |
对行名称进行解释如下：
- 新增拉取请求：该周开启的拉取请求数量。
- 草稿拉取请求：该周新开启的拉取请求中，有多少目前是草稿状态。
- 已关闭拉取请求：该周关闭的拉取请求数量（未合并的）。
- 已合并拉取请求：该周合并的拉取请求数量。
- 拉取请求总数：截至该周结束，我们共有的拉取请求总数。
- 仍开放的拉取请求：截至该周结束，仍开放（包括草稿）的拉取请求总数。
- 首次响应天数：该周开启并已获得响应的拉取请求的首次有意义响应的平均天数。
- 获得响应的新增拉取请求：该周开启并已获得有意义响应的拉取请求总数。
- 自行合并且无评审的拉取请求：该周开启的、由作者自行合并且无 MariaDB 团队其他成员评审的拉取请求数量。
- 自行关闭且无评审的拉取请求：该周开启的、未获得有意义响应并由作者自行关闭的拉取请求数量。
您会注意到，“自行合并且无评审的拉取请求”类别中有一条记录。根据 verbose 模式，这是 PR #2678。现在，这很可能确实在 GitHub 之外经过了某人的评审，但没有任何评论表明这一点。
我们希望收集这些指标能帮助我们了解需要在哪些方面进行改进，例如流程改进。新发布的季度指标报告中将包含一份包含这些数据的完整报告。
未来指标
在与 MariaDB 基金会的 Ian Gilfillan 讨论后，我们决定在拉取请求指标代码中添加报告功能。这些报告将列出最需要关注的拉取请求，希望能帮助我们开始解决一些积压最严重的问题。此功能可在 Jira 上的 MDBF-576 中进行跟踪。
除此之外，我们也乐于听取意见。您希望看到哪些指标？我们能做得更好吗？请告诉我们您的想法。
特色图片：XKCD Data Trap，在 Creative Commons Attribution-NonCommercial 2.5 许可下使用。