Datart(数艺) - Github Issue 标签规范化实践

284 阅读2分钟

总览

问题的提出: 目前Datart项目上的标签混乱,同时缺少某些状态,无法很好的反馈给提出问题的人,往往很多时候需要留言说明。

解决问题的原则:

  • 问题首先划分维度,一个问题可以有多个维度标签
  • 同一维度内,不同标签按照一定规则顺序,使用渐变颜色

维度拆分:

  • 状态:Status, Issue过程状态
  • 类别:Category, Bug、Feature 等类别
  • 优先级:Priority, 相对紧急程度
  • 难易程度:Difficulty, 相对修复时间

1.状态标签

  • Investigating: 正在排查,是否是有效的Issue。
  • Invalid: 无效的Issue,不完整的Issue描述。
  • Duplicate: 重复提交的记录。
  • WontFix: 不需要修复的、或不可完成的Issue。
  • NeedClarification: 需要更多信息以帮助分析问题。
  • Discussing: 有些疑问,讨论中。
  • Planning: 正在制定计划。
  • NeedHelp: 需要社区的帮助。
  • Pending: 延期,需要更多的帮助以进行工作。
  • WorkInProgress: 正在修复中 (WIP)。
  • GoodFirstIssue: 鼓励社区人员积极尝试修复的问题。
  • Validating: 需要在Dev/Pre-Release环境中验证是否修复。
flowchart LR
    Z((New Issue)) --> A1[Investigating]
    A1-->A11{A Valid Issue?}
    A11 -- Yes --> A3[Discussing]
    A3 --> A31[Planning]
    A31 --> A41[WorkInProgress]
    A31 --> A42[Pending]
    A31 --> A43[GoodFirstIssue]
    A31 --> A44[NeedHelp]
    A42 --> A41
    A43 --> A41
    A44 --> A41
    A41-->A51[Validating]

    A11 -- No --> B{Need more Info?}
    B -- No ---> B3[Invalid]
    B -- No ---> B4[Duplicate]
    B -- No ---> B5[WontFix]
    B -- Yes --> B2[NeedClarification]
    B2 --> A1

    A51--->Z0((End))

2.类别

  • Bug: 不是业务设计时期望的行为或严重的代码、业务逻辑漏洞。
  • Improvement: 需要改善的功能,能修正最好。
  • NewFeature: 新功能需求。
  • Documentation: 需要更新文档。
  • Calcite: Calcite相关Issue。

3.优先级

P1

P1: Critical 严重级

触发条件 👉:

  • 可复现的程序崩溃
  • 在下一个 Release 之前必须修复的问题

P2

P2: High 高优先级

触发条件 👉:

  • 可复现的问题导致功能不可用
  • 可复现的问题需要尽快修复,但不会导致程序崩溃

P3

P3: Meidum 中优先级

触发条件 👉:

  • 需要被修复,还没有制定修复计划,如果反馈比较多,优先级提升至 P2

P4

P4: Low 低优先级

触发条件 👉:

  • 暂时不会修复,如果反馈比较多,优先级提升至 P3

优先级变更原则

  • 如有兼容方案,则优先级降低。
  • 如果 Bug 产生了很多重复数据,则提升优先级。
  • 如果 Bug 反馈较多,则提升优先级。

4.难易程度

  • Easy: 0-3 天
  • Medium: 3-5 天
  • Hard: 大于一周?

参考

[^1]GitHub Issues: Tagging Best Practices - Save Time!

[^2]如何使用 Issue 管理软件项目?

[^3]Bug Prioritization