# 总览

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

解决问题的原则：

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

维度拆分：

• 状态：Status, Issue 过程状态
• 类别：Category, Bug、Feature 等类别
• 优先级：Priority, 相对紧急程度
• 难易程度：Difficulty, 相对修复时间
• 交互：Interaction, 与社区的互动标签

# 1.状态标签

• Investigating: 正在排查，是否是有效的 Issue。
• Invalid: 无效的 Issue，不完整的 Issue 描述。
• Inactive: 过期或者长时间无反馈的 Issue，即将关闭。
• Duplicate: 重复提交的记录。
• WontFix: 不需要修复的、或不可完成的 Issue。
• NeedClarification: 需要更多信息以帮助分析问题。
• Discussing: 有些疑问，讨论中。
• Planning: 正在制定计划。
• VolunteerWanted: 需要社区的帮助。
• Pending: 延期，需要更多的帮助以进行工作。
• WorkInProgress: 正在修复中 (WIP)。
• GoodFirstIssue: 鼓励社区人员积极尝试修复的问题。
• Validating: 需要在 Dev/Pre-Release 环境中验证是否修复。

# 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: 大于一周？

# 5.互动

• 🔥Heat: 代表社区关注度高
• 👏Good Idea: 赞扬鼓励问题的提出者

# 参考

[^1]GitHub Issues: Tagging Best Practices - Save Time! (opens new window)

[^2]如何使用 Issue 管理软件项目？ (opens new window)

[^3]Bug Prioritization (opens new window)