你在这里:

变更请求

问题: 在某一时期内对源代码发生了哪些新的变更请求?

概述

变更请求指标跟踪在给定时间范围内提交以供审核的项目源代码修改提案。这些提案会由其他开发人员审核,然后才能将更改纳入项目。该过程涉及反馈循环,提交者可以根据审核者的建议修改其提案。示例包括 GitHub“拉取请求”、GitLab“合并请求”和 Gerrit“代码审核”或在某些情况下的“变更集”。

跟踪一段时间内的变更请求数量可以深入了解项目内的整体编码活动。虽然单凭这一指标无法衡量变更的质量,但它可以很好地表明贡献者参与代码库的频率。

想知道更多?

单击即可阅读有关该指标的更多信息。

数据收集策略

  • GitHub的:
    当变更请求提议对源代码文件进行更改时,它被定义为“拉取请求”。提交日期标志着审核过程的开始。
  • GitLab:
    当变更请求提议对源代码文件进行更改时,它被定义为“合并请求”。提交日期用于定义审核过程的开始时间。
  • Gerrit:
    在 Gerrit 中,变更请求被称为“代码审查”或“变更集”。补丁集的提交标志着审查过程的开始。

筛选

  • 按时间段:观察期的开始和结束日期。
  • 按源代码类型:根据被修改的源代码类型缩小变更请求的范围。
  • 按参与者:包括基于变更请求的提交者、审阅者或合并者的过滤器。需要参与者合并(合并对应于同一作者的 ID)。
  • 按演员组(每个演员的雇主、性别……)。 需要演员分组,并且可能需要演员合并。
  • 按状态:按变更请求的状态进行过滤(例如,打开或关闭)。

可视化

  • 随时间推移每月计数:
    以条形图格式显示每月提交的变更请求的数量。
  • 随时间推移每个组的计数:
    显示指定时期内按群组(例如组织)细分的变更请求。

这些可以表示为条形图,时间在 X 轴上运行。 每个条将代表在特定时期(例如,一个月)内更改代码的更改请求。


案例

  • 没有指定

合作者

  • 没有指定

产品附带信息

健康指标的使用和传播可能会导致侵犯隐私。 组织可能会面临风险。 这些风险可能源于遵守欧盟的 GDPR、美国的州法律或其他法律。 GitHub 和 GitLab 等数据提供商的服务条款也可能存在合同风险。 必须检查指标的使用是否存在风险和潜在的数据伦理问题。 请参见 CHAOSS 数据伦理文件 有关其他指导。

标签:
本文是否有帮助?
反感 0