Zen Browser 月度 Issue Metrics 报告解读：2026 年 1 月数据、自动生成流水线与指标分析

本文围绕 2026 年 1 月 Issue Metrics 报告 展开：先还原这份报告是如何由 GitHub Actions 每月自动生成的，再逐项解读其中的响应时长、关闭时长、未关闭数量等核心指标，并结合上月报告与仓库内的 issue 模板、标签流水线做横向对照，帮助你快速读懂一份社区健康度数据报告并复用其分析方法。

报告本身包含什么

2026 年 1 月报告 是一份典型的 Issue Metrics 月度统计文档，全文由四部分构成：

1. 响应/关闭时长汇总表：给出两个关键时长的平均值、中位数与 90 分位值。
2. 状态计数表：当月创建 issue 中仍开放、已关闭与总数。
3. 逐条 issue 明细表：244 行，每行包含标题、issue URL、首次响应时长与关闭时长。
4. 报告尾注：说明生成工具与检索条件。

核心指标原文如下：

Metric	Average	Median	90th percentile
Time to first response	14:19:40	2:07:00	1 day, 4:29:24
Time to close	23:19:13	6:44:05	2 days, 5:35:23

Metric	Count
Number of items that remain open	103
Number of items closed	141
Total number of items created	244

时长列采用 H:MM:SS 或 N days, H:MM:SS 格式；值为 None 表示该事项截至报告生成时尚未首次响应（首次响应列）或尚未关闭（关闭时长列）。尾注给出的检索语句是：

repo:zen-browser/desktop is:issue created:2026-01-01..2026-01-31

即统计范围仅限 2026-01-01 至 2026-01-31 期间创建的 issue，与报告文件名中的日期区间一一对应。

报告是如何自动生成的

这份报告并非人工编写，而是由仓库内的 Monthly issue metrics 工作流 每月自动产出。从工作流定义看，其执行链路为：

1. 触发时机：schedule 中的 cron: "3 2 1 * *"，即每月 1 日凌晨 2:03（UTC）自动运行，也支持 workflow_dispatch 手动触发。
2. 计算上月日期区间：用 date 命令算出上个月的 first_day..last_day（如本次为 2026-01-01..2026-01-31），并写入 GITHUB_ENV，后续步骤引用 env.last_month 与 env.last_month_year。
3. 运行 issue-metrics 工具：调用 github-community-projects/issue-metrics@v2 动作，环境变量为：
   • SEARCH_QUERY: "repo:zen-browser/desktop is:issue created:${{ env.last_month }}" —— 与报告尾注中的检索语句完全一致；
   • HIDE_AUTHOR: true —— 报告中不出现 issue 作者信息（因此明细表只有标题、URL 与两列时长）；
   • HIDE_TIME_TO_ANSWER: true —— 隐藏“解答时长”一列，因此报告只保留 first response 与 close 两个时长指标。
4. 归档命名：把生成的 issue_metrics.md 移动到 docs/issue-metrics/${last_month_year}_${last_month}.md，并删除中间产物 issue_metrics.json。这也解释了 docs/issue-metrics 目录下的命名规则——2026_2026-01-01..2026-01-31.md 就是「年份_起始日..结束日」的拼接结果，同目录下可查到 2025 年 12 月的报告 以及更早的逐月文件。
5. 自动提交：使用 stefanzweifel/git-auto-commit-action@v5，以 “Zen Browser Robot” 身份提交，commit message 固定为 docs: Update monthly issue metrics, b=(no bug), c={docs}。

工作流权限最小化：仅 contents: write 与 issues: read，token 使用部署密钥 secrets.DEPLOY_KEY。从源码结构看，这是一条“只读 issue 数据、只写 docs 目录”的单向流水线，不会修改任何产品代码。

如何读懂两份核心时长指标

Time to first response（首次响应时长） 指从 issue 创建到第一次有人（通常是维护者）回复的时间间隔。2026 年 1 月的平均值 14:19:40 远高于中位数 2:07:00，说明分布严重右偏——多数 issue 在两小时内得到响应，但少数 issue（最长一例为 1 day, 4:29:24，对应 “Right-click > Move Tab does not always show your Workspaces”）把均值拉高。90 分位 1 day, 4:29:24 意味着 90% 的 issue 在约 28.5 小时内获得了首次响应。

