拉取请求生命周期政策

本政策使开放的拉取请求列表聚焦于正在积极推进且有现实合并路径的贡献。

目标

  • 让开放中的拉取请求对贡献者和维护者保持可管理。

  • 将审查精力优先用于正在向前推进的变更。

  • 为草稿拉取请求和不活跃拉取请求提供明确的预期。

范围

本政策适用于仓库中的所有拉取请求,包括草稿拉取请求。

定义

活跃拉取请求

有实质性进展的拉取请求,例如提交、审查回复或针对所请求变更的更新。

草稿拉取请求

为进行中的工作和早期反馈而开启的拉取请求。

停滞拉取请求

在不活跃窗口内没有实质性活动的拉取请求。

已关闭的不活跃拉取请求

因不活跃、被取代或没有明确合并路径而关闭的拉取请求。

草稿拉取请求的预期

  • 草稿拉取请求应包含清晰的问题说明、当前状态和已知的不足。

  • 草稿拉取请求应在 30 天内转为可供审查(ready-for-review)。

  • 如果草稿拉取请求在 30 天内不活跃,可能会被标记为停滞并发布提醒。

  • 如果在停滞通知发布后额外的 7 天内仍没有实质性进展,该拉取请求可能会被关闭。

可供审查(Ready-for-Review)拉取请求的预期

  • 作者应在 21 天内回复审查反馈。

  • 如果已就绪的拉取请求在 30 天内没有实质性活动,可能会被标记为停滞。

  • 如果在停滞通知发布后 7 天内没有进行实质性更新,该拉取请求可能会被关闭。

  • 对于存在未解决的阻塞性反馈超过 45 天的拉取请求,如果没有提供具体计划,可能会被关闭。

什么算作实质性活动

实质性活动的示例包括:

  • 针对审查反馈的新提交。

  • 具体的技术回复和后续更新。

  • 实质性改变拉取请求的重大修订更新。

通常不算作实质性活动的示例包括:

  • 没有技术更新的仅 ping 评论。

  • 没有实质性变更的琐碎变基(rebase)。

例外情况

以下拉取请求可能免于自动的不活跃关闭:

  • 安全关键修复。

  • 版本阻塞项。

  • 明确在等待外部依赖、并附有已链接跟踪项的拉取请求。

豁免的拉取请求仍需要至少每 30 天进行一次状态更新。

被取代的拉取请求

当工作被另一个拉取请求取代时:

  • 以被取代为由关闭旧的拉取请求。

  • 链接替代它的拉取请求。

  • 添加简短的总结评论以保留上下文。

重新开启已关闭的不活跃拉取请求

因不活跃而关闭拉取请求是一项保持开放列表可管理的行政措施。这并不是对贡献的拒绝。

已关闭的不活跃拉取请求可在以下情况下重新开启:

  • 作者发布了更新后的计划。

  • 先前的阻塞性反馈已得到处理。

  • 维护者确认审查可以继续。

鼓励贡献者在能够提供实质性更新时随时重新开启。

职责

贡献者应当:

  • 保持拉取请求描述为最新。

  • 及时回复审查评论。

  • 草稿拉取请求一旦可供审查,就将其转为可供审查状态。

请查阅 贡献者期望 文档以获取更多指导。

维护者应当:

  • 一致地执行停滞和关闭决策。

  • 提供明确的阻塞性反馈。

  • 关闭时给出明确理由和重新开启路径。

请查阅 维护者职责 文档以获取更多指导。