Issue 分类与优先级

简要摘要

本技能把「读工单 → 打标签 → 定优先级 → 指队列 → 列缺口」拆成可执行步骤；Agent 输出应是可粘贴到跟踪系统的结构化建议，而不是替维护者做未经证实的根因结论。

• 先分类：类型与领域标签决定路由与模板，再谈排期。
• 再定级：按影响面 × 紧急度映射到 P0–P3，并挂上团队约定的首次响应 SLA。
• 最后追问：信息不足时列出最小复现集（版本、环境、日志、期望/实际），避免空泛「无法复现」。

Agent 输出示例——可直接粘贴到 issue 评论：

## 分类建议（issue-triage）

type: bug
priority: P1
area: checkout
sla_first_response: ≤ 1h（7×24）

### 缺失信息，请补充：
1. 版本号与部署环境（prod / staging / commit SHA）
2. 复现步骤及期望与实际行为
3. 相关错误日志或 request_id / trace_id

### 相似 issue（查重）：
- #1234 支付页 500 错误（2024-11）— 建议核对是否同源

标签体系

类型（type）：bug、enhancement、documentation、support、security。优先级（priority）：P0–P3。状态（status）：needs-info、in-progress、blocked。组件（area）：与 CODEOWNERS 对齐。

用 GitHub CLI 批量创建标签体系：

# 批量创建类型标签
gh label create "type:bug"          --color "d73a4a" --repo org/repo
gh label create "type:enhancement"  --color "a2eeef" --repo org/repo
gh label create "type:documentation"--color "0075ca" --repo org/repo
gh label create "type:security"     --color "e4e669" --repo org/repo

# 批量创建优先级标签
gh label create "priority:P0" --color "b60205" --repo org/repo
gh label create "priority:P1" --color "d93f0b" --repo org/repo
gh label create "priority:P2" --color "fbca04" --repo org/repo
gh label create "priority:P3" --color "0e8a16" --repo org/repo

# 批量打标签（对已有 issue）
gh issue edit 1234 --add-label "type:bug,priority:P1,area:checkout" --repo org/repo

# 批量查找并打标签（需要 jq）
gh issue list --label "needs-triage" --json number \
  | jq '.[].number' \
  | xargs -I{} gh issue edit {} --add-label "priority:P2"

分类决策树——严重度判断条件（可嵌入 issue 模板）：

# 严重度判断伪代码（在 SKILL 中固化为规则）
def classify_severity(issue):
    if issue.affects_payment or issue.affects_auth:
        if issue.no_workaround and issue.affects_all_users:
            return "P0"  # 核心交易全量不可用
        elif issue.affects_majority:
            return "P1"  # 核心路径严重降级 > 20% 用户
    if issue.has_workaround:
        return "P2"      # 有变通方案或非主路径
    if issue.is_enhancement or issue.affects_edge_case:
        return "P3"      # 改进项/边缘场景
    return "P2"          # 默认兜底

• 平台/环境标签：os:windows、browser:safari、region:cn 等与复现相关的维度单独成标签，便于筛选。
• 客户/租户级问题：若有合同分级，用标签或自定义字段反映，以便 SLA 规则引擎匹配。

SLA 与响应目标

下表为示例矩阵，请在 SKILL 中替换为你们组织的真实数值（工作日/7×24、时区与节假日规则写清楚）。

周期性分类会议 Agenda 模板（建议每周一次，30 分钟）：

# Issue Triage 周会 Agenda（每周二 10:00，30min）

## 1. 新建工单扫描（10min）
- 查看上周新增未分类 issue：
  gh issue list --label "needs-triage" --limit 20
- 每单确认：type / priority / area / 信息完整性

## 2. P0/P1 状态更新（5min）
- 确认所有 P0/P1 issue 有 assignee 且本周有更新
- 超 SLA 未响应的升级或关闭

## 3. Stale issue 处理（5min）
- 查看 "needs-info" 超 14 天无回复的工单
  gh issue list --label "status:needs-info" --state open
- 决定：追问 / 关闭 / 降级

## 4. 回归 & 阻塞发布清单（5min）
- 确认带 "regression" 标签的 issue 是否影响当前 release
- 与 release captain 同步

## 5. Action items（5min）
- 记录跟进人与截止日期

分流主路径

  [ 新建 Issue / 同步外部工单 ]
        │
        ▼
  ┌─────────────┐     读标题与描述：是否安全类 → 转私密渠道
  │  类型与安全   │──── 否则：bug / enhancement / docs / support
  └─────────────┘
        │
        ▼
  ┌─────────────┐     影响面：用户比例、数据风险、收入/合规
  │  优先级 P0–P3 │──── 对照 SKILL 矩阵与当前事件（如正在发布）
  └─────────────┘
        │
        ▼
  ┌─────────────┐     area 标签 + 队列 / CODEOWNERS / on-call 表
  │  路由与指派   │──── 跨团队：拆子任务或标明依赖方
  └─────────────┘
        │
        ▼
  ┌─────────────┐     缺复现、版本、日志 → 生成追问清单
  │  信息完整性   │──── 足够则：可开发 / 待复现验证
  └─────────────┘

合并、回归与机器人

• 组件标签与代码所有者或 on-call 轮值表对齐；更名时批量迁移旧标签以免报表断裂。
• 回归：用标签或里程碑标明是否阻断发布、是否仅主分支；与 CI 失败单区分，避免同一红构建开多单。
• 机器人：写明自动关闭（如 stale）的前置条件、豁免标签，以及「需要作者反馈」超过 N 天未回复时的升级或关闭策略。

Stale Bot 配置示例（.github/stale.yml）：

# .github/stale.yml
daysUntilStale: 30        # 30 天无活动 → 打 stale 标签
daysUntilClose: 14        # stale 后 14 天无回复 → 关闭
staleLabel: "stale"
exemptLabels:             # 以下标签永不 stale
  - "priority:P0"
  - "priority:P1"
  - "pinned"
  - "security"
staleIssueMessage: |
  此 issue 已超过 30 天无活动。
  若仍相关，请回复并附上最新环境信息，否则将在 14 天后自动关闭。
closeIssueMessage: |
  因长时间无活动，此 issue 已自动关闭。
  若问题依然存在，欢迎重新提交并附上完整复现步骤。
# PR 单独配置（更宽松）
daysUntilStalePr: 60
daysUntilClosePr: 30
stalePrMessage: "此 PR 已超过 60 天无活动，请更新或关闭。"

分类草稿生成

选择类型、优先级与待补信息，生成本页专用的 YAML 草稿，可粘贴到 issue 描述或内部工单模板（字段名请按你们系统调整）。