从业者指南：响应能力入门

主要指标：

如果您还没有阅读 从业者指南：简介 - 解释指标时要考虑的事项，请现在暂停并阅读该指南。

响应能力指标是评估项目健康状况的重要组成部分（Eghbal，2020），对于招募新贡献者和留住现有贡献者尤其重要。响应能力（包括完成时间）是吸引新人参与项目的最重要因素之一（Fronchetti 等人，2019）。GitHub 在 2017 年进行的一项调查发现，在考虑是否为开源项目做出贡献时，95% 的贡献者表示，响应迅速的维护者非常重要或有点重要。当贡献者没有及时收到对贡献的适当回应时，他们会感到沮丧，但当他们得到对其贡献的快速而有用的解决方案时，他们会受到鼓舞。当项目响应迅速时，它可以让人们想要做出更多贡献或继续做出贡献。及时、周到和友好的回应贡献者表明您欣赏他们的工作。

响应能力还会影响整个项目运营，尤其是变更请求（拉取请求/合并请求）。变更请求在未合并的情况下停留的时间越长，合并冲突就越多，累积到可能变得太困难或无法接受的程度。有时，由于不兼容、与总体项目方向冲突或其他考虑因素，贡献可能永远不会被包括在内。在这种情况下，最好以友善和周到的方式让某人知道为什么他们的贡献不会被接受，而不是让他们猜测并因缺乏回应而增加他们的挫败感。您可以通过响应和跟上贡献来减少技术债务、减少维护人员的工作量并提高贡献者的保留率。

第 1 步：确定趋势

虽然查看响应能力的方法也很复杂，但如果您从识别趋势开始，那么响应能力指标的入门就会很简单。通过查看 第一反应时间, 关门时间及 变更请求关闭率 在一起，您可以了解贡献者是否得到及时响应，以及您是否通过关闭变更请求（合并或关闭而不合并）来跟上贡献。

第一反应时间

有很多方法可以查看首次响应时间，包括平均值/中位数的变化。尽管如此，将变更请求总数与在对您的社区来说合理的某个基准（例如两个工作日）内响应的数量进行比较仍然很有帮助。我喜欢这种方法，因为您可以看到贡献总量如何影响您的响应能力。

首次响应时间显示大多数 PR 在 2 个工作日内关闭

该图显示了人类首次做出反应的时间。这很重要，因为人们在贡献中投入了大量工作，并且可能会关注变更请求或问题，并等待查看其收到情况。如果它坐在那里几天或几周都没有回应，人们可能会感到沮丧，并觉得自己浪费了时间。在这种情况下，任何回应都可能比没有回应要好，即使回应是感谢他们并让他们知道何时需要反馈。

关门时间

首次响应时间显示了当有人发起贡献时您的响应速度，而结束时间则可以深入了解项目从启动到完成请求的速度。关闭时间经常用于变更请求和问题，但也可以适用于其他类型的贡献。就像首次响应的时间一样，如果贡献者觉得自己的贡献没有取得进展并没有接近完成，他们可能会感到沮丧。

关于关闭时间的一个注意事项是，完成请求或关闭问题所需的时间根据复杂性的不同而有很大差异。对于变更请求，一行变更通常可以在很短的时间内完成，而大型组件的完整重构可能需要更长的时间进行审查和测试才能合并。问题的结束时间甚至更加可变，可能需要几分钟到几年的时间，因为有些问题的影响可能很小，以至于任何人都不会决定解决它们。

由于这种可变性，除了平均关闭时间之外，通常最好查看平均关闭时间，因为中值可能更接近人们对完成某项任务所需时间的看法。

平均收盘时间为 8.941 天，中位收盘时间为 4.022 天

闭合率

除了查看获得初步回应和结束贡献所需的时间外，了解项目跟上贡献的速度也很重要。例如，大量的未结拉取请求有时被认为是维护者“在与项目外部人员打交道时不太认真的标志，因为每个未结拉取请求都表明代码被忽略了，而不是被接受、拒绝或评论”（Dabbish 等人，2012 年）。

