Repository navigation
[RFC] ReviewBot PR 全生命周期治理：责任人路由、看板指标与状态提醒 #116
Description
Summary
ReviewBot 已经具备 PR 评审、owner 路由、CI 状态采集和 Kanban 指标等分散能力，但还缺少从“进入评审”到“可合入/长期无进展”的完整运营闭环。
本 RFC 希望先在 vllm-project/vllm-omni 落地一套可审计、可去重的 PR 生命周期自动化：
- 提高责任人覆盖，并优化模块 owner 与模型 owner 的路由优先级；
- 在 Kanban 展示 ReviewBot 相对 Claude Fable 5 和人工评审的质量、效率数据；
- 给每次知识库刷新指定明确责任人；
- PR 一周无人工 commit/comment 时提醒即将关闭，并进入 Kanban 待处理队列；
- CI 失败时提醒修复，CI 恢复且 PR ready 时提醒 committer/maintainer 合入；
- 对性能/价值型 PR 用简短问题要求 A/B 或消融证据。
Motivation
- 现有 owner 路由在 PR 同时涉及模型和公共模块时，容易优先命中模型 owner，而忽略 PR 描述里明确写出的模块边界。
- Kanban 能说明 ReviewBot 自身是否运行正常，但还不能直接回答“相比 Fable 5 和人工评审，质量与效率如何”。
- 知识刷新已有审计和更新流程，但缺少明确的人类责任人、截止状态和阻塞升级入口。
- CI 红、CI 已恢复但无人合入、以及长期无更新的 PR，都依赖 maintainer 人工巡检。
- 性能 PR 的评审容易停留在“有数字”，没有追问数字隔离了什么瓶颈、证明了什么价值，以及改动中各个 claim 的独立贡献。
Proposed behavior
1. Owner routing：模块信号优先于模型 owner
- 扩充 owner catalog/coverage，允许一个 PR 产生多个去重后的候选责任人。
- 路由打分优先级建议为：
- PR 描述中明确声明涉及的模块/组件；
- changed files 命中的模块 owner；
- 模型 owner；
- repository/general fallback。
- 当 PR 描述的模块信号与模型信号冲突时，模块 owner 权重高于模型 owner；模型 owner 可作为补充候选，而不是覆盖模块 owner。
- 在 ledger/Kanban 记录最终候选、命中信号和得分理由，便于发现误路由与补 owner catalog。
- 延续 [Feature] review-bot supports issue assignment #87 的安全边界：默认只 mention，不直接修改 GitHub Assignees。
2. 对性能/价值型 PR 增加简短证据追问
当 PR 声称性能提升、资源下降、架构优化或新增高成本机制时，ReviewBot 先提出三个简单问题：
- 当前性能瓶颈是什么，证据在哪里？
- 这项改动带来的用户或系统价值是什么？
- 是否有同 workload、同 head/config 的 A/B 或消融，能隔离每个主要 claim 的独立贡献？
评论应保持简短、可执行，并根据 claim 大小按比例要求证据，不把 smoke/model-addition PR 一律升级成完整性能研究。需要详细格式时，复用仓库 review skill 的 performance-evidence 规则；可参考 Hongsheng 的 vllm-omni#6820 和性能证据较完整的 vllm-omni#6885。
至少要求固定 base/head SHA、硬件、workload、warmup/重复次数、质量/正确性等价信号；多项叠加优化应尽量提供逐项消融，而不是只给一个 blended delta。
3. 知识库刷新必须有明确责任人
- 每次 release audit、
imupdate或周期性知识刷新都生成/更新一个 Kanban task，并指定一名人类责任人。 - task 展示 repository、from/to baseline、目标版本/SHA、owner、最近更新时间、验证状态和 blocker。
- owner 负责确认结构事实更新、owner-scoped rule 评审和最终 validators 通过；机器人不根据一次 diff 自动生成语义规则。
- 超期或阻塞任务在 Kanban 升级提醒，避免“审计已发现 drift，但无人完成刷新”。
4. 一周无人工活动的 PR 提醒
- 对 open PR 计算最后人工活动时间：
max(last non-bot commit, last non-bot comment/review)；机器人自己的评论不能刷新计时。 - 连续 7 天无人工活动时：
- 在 PR 留一条去重提醒，说明若继续无更新将按仓库策略关闭；
- Kanban 标记为
stale / needs-owner-action； - 通知 @yenuo26（王语）协调责任人处理。
- 同一 inactivity window 只提醒一次；新 commit/comment 后清除 stale 状态并重新计时。
- 第一阶段不自动关闭 PR，只做预警和看板升级；自动关闭需要独立、可配置的仓库策略。
5. CI 失败与 ready-to-merge 提醒闭环
- CI 失败：复用 [RFC] vLLM-Omni 的 PR CI（Buildkite ready / merge 等）挂了之后，希望 review-bot **自动在该 PR 上 @ 贡献者，提醒他把 CI 修好 #108 的方向，在 PR 上 @ author；若最后一次非 merge commit 的提交者/推送者不同，一并提醒修复，并附失败 job、head SHA 和 CI 链接。
- CI 恢复且 PR 满足 ready 条件（非 draft、mergeable、required checks 全绿，并满足仓库要求的 approval/label）时，@ 对应 committer/maintainer 提醒合入。
- 以
(repo, PR, head SHA, lifecycle state)去重；同一 SHA 的 CI 重跑不得刷屏，只有 head 或状态发生有效变化才产生新提醒。 - 跳过 bot/Dependabot，并保留现有
ALLOW_POST和发评安全闸。
6. Kanban 增加外部基线和人工对照
在 #96/#114 已有运行指标和叙事看板基础上，增加按版本/固定评测窗口展示的对照：
- ReviewBot / InferMatrix；
- Claude Fable 5 teacher baseline；
- 人工 review ground truth / maintainer adjudication。
至少展示：
- 质量：有效 finding 数/率、precision、recall 或覆盖率、severity-weighted yield、与人工意见的 overlap/unique findings；
- 效率：总耗时、首个可执行 finding 时间、模型/工具调用或成本、人工复核耗时；
- 可信度：评测 PR 数、finding 数、未知/缺失样本、相同 SHA/base/model/environment/time budget 是否成立。
不满足同一快照和同一预算的结果只能标记为 directional case study，不能显示成严格 A/B 结论。可复用 #24 的比较口径和 #96 的 monthly ground-truth probe。
Lifecycle state/actions
| Event/state | Action | Primary recipient | Dedupe key |
|---|---|---|---|
| PR opened/updated | owner routing + reason | module owner first, model owner supplementary | PR + head + routing digest |
| performance/value claim | three-question evidence prompt | PR author | PR + head + prompt kind |
| required CI failed | ask to fix CI | author + distinct last pusher | PR + head + ci_failed |
| CI green and ready | ask to merge | committer/maintainer | PR + head + ready_to_merge |
| 7 days without human activity | stale warning + Kanban escalation | contributor + @yenuo26 coordination | PR + inactivity window |
| knowledge drift/update due | assigned refresh task | named knowledge owner | repo + target baseline |
Acceptance criteria
- PR 描述明确命中的模块 owner，其路由权重高于模型 owner，并在 ledger/Kanban 可解释。
- owner catalog 可扩充，多 owner 去重且保留安全的 mention-only 行为。
- 性能/价值 claim 能触发“瓶颈、价值、A/B/消融”三类简短问题，并按改动规模要求证据。
- 每个知识刷新任务都有明确 owner、baseline、状态、最近更新时间和验证结果。
- 7 天无人工 commit/comment 的 PR 只提醒一次，进入 Kanban，并通知 @yenuo26 协调处理；机器人评论不重置计时。
- CI 红时提醒修复；CI 绿且 ready 时提醒 committer/maintainer 合入；同一 head/state 不重复评论。
- Kanban 能在同一评测口径下展示 ReviewBot、Fable 5 与人工评审的质量和效率，并始终显示样本量与不可比条件。
- 首期仅对
vllm-project/vllm-omni开启，其他 adapter 显式 opt-in。 - 所有 GitHub 写入继续受现有 posting gate 控制；不自动 merge、不自动 close、不 force-push。
Out of scope
- 自动替 contributor 修 CI 或自动提交代码。
- 在本 RFC 中自动关闭 stale PR 或自动 merge ready PR。
- 用一次 PR diff 自动写入 owner 语义规则。
- 将不同 SHA、不同模型或不同预算的结果包装成严格 A/B。
Related
- [Feature] review-bot supports issue assignment #87 — issue/owner routing 与 owner catalog
- [RFC] vLLM-Omni 的 PR CI（Buildkite ready / merge 等）挂了之后，希望 review-bot **自动在该 PR 上 @ 贡献者，提醒他把 CI 修好 #108 — PR CI 失败后提醒贡献者
- [Feature] provide review result metrics #96 — ReviewBot review metrics 与 monthly ground-truth probe
- RFC: Human-friendly ReviewBot dashboard narratives and history trends #114 — Kanban 人类可读叙事与 14-day trends
- [Feedback] Codex vs. Codex + InferMatrix on vllm-omni #5559: preserve coverage, reduce latency #24 — Codex vs. InferMatrix 的质量、延迟与受控对比口径
- [Discussion] How should InferMatrixCopilot stay aligned with active repositories? #41 / Add deterministic vLLM-Omni release drift audit and maintenance workflow #28 — 活跃仓库知识对齐与 release drift audit
- [Skills] Add perf-evidence isolation, stage-attribution, and realtime-contract requirements vllm-project/vllm-omni#6820 — performance-evidence review skill
Activity
zengchuang-hw commentedon Sep 1, 2026
已按原始纪要拆分为 6 个独立 work items，后续在各子 issue 跟踪设计和实现；本 issue 保留为总览：
tzhouam commentedon Sep 3, 2026
Status 2026-09-03: the six work items are now implemented as stacked PRs on JiusiServe/omni-reviewbot, every one default-off and shadow-first; nothing changes on the host until its flag is set.
ROUTING_SCORER_ENABLED— scorer records and compares by default, drives the mention only when on.CI_OWNER_LOGINSreplaces the hardcoded CI owner and must be set on the host (yenuo26keeps today's routing) before review mode starts.CI_LIFECYCLE_ENABLED,MERGE_NOTIFY_LOGINS(empty ⇒ready_unrouted, recorded only: there is no committer catalog yet)STALE_PR_ENABLED,STALE_COORDINATOR_LOGINPERF_QUESTIONS_ENABLED(needsTRIAGE_ENABLED)Common ground across the four features: one comment per key, claimed in the ledger before the POST with lease recovery and orphan adoption after a crash; request budgets with page caps that fail closed; bot activity (including the reviewbot's own account) never counts as a person;
POST_MODE=shadowrecords would-be comments as artifacts and promotes them exactly once when review mode turns on.Deferred, each on a decision only the owners can make:
imupdate/release audits, or one GitHub issue per refresh) and who assigns owners.Suggested merge order: #27, #28, #31, #29, #30 (children get retargeted to
mainas their parents merge).tzhouam commentedon Sep 29, 2026
All four buildable items are merged and enabled in production: #117 (omni-reviewbot#31), #121 + #108 (#28), #120 (#29), #122 (#30). The two deferred items stay open on their own issues, #118 and #119, since both need an owner decision. Closing this parent.