PR-scoped approval delegation
PR 范围内的批准委托
A reviewer may trust another reviewer to decide a particular PR while retaining the score associated with their own repository role and code ownership. Counting both the original approval and transferred points would inflate that reviewer's contribution.
English
Problem
A reviewer may trust another reviewer to decide a particular PR while retaining the score associated with their own repository role and code ownership. Counting both the original approval and transferred points would inflate that reviewer's contribution.
Decision
The approval policy accepts /delegate @username in PR conversation comments. Each eligible sender's points follow the named recipient's effective approval, once, using the sender's weight. Delegation applies only to that PR and only between write-capable accounts other than the PR author. Received points cannot be forwarded. The command dismisses the sender's prior approvals and change requests through GitHub. Other effective blocking reviews still follow blocking-review policy.
The latest surviving eligible command in comment creation order determines the recipient. Edited commands require the latest editor to match the author’s immutable account ID; other writers cannot transfer or cancel that author’s points by editing a comment. A self-delegation or a subsequently submitted review restores the sender's own decision. Comment-only reviews also reclaim the points; pending reviews do not. Equal timestamps favor the review, and subsequent dismissal cannot revive the delegation. A fresh command after the review can delegate again. Edits and deletions recompute from current comments, including restoration of older commands. The trusted publisher filters conversation comment changes for /delegate, resolves the live open PR head, and reads comments and editor identity as API data. Every evaluation reconciles active eligible commands, dismissing prior decision reviews and requesting recipients unless already approved or requested. This covers replaced queued events and draft-to-ready transitions; other requested reviewers remain unchanged. Scores refresh after dismissal, which retains the old submission timestamps and cannot cancel delegation. Removing the recipient's approval removes counted points while retaining delegation for their next approval. Drafts do not dismiss or request reviews. Dismissal failures fail evaluation; request failures are logged separately and retried on later evaluations. Closed or merged PRs are skipped before status writes and dependency setup. It preserves the separate review-workflow validation.
Alternatives considered
Count delegation as immediate approval. This would approve a PR before the chosen reviewer makes a decision.
Add the sender's score without removing their direct contribution. This would count one account twice and weaken the approval threshold.
Forward received points through delegation chains. This would let a recipient transfer another person's points to an account that person did not name.
Only suppress the sender's old decision in the score. GitHub would retain the old approval or blocking review. Dismissing it keeps native review state consistent with the handoff.
Keep delegation after the sender reviews. A submitted review expresses the sender's own decision, so continuing to use someone else's approval would disregard it.
Persist commands separately from comments. This would require additional storage and reconciliation for edits and deletions; current comments already provide an inspectable record.
Consequences
Delegation preserves the sender's production ownership weight and the independent author-credit rule. Each evaluation needs complete comment and editor history and current participant permissions; missing history fails evaluation. Editing an older command does not change its priority, and deleting a newer command may reactivate an older one. Policy tests cover score conservation, review-driven revocation, prior-review dismissal, permission filtering, review requests, blockers, pagination, and failure publication; workflow tests pin trusted execution and shared per-PR concurrency. Native stale-review and latest-push requirements remain GitHub's responsibility.
中文
Problem
评审人可能信任另一位评审人来决定某个 PR（Pull Request），同时保留自己的仓库角色和代码归属对应的分数。如果同时计入原始批准和转交的分数，就会放大该评审人的贡献。
Decision
批准策略 接受 PR 普通评论中的 /delegate @username。每位符合资格的委托人，其分数跟随指定受托人的有效批准，按委托人的权重计入一次。委托仅适用于当前 PR，且双方都必须具有写权限，不能是 PR 作者。收到的分数不能继续转交。命令会通过 GitHub 撤销委托人原有的批准和变更请求。其他有效阻塞评审仍遵循阻塞评审策略。
按评论创建顺序，最新、仍存在且符合资格的命令决定受托人。编辑过的命令要求最近编辑者与作者的不可变账户 ID 一致；其他有写权限的人不能通过编辑评论转交或取消作者的分数。委托给自己或随后提交评审会恢复使用委托人本人的评审决定。仅评论的评审也会收回分数；尚未提交的评审不会。时间戳相同时以评审为准，随后撤销评审也不会重新启用委托。评审之后的新命令可以再次委托。编辑和删除会根据当前评论重算，包括恢复较早的命令。可信发布器按 /delegate 筛选普通评论变更，解析实时且未关闭的 PR 头提交，并将评论及编辑者身份作为 API 数据读取。每次评估都会处理所有有效且符合资格的命令，撤销旧的决定性评审，并请求尚未批准、尚未收到请求的受托人进行评审。这覆盖了排队事件被替换以及草稿转为 ready 的情况；其他 requested reviewers 保持不变。撤销后刷新分数；撤销保留旧提交时间戳，不会取消委托。移除受托人的批准只会移除计入的分数，委托仍然保留，供其下次批准使用。草稿 PR 不撤销或请求评审。撤销失败会使评估失败；请求失败单独记录日志，并在后续评估中重试。已关闭或合并的 PR 会在写入状态和安装依赖之前跳过。独立的评审工作流验证 保持不变。
Alternatives considered
把委托直接视为批准。 这会在选定的评审人作出决定前批准 PR。
增加委托人的分数，同时保留其直接贡献。 这会将同一账户计算两次，削弱批准阈值。
沿委托链继续转交收到的分数。 这会允许受托人将他人的分数转给未经原委托人指定的账户。
只在分数中忽略委托人的旧决定。 GitHub 会保留原有批准或阻塞评审。撤销旧评审使原生评审状态与委托一致。
委托人提交评审后仍保留委托。 已提交的评审表达了委托人本人的决定，继续使用他人的批准会忽略该决定。
在评论之外单独持久化命令。 这需要额外存储，并协调编辑与删除；当前评论已经提供可检查的记录。
Consequences
委托保留委托人的生产代码归属权重和独立的作者信用规则。每次评估都需要完整评论与编辑者历史和参与者的当前权限；历史缺失会使评估失败。编辑较早命令不会改变其优先级，删除较新命令可能重新启用较早命令。策略测试覆盖分数守恒、评审触发的收回、旧评审撤销、权限过滤、评审请求、阻塞评审、分页和失败状态发布；工作流测试约束可信执行及每个 PR 共享的并发分组。过期评审和最新推送要求仍由 GitHub 原生规则负责。