Time to close（关闭时长） 指从创建到关闭的总时长。1 月平均 23:19:13、中位数 6:44:05、90 分位 2 days, 5:35:23。中位数不足 7 小时，说明大量 issue 被快速关闭（常见路径：确认为已知问题、提供临时规避方案或归并重复项）；而长尾部分超过两天。

结合明细表可以验证这两个分布：大量行（如 0:06:58、0:13:05）的 first response 与 close 时长完全相等，表示 issue 在被首次响应的同一分钟内即被关闭（典型的重复合并或配置问题答复）；也有 None | 2 days, 10:11:43 这类“从未被回复但最终关闭”的行。

与上月（2025-12）的环比对照

将 1 月报告与 2025 年 12 月报告 对照，可以看到一个月度的社区负载变化：

指标	2025-12	2026-01	变化
新建 issue 总数	160	244	+52.5%
已关闭	85	141	+65.9%
仍开放	75	103	+37.3%
首次响应（平均/中位数/p90）	1 天 0:30:20 / 5:02:49 / 2 天 2:05:28	14:19:40 / 2:07:00 / 1 天 4:29:24	全面缩短
关闭时长（平均/中位数/p90）	1 天 6:06:03 / 15:57:36 / 3 天 0:29:29	23:19:13 / 6:44:05 / 2 天 5:35:23	全面缩短

从数据看，1 月 issue 量随版本发布节奏明显上升（明细表中大量标题指向 1.18.x 系列版本），但团队响应与关闭效率同步提升：平均首次响应从约 24.5 小时降到约 14.3 小时，平均关闭时长从约 30 小时降到约 23.3 小时。这是解读月度报告时最有价值的用法——单月数据只能看绝对值，环比才能看趋势。

1 月明细数据中的主题聚类

244 条明细记录（issue 编号从 11781 到 12186 区间）可以按标题自然聚成几类高频主题，这对维护者优先排障有直接参考价值：

窗口同步（Window Sync）类问题是 1 月最集中的主题之一，例如 “Tabs being cloned to all windows”、“Disabling zen.window-sync.enabled breaks new zen instances”（关闭后首次响应 4:34:06、关闭耗时 22:44:50）、“Window Sync with multi monitors is a nightmare”、“Window sync with zoom” 等十余条。这类问题直接对应仓库中的偏好项 prefs/zen/window-sync.yaml：

- name: zen.window-sync.enabled
  value: true

- name: zen.window-sync.log
  value: false

- name: zen.window-sync.prefer-unsynced-windows
  value: false

- name: zen.window-sync.open-link-in-new-unsynced-window
  value: true

- name: zen.window-sync.sync-only-pinned-tabs
  value: false

该文件定义了 window sync 的全部开关及默认值（默认开启同步、关闭日志）。明细表中“禁用 zen.window-sync.enabled 导致新窗口异常/无法重命名标签”的多条 issue 表明：在默认值 true 的用户侧手动改回 false 后会出现回归路径，这是偏好开关之间耦合产生的典型问题面。实现侧相关模块位于 src/zen/sessionstore/ZenWindowSync.sys.mjs 与 src/zen/sessionstore/ZenSessionManager.sys.mjs（会话/窗口同步管理），阅读这些文件可以定位同步逻辑的实际入口。

升级后标签/工作区丢失类是第二集中主题，如 “Update deleted all my tabs”、“1.18.3b AutoUpdate Lost all Tabs including Essentials”、“All my workspaces and tabs just gone after update”、“Loss of open tabs after update 1.18.x” 等，多条都指向 1.18.x 系列自动更新流程，且部分关闭时长极长（如 “Cursor stuck as default everywhere after updating to 1.18.3b” 关闭耗时 21:06:24）。这与 12 月报告中同样出现的 “Upgrade to 1.18t lost everything” 形成跨月延续线索，提示版本升级路径的会话持久化是当时需要重点回归验证的领域。