关闭比率 - 维持并跟上贡献，表明它们在 7 月和 8 月落后

该图查看变更请求（合并请求/拉取请求）的关闭率，以了解项目是否跟上传入的贡献。这很重要，原因有几个。旧的变更请求有时会保留太长时间，因为维护人员不想告诉某人它不会被接受，这通常是出于很好的原因，例如架构不兼容或与项目方向的其他冲突。这使得贡献者犹豫不决，不确定为什么他们的请求没有被合并，这可能会浪费人们的时间并对项目产生不良影响。在这种情况下，为维护人员提供一些关于关闭变更请求的重要性以及如何以同理心和善意对待那些投入工作做出贡献的人的培训可能会有所帮助。如果即使质量很好，相关的变更请求也没有在合理的时间内合并，这可能表明该项目没有足够的维护人员，或者维护人员没有足够的带宽来跟上。一段时间后，合并旧的变更请求也变得不切实际，因为通常存在太多合并冲突而无法实际解决。

第 2 步：诊断

正如从业者指南简介中提到的，您应该首先向一些密切参与项目的人员展示数据，以便您可以一起查看这些图表中确定的趋势，并根据项目中可能发生的其他事情来解释它们。该项目。例如，步骤 1 中的首次响应时间和结束比率图表显示 XNUMX 月和 XNUMX 月的差距更为显着，如果是一年中的其他时间，这可能会让我更担心。在这种情况下，这可能意味着人们正在放暑假，这对项目维护人员来说可能是健康的。

关闭比率 - 维持并跟上贡献，表明该项目已逐渐停止跟上

如果趋势表明响应能力在几个月内逐渐下降，那么可能是时候找出原因了。在上图中，您可以看到，直到六月，该项目每个月都跟上他们的拉取请求，但最近已经落后了。这才几个月的时间，所以这可能不是问题，该问题可能是由许多可能无法表明响应能力存在根本问题的因素引起的：

  • 八月份捐款的激增可能造成积压，他们仍在处理。
  • 由于拉取请求的数量较低，他们可能收到了多个复杂的拉取请求，这些请求需要更长的时间才能合并。

然而，其他事情也可能导致这种情况，这可能是一个令人担忧的问题。例如，可能一个或多个关键人员没有足够的时间投入到该项目中，或者增加的拉取请求数量可能超出了他们的管理能力。

显示关闭时间逐渐增加的交货时间

在诊断结束时间时，查看结束时间随时间的变化趋势会有所帮助。在这个项目中，结束趋势的时间正在增加，并且需要更长的时间来结束问题，但它是逐渐增加的。在此图所示的 5 年内，该项目可能变得更大、更复杂，因此这可能是可接受的增长。最好看看在一些大峰值期间发生了什么，以了解发生了什么，并决定是否可以采取不同的措施来更好地处理这些峰值。

第 3 步：根据需要收集其他数据

步骤 1 和 2 中使用的示例提供了一个起点，可以扩展该起点以查看跨各种渠道（例如问题、变更请求、审核）的类似响应指标

CHAOSS 还有与响应能力相关的其他指标，可以帮助诊断社区内的特定问题。

指标：

第四步：做出改进

尝试通过要求现有维护者更快地响应并解决更多贡献来向现有维护者施加更大压力来尝试以响应性解决问题可能很诱人，但这很少能解决长期问题。这可能会带来短期收益，但如果您不首先解决导致缺乏响应能力的根本问题，从而让维护人员精疲力竭，那么随着时间的推移，可能会对社区和项目造成损害。

