运营节奏
用四个信号读懂项目组合健康度。
总吞吐量
+10%21.4
整个 OSS 组合每天关闭的 issue 与 pull request。
PR 合并
+19%9.8
每天合并的 pull request，与未合并关闭的 PR 分开统计。
已处理外部 PR
+88%4.3
来自维护者群体之外的人类贡献者，每天得到处理的贡献。
组合覆盖度
+0%12/21
窗口期内至少关闭过一个 issue 或 pull request 的仓库。
维护雷达
队列现在有记忆了。
xref 会核对每个仓库的 backlog，保留两次扫描之间的变化，并在不修改 GitHub 的前提下区分审查、清理和探索。
雷达快照 · 2026年8月14日 08:39
完整覆盖
21/21
维护范围内的仓库均已读取，没有失败或覆盖限制。
需要核对
18
在关闭、替换或重新关联工作前，需要人工验证的候选项。
待审查 PR
20
可进入 factory review gate 的开放 pull request。
可进入探索
3
没有活跃队列的仓库将进入 dogfooding 和产品方向探索。
自上次扫描后的变化
+0 新增 · 0 变更 · 0 已解决
流动
按时间标准化的新增与解决。
每根柱子都是等长窗口内的每日速率。窗口随发布增长，最长十四天。
新开 issue
关闭 issue
新开 PR
关闭 PR
获取与运营
更多产出不自动等于更多贡献者。
外部流入与维护处理能力分开显示，避免把维护冲刺误当成社区增长。
外部 PR 新增 / 天
4.3
4.1 → 4.3
+7%
衡量目录是否吸引贡献尝试的最清晰早期信号。
外部 PR 处理 / 天
4.3
2.3 → 4.3
+88%
组织将外部贡献转化为明确决策的速度。
每日净积压
5.4
4.6 → 5.4
+16%
每天新增工作减去关闭工作。负数表示队列缩小。
分布
健康的组合需要广度，而不是一个英雄仓库。
汇总吞吐量可能掩盖集中度。这里准确显示已关闭工作发生在哪里。
前两名占比
61%
的发布后关闭工作来自两个最活跃的仓库。
方法
数字应该能够自我解释。
这个仪表板明确说明统计范围、外部贡献者定义以及如何保持发布对比公平。
- 01
包含当前 /oss 列出的全部仓库，覆盖 crafter-station、Railly 与 shiarauzo。
- 02
发布前后使用完全相同的时长，最长十四天，并以每日速率表达。
- 03
外部贡献者指不是 owner、组织成员或仓库 collaborator 的真实用户。
- 04
GitHub Search 每小时刷新。不可用时，页面会明确标记并展示最近一次验证快照。
- 05
发布后新增的仓库计入当前组合运营。它们更早的活动仅作为背景，不代表发布带来的因果影响。
轮到你了
有人 ship，数字才会变化。
选择一个持续维护的仓库，找到聚焦的 issue，把下一个 pull request 送进系统。