总览
问题的提出： 目前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: 大于一周？
