Triage 角色或更高权限用户现在可以归档拉取请求

拥有仓库中 triage 角色或更高权限的用户现在可以归档和取消归档拉取请求。

以前，归档仅限于仓库管理员，这要求受信任的 triager 将日常审核工作交给拥有更高权限的人。

维护者越来越依赖 triager 来保持拉取请求队列健康，而不授予他们更改代码的权限。

归档——通常用于垃圾、重复或废弃的拉取请求——是一种常见的审核操作，将其限制为管理员给那些委托这项工作的项目带来了不必要的摩擦。

我们还改进了已归档拉取请求变为只读的方式。

以前，归档会锁定拉取请求，但管理员仍然可以留下评论。

现在，我们阻止拉取请求在归档后产生任何新活动。

这使已归档拉取请求保持只读，而不授予 triage 用户操纵对话锁定状态的能力，该操作需要写入权限。

拥有 triage、write、maintain 或 admin 角色的用户可以归档和取消归档拉取请求。

归档会自动关闭拉取请求并使其对话变为只读。

拉取请求归档期间，新评论、反应和自动评论都会被阻止。

已归档拉取请求会从公众视野中隐藏，并且对仓库管理员保持可见。

取消归档会恢复评论和反应的能力，但不会重新打开拉取请求。

如果您有任何问题或反馈，请在我们的社区讨论中留言评论。

GitHub 允许拥有 triage 或更高角色的用户归档与取消归档拉取请求，此前仅限管理员。归档会自动关闭 PR、使对话只读、阻止新评论/反应/自动评论，并从公众视野隐藏；取消归档可恢复评论和反应，但不会重新打开 PR。

• GitHub 允许拥有 triage 或更高角色的用户归档与取消归档拉取请求，此前仅限管理员。归档会自动关闭 PR、使对话只读、阻止新评论/反应/自动评论，并从公众视野隐藏；取消归档可恢复评论和反应，但不会重新打开 PR。
• 原贴提到：Users with the triage role or higher in a repository can now archive and
• 来源：github.blog

这是什么信号

GitHub 在 Changelog 中把归档拉取请求的权限从管理员下放到 triage 及以上角色，同时强化了归档后的只读语义。表面看是一个角色权限的小调整，实际是开源协作平台在治理颗粒度上的继续细化：审核动作与代码写入权限被进一步拆开。

为什么重要

开源项目的 PR 队列里经常混入垃圾、重复或废弃提交。此前只有管理员能归档，导致被信任的 triager 必须把日常审核动作转交给更高权限的人，形成瓶颈。现在 triage 角色可以直接处理这类队列噪声，维护者不必为了审核而授予写权限。与此同时，归档后 PR 自动关闭、对话只读、新评论与反应被阻止，并且对公众隐藏，只对仓库管理员可见。这避免了 triage 用户通过归档来变相锁定对话，因为锁定状态需要写权限。取消归档会恢复评论和反应，但不会重新打开 PR，语义上更接近“解除隐藏”而不是“恢复流程”。

对谁有价值

直接受益的是开源维护者、社区经理和负责 PR 分类的 triager：他们可以更快清理队列，减少管理员介入。平台工程和内部 GitHub 管理员也能借此重新设计角色矩阵，把审核权限和代码权限分开。依赖自动评论的机器人开发者需要特别注意：归档期间自动评论同样被阻止，原有工作流可能失效。

可以怎么行动

第一，梳理仓库角色分配，把合适的社区审核者提升到 triage，而不是直接给写权限。第二，更新审核 runbook，明确归档适用于垃圾、重复、废弃 PR，并记录取消归档不会重开 PR 这一后果。第三，检查现有机器人或自动化脚本是否依赖 PR 归档后仍能评论，必要时改为在归档前触发。第四，建立误归档恢复流程，因为归档会对公众隐藏内容，只有管理员可见。第五，培训 triager 理解归档的可见性与只读影响，避免把归档当作临时静音工具。

风险或限制

归档后 PR 对公众隐藏，可能影响外部引用、透明度或贡献者追溯。取消归档不重新打开 PR，可能让贡献者误以为 PR 已恢复。自动评论被阻止，可能影响合规检查、CI 通知或机器人协调。归档 PR 仅对仓库管理员可见，可能造成其他协作者看不到历史讨论。triage 用户无法操纵对话锁定状态，但归档本身已经实现了只读效果，因此仍需防止误用。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《Triage 角色或更高权限用户现在可以归档拉取请求》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