# 维护者雷达优先级矩阵

这个矩阵同时覆盖三类判断：

1. 响应是否超出 SLA
2. reviewer 负载是否失衡
3. 责任关系是否失效或停滞

按下面的规则把条目分到 `HOT`、`WATCH`、`BACKGROUND`。多个信号同时命中时，取更高优先级。

## HOT

- Issue 超过 24 小时无人首次响应，且当前明显需要维护者接手。
- PR 超过 3 天无人 review，或作者更新后超过 48 小时无人复看。
- PR 已 `approve` 超过 2 天仍无人推进合并或后续处理。
- 同一 reviewer 挂着多个高优先级 PR，已经形成明显瓶颈。
- 条目已有 assignee / reviewer，但在阈值内完全无新动作。
- 新贡献者提交或高影响条目因无人响应而持续停滞。

## WATCH

- 条目还未超 SLA，但已经接近阈值。
- reviewer 分配不均已经出现趋势，但还没形成硬阻塞。
- Issue 有责任人，但更新频率明显偏低。
- PR 讨论在继续，但没有明确下一步负责人。
- requested changes 后长时间无更新，需要维护者决定提醒还是收口。

## BACKGROUND

- 普通系统消息、点赞、关注、加入退出项目。
- 已经明确归属、暂时不需要维护者处理的条目。
- 与当前值班轮次无关的历史性提醒。

## 额外判断维度

在同优先级内，再按这些维度排序：

1. 是否在等待维护者，而不是等待作者。
2. 是否影响新贡献者体验或版本节奏。
3. 是否能通过一次短动作明显降低队列风险。
4. 是否会牵连多个 PR、Issue 或模块。
5. 是否存在明显的 reviewer 负载再平衡空间。
6. 是否属于“已分配但无人推进”的责任失效。

## 建议阈值

如果仓库没有自定义规则，默认使用下面的启发式阈值：

- Issue 首响超时：24 小时
- PR 首次 review 超时：72 小时
- `approve` 后无人推进：48 小时
- 作者按 review 更新后无人复看：48 小时
- assignee / reviewer 名下条目长期停滞：5 到 7 天
- reviewer 高负载预警：同一时间挂 4 个以上待处理 PR
