its-gen1/docs/project/DEFECT_MANAGEMENT.md

AI-Box项目Defect管理规范

1. 标签体系设计

1.1 按模块分类

• mcu: MCU软件相关问题
• soc: SoC软件相关问题
• f1-npu: Fellow 1 NPU芯片相关问题
• power-management: 电源管理模块问题
• communication: 通信协议和接口问题

1.2 按类型分类

• bug: 缺陷和错误
• feature: 新功能需求
• enhancement: 功能改进
• documentation: 文档相关

1.3 按严重程度分类

• critical: 系统崩溃、数据丢失等严重问题
• high: 主要功能不可用
• medium: 次要功能问题
• low: 界面优化、文案修正等

1.4 按状态分类

• in-review: 待评审
• in-progress: 开发中
• testing: 测试中
• resolved: 已解决

2. Issue模板

2.1 Defect报告模板

## 问题描述
[简要描述问题]

## 重现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]

## 环境信息
- 硬件平台: H100核心板
- 温度环境: [实际温度]
- 软件版本: [版本号]

## 预期结果
[期望的行为]

## 实际结果  
[实际的行为]

## 附件
[截图、日志等]

2.2 Feature请求模板

## 业务价值
[说明此功能的业务价值]

## 功能描述
[详细功能描述]

## 技术方案
[建议的技术实现方案]

## 验收标准
- [标准1]
- [标准2]
- [标准3]

2.3 任务模板

## 任务描述
[任务详细描述]

## 负责人
[负责人姓名]

## 截止日期
[YYYY-MM-DD]

## 依赖关系
- [依赖任务1]
- [依赖任务2]

## 验收标准
[具体的验收标准]

3. 工作流程规范

3.1 Defect创建和分配流程

1. 任何人发现Defect都可以创建Issue
2. 项目经理根据模块标签分配给相应负责人
3. 负责人确认后更新状态为in-progress

3.2 状态转换规则

• in-review → in-progress: 负责人开始处理
• in-progress → testing: 开发完成，提交代码
• testing → resolved: 测试通过，问题解决

3.3 代码提交关联规范

• 提交信息必须包含Issue编号，格式: fix #123
• 相关代码文件必须有适当的注释说明

3.4 评审和关闭标准

• Critical/High级别Defect必须经过代码评审
• 所有Defect必须有对应的测试用例
• 关闭前必须验证在极端环境(-40℃~85℃)下的稳定性

4. 团队协作要求

4.1 新成员培训

• 入职时必须学习本规范
• 第一个任务必须在导师指导下完成

4.2 日常维护

• 每日站会检查高优先级Defect状态
• 每周清理已解决的Issue
• 每月回顾Defect趋势，优化开发流程

4.3 质量保证

• Critical Defect 24小时内响应
• High Defect 3天内解决
• Medium/Low Defect 在下一个里程碑前解决

---

本规范自发布之日起生效，所有团队成员必须遵守。