重新定义Issue标签

[Cuiyansong]

总览

问题的提出：
目前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环境中验证是否修复。

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 --> B6[Inactive]
    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: 大于一周？

5.互动

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

参考

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

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

[^3]Bug Prioritization

[nianhua99]

难易程度用easy medium hard来描述更好点，和力扣一样的，small large是描述开发成本的吧

[Cuiyansong]

Ok，Good Idea~

[fuchanghai]

• 给第一次提交的贡献者 打first time contributor 以便于review辅导，第一次提交CI&CD需要PMC手动run，以便于减少资源损耗。
• 需要区分前后端问题的标签。
  我觉得dolphinscheduler 的标签就很好，希望您能参考一下

[Cuiyansong]

• 给第一次提交的贡献者 打first time contributor 以便于review辅导，第一次提交CI&CD需要PMC手动run，以便于减少资源损耗。
• 需要区分前后端问题的标签。
  我觉得dolphinscheduler 的标签就很好，希望您能参考一下

Q1: "First Time Contributor" 这个指的是给PR打标签吧，目前还有计划给PR单独设置Attribute。目前，对于新用户第一次提交的PR无论如何都是需要PMC手动触发的，跟标签没有关系吧？
Q2：内部讨论了一下，由于团队规模和沟通方式的问题，觉得区分前后端标签没有意义，或者您能提供更多的想法。DolphinSchedular的标签那里用的比较好，能说明一下嘛？