如果您发现响应能力下降，那么可能是时候让更多的贡献者担任领导角色，并提升一些贡献者成为项目的维护者了。您可以首先查看项目中的贡献者，找到定期贡献但还不是维护者的人。良好的第一步是将一些贡献者提升为审阅者角色，他们可以通过审阅其他社区成员的贡献来减轻维护者的负担。更多的人审查贡献应该提供更快的首次响应时间和改进的变更请求关闭率，因为维护人员为每个贡献要做的工作更少，并且他们可以专注于项目中需要更多专业知识的事情。您还应该考虑现有贡献者是否准备好在项目中承担维护者角色，他们可以首先使用 OWNERS 或 OWNERS 负责存储库中的单个区域 代码所有者文件 来管理访问。如果您还没有关于项目中领导角色的良好文档，您可能还需要更好地定义贡献者、审阅者和维护者的角色和职责，这可以帮助使用诸如 贡献者阶梯。 请看看 可持续发展贡献者实践指南 了解有关招募贡献者并将他们提升为领导角色的更多信息。

它还可以帮助人们设定明确的期望，以确定何时可以期待得到回应。例如，contributing.md 指南可以告知贡献者平均或预期响应时间。您还可以考虑在项目里程碑或路线图中包含有关休假或其他可能导致响应延迟的详细信息，以表明响应可能会延迟。

减少审阅者摩擦并使维护者更容易审阅贡献的另一种方法是使用 问题和变更请求模板 帮助贡献者做出好的贡献，而需要维护者更少的工作。这里有一个 一些事物类型的例子 您可能希望在这些模板和贡献者指南中包含以下内容：

  • 不要发送超过 X 行代码的更改（500-800 可能是合适的阈值）
  • 不要发送涉及超过 X 个文件的更改（最好是一个文件，但如果您必须更改多个相关文件，请将其范围限制为每个更改请求的一个功能/问题）
  • 将变更请求保留在单独的功能分支中。
  • 清楚地传达在合并之前将对更改请求运行哪些检查（例如，样式检查器、linter、测试套件、签名提交、开发人员原始证书检查）。
  • 变更请求的命名、标记和标记的清晰策略和示例。
  • 提供对审核的期望（例如，我们尽量不要让问题/变更请求开放超过 X 天，我们每 X 天/周/月进行积压整理。）

使用问题和变更请求模板时需要注意的是，您需要在获取足够的信息以使维护人员更容易审查请求与不要求提供太多信息之间找到平衡，以免在新贡献者做出贡献之前就吓跑他们。

与您的维护人员交谈，了解他们还花时间在哪些事情上。如果维护人员在社区管理、文档或其他非​​编码任务上花费大量时间，那么招募人员来帮助完成这些角色是值得的。在其他情况下，改进的文档可能有助于减少维护人员的工作量；例如，如果维护人员花费大量时间来引导贡献者或回答有关贡献流程的问题，那么更好的入职文档或贡献者指南可能会腾出一些时间来专注于响应传入的贡献。

第 5 步：监控结果

您如何监控结果将取决于您决定进行哪些改进。继续监控首次响应时间、关闭时间和变更请求关闭率是一个好的开始。如果您使用了步骤 3 中的其他数据，您还应该监控这些指标。

如果您正在招募新的审批者和维护者，可能需要一段时间才能看到这些努力的结果，因此您可能在 3 到 6 个月内看不到显着的改进。

响应能力可能是一个具有挑战性的改进指标，因为项目中发生的许多事情都会影响响应能力，人们通常会关注响应能力，但当人们不再关注它时，短期改进就会再次消失。这意味着响应能力可能是一个你应该始终监控的指标，无论你是否关注它。

注意事项和注意事项

  • 响应能力很难诊断，因为很多因素都会影响响应能力，所以如果您的第一次尝试没有带来改善，请不要灰心。

补充阅读

反馈

我们很乐意收到反馈，以了解更多有关人们如何使用 CHAOSS 从业者指南以及我们如何随着时间的推移对其进行改进的信息。请完成此 简短的调查 提供您的反馈。

合作者

以下人员为本指南做出了贡献：

  • 黎明福斯特
  • 陈翁
  • 雷米·迪考梅克
  • 路易斯·卡纳斯·迪亚斯
  • 约阿希姆·诺雷科

案例

CHAOSS 从业者指南是 MIT 授权的动态文档，我们欢迎您的反馈和意见。您可以在以下位置建议对本文档进行修改 https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/responsiveness.md