议题分类与解决

議題

所有仓库通用的议题分类流程。

分类流程

议题应当被尽快打上标签，显示议题分类及其他必要信息。在项目管理人进行验证并纳入优先级排期之后，应当把议题加入到对应的项目之中。

议题类别

以下为议题的基本类别。每类议题的解决流程见下一章节。

类别	描述
question	普通问题，回答后或者文档更新后即可关闭
bug	功能的实现不正确
feature request	新功能请求
enhancement	优化既有功能与当前性能，包括构架调整等
community	对社区规则及协作流程的讨论和提案

以下标籤用于对议题提供进一步分类及信息。

Type	Description
needs more info	因缺失信息尚不能对议题进行分类
design	缺少设计，或者对当前设计的讨论
under discussion	正在讨论该议题的类别
documentation	需要增加或更新文档
help wanted	值得实现，但是核心团队囿于精力等限制尚未排期
good first issues	适合新人上手解决的问题

议题解决

所有仓库通用的解决流程。

解决流程

决定解决的议题应当被加入到对应的项目之中，以便进度跟进。

feature request

新功能提案需要由项目管理人审阅。

• 如果功能已经在设计与开发之中，项目管理人应当提供对应的文档和资料，并将议题加入到对应的项目之中。
• 如果功能与既有方向和原则相衝突，项目管理人应当提供对应的理由与解释，必要时加入到文档之中，并关闭议题。
• 如果功能没有原则衝突、且尚未进行讨论，议题作者应该在 Matters 上发文讨论、徵询社区意见。如果有贡献者愿意提供设计与开发的协助，或者社区有广泛的支持，项目管理人应当优先排期。需要时可以打上 help wanted 及 design 标签。

bug

Bug 类需要提供复现方式，否则应当打上needs more info标籤。确认bug之后：

• 如果严重，应当加入到项目中进入排期、分配和跟进。
• 如果不严重，同时超过了核心团队的处理能力，应当打上 help wanted 标籤。
• 如果修复方式简单直接，应当打上 good first issues 便于初次参与者上手。
• 如果有贡献者提出 Pull Request，则应当优先审阅与部署。

enhancement

优化类不应有任何功能或者性能上的副作用。

• 如果议题作者或者其他贡献者提出Pull Request，则应当优先审阅与部署。
• 如果议题作者没有提出Pull Request，则由开发团队评估，与其他开发任务统一进行优先级排期。如果优化提案有必要、但超过了核心团队的处理能力，应当打上 help wanted 标籤。

community

社区规则更新需要由项目管理人最终决定。在达成共识之后，应当打上documentation标籤并在补充文档后关闭。

• 如果不涉及新功能决策，应当由开发团队与项目管理人审阅，并在 GitHub 中继续讨论。
• 如果涉及新功能决策，应当由运营团队与项目管理人审阅，并转到 Matters 讨论。