Essentials / Pinned 标签消失类占据第三大簇： “Essential tabs dissapear from sidebar UI”（1 分 44 秒内即关闭）、“Essentials becoming invisible / absent until browser restarted”、“Pinned tabs not resseting on startup”、“Pinned tabs don't scale: hundreds of pins freeze browser”（关闭耗时 1 天 13:33:03）。该簇同时覆盖 UI 显示异常与性能问题两个层面。

其余可见主题包括：跨窗口拖拽标签异常（“Cannot drag tabs from window with 2 or more tabs into another window” 等）、Workspace/Space 管理（“Drag and drop tabs to different workspaces ... causes the tabs to disappear after restart”）、平台相关（Wayland 白屏、macOS 扩展弹窗在别的桌面打开、KDE 全局菜单无响应）以及渲染/性能类（“Zen struggle rendering large DOM lists containing lots of child elements” 首次响应长达 2 天 21:36:13）。

报告数据之外的配套机制

解读这份报告时，还有两处仓库内的配套机制值得了解，它们决定了数据质量的上限：

Bug 报告模板。.github/ISSUE_TEMPLATE/bug_report.yml 强制要求填写：问题描述、期望/实际行为、复现步骤、版本号（明确要求从 “Help -> About Zen” 获取，不允许填 “latest”）、平台下拉（Linux AppImage/Flatpak/Tarball、macOS aarch64/Intel、Windows x64/aarch64）以及组件下拉（Tabs、Workspaces、Sync、URL Bar、Bookmarks 等 20 个选项），并带有前置检查（确认非重复 issue、确认无法在 Mozilla Firefox 上复现、确认移除 Mods 与自定义 CSS 后仍可复现）。模板中 “不能复现于 Firefox” 的要求解释了为什么报告尾注的检索词是 is:issue 且明细中混有纯行为咨询——模板在源头过滤了部分噪声。

自动标签流水线。.github/workflows/issue-labeler.yml 在 issue 打开时解析上述表单（stefanbuck/github-issue-parser@v3），再依据 .github/advanced-issue-labeler.yml 的映射策略给 issue 打上 component: * 与 platform: * 标签（如表单选择 “Sync” 得到 component: sync，选择 “Linux (Flatpak)” 得到 platform: linux）。这意味着明细表中的标题文本虽然无法直接携带标签信息，但对应的 issue 页面上都有结构化标签——对维护者而言，这份月度报告实际上是“标签数据的时间切片”，可以按标签维度回查每一条记录的归因。

使用这份月度报告的建议

• 先看三行计数，再看时长分布：open/closed/total 决定当月负载；中位数与 90 分位的差距决定长尾风险。1 月的报告里两者差距明显（first response 中位数 2 小时 vs p90 28.5 小时），长尾治理比提升均值更有意义。
• 按版本/主题聚类读明细表：1 月明细中 1.18.x 字样高频出现，直接指向当月版本发布引入的回归集中区；把同主题 issue 的关闭时长拉出来排序，能找出处理成本最高的条目。
• 与上月环比：docs/issue-metrics 目录下按 年份_日期区间.md 规则每月新增一份，16 个月的序列（2024-11 至 2026-02）已足以画出趋势线。
• 注意统计口径：数据只统计指定区间内创建的 issue，关闭时长以报告生成时刻为截止点，None 是“尚未发生”而非“零”；工具侧通过 HIDE_AUTHOR 隐藏了作者信息，无法从报告中做贡献者维度分析。
• 复现检索：尾注中的 repo:zen-browser/desktop is:issue created:2026-01-01..2026-01-31 与 issue-metrics.yml 中的 SEARCH_QUERY 一致，修改日期区间即可自查任意时段的同类统计。

小结

docs/issue-metrics/2026_2026-01-01..2026-01-31.md 是 Zen Browser 月度社区健康度报告中的 1 月样本：当月新建 244 个 issue，关闭 141 个，平均首次响应 14 小时 19 分、中位数 2 小时 07 分，平均关闭时长 23 小时 19 分，且相较 2025 年 12 月各项时长指标均显著改善。该报告由 issue-metrics.yml 工作流每月 1 日自动生成、自动归档至 docs/issue-metrics/ 并按固定命名提交，配合 bug 报告模板 与自动标签策略 构成一条从“用户提单”到“月度度量”的完整数据链路。读懂这条链路，就掌握了分析任何开源项目 issue 运营数据的方法论。