issue（需求类）处理指导.md

### 需求的收集及决策：
- 需求收集责任人：社区开发者随时可以提交需求类issue，对应sig负责需求收集和整理。
- 需求决策组织：sig组需求分析后提交PMC组织需求价值评审和排序，在PMC决策接纳或拒绝需求。

### 需求交付计划制定
- 里程碑制定：release-sig组发布迭代交付里程碑。
- 需求交付计划：所有需求经PMC评审后接纳的需求，需要明确交付计划，每个需求必须指定里程碑点，并按照计划交付。

### 需求分解及依赖管理
原始需求颗粒度不同，需要经过分解形成可以指导开发的需求列表，一个需求如果描述不清楚需要分解到场景清晰、能够验收、质量目标明确（性能、功耗等基础特性）的粒度，需求的分解通过子任务和父任务进行关联关联，所有原始需求作为一级需求，每个原始需求建议分解到一个二级需求（子任务），如果二级需求依然粒度大，可以继续分解，直至能够达成需求描述可以直接指导开发实现的程度，建议最高分解到三级需求（三级子任务）：
- 建议所有原始需求要分解到二级需求。
- 所有最终分解的需求达成场景清晰、可验收、质量目标明确的目标。
- 最小化原则：每个最小粒度需求不跨仓，唯一一个开发者完成。
- 如果需求和其他需求依赖，必须指定需求依赖关系。
- 需求分解需要指定协作者，协作者需要包括测试，安全和资料，协作者负责对应领域的需求评审，所有需求必须经过协作者评审通过。
- 每个需求分解需明确性能、功耗、安全等基础特性对应规格目标。
- 每个需求如果涉及对外接口或对开发者使用有变化，必须分解一个文档类需求。
- 设计方案变更或大粒度需求，要输出设计文档，每个sig组维护一个模块设计文档。
- 原则上禁忌特性需求不能被接纳，确认提交需求是否会造成以下结果：<br>
  1、需求会危害社会安全，如自动攻击网络服务器；<br>
  2、需求会建立文化冲突，造成种族和文化歧视，如识别人的种族；<br>
  3、需求会违反伦理道德，如图像换脸技术；<br>
  4、需求会在用户或设备不知情的情况下收集用户相关信息，并可能未经用户同意将其信息发送给其他实体；<br>
  5、需求是否会降低系统安全防护能力；

### 需求分配
- 每个需求明确责任人。
- 每个需求需预估工作量。
- 开发者认领需求如果出现一次延期，可以申请交付计划变更一次，再次计划延期时间原则上不能超过原计划需求工作量的20%，如果出现再次延期，由sig组有权重新分配责任人或调整交付范围。

  
  ### 需求类issue各字段的要求
- issue状态字段是跟踪管理issue重要的信息，需要在处理issue环节及时更新

|   状态字段 | 负责人  | 描述  |
| ------------ | ------------ | ------------ |
|  待办 | 提交者  | 任何开发者都可以提交需求到社区，初始状态为待办 |
|  已确认 |sig组   |由sig组指定责任人收集需求，并和提交者确认   |
|  已分解 |sig组   |需求经过评审接纳后分解需求，组织需求分配责任人   |
|  设计中 |需求责任人   | 按照设计要求输出设计文档  |
|  开发中 |需求责任人   | 代码开发，本地验证，提交pr到社区，开发完成指定需求回归测试人员  |
|  验收中 |测试   |由测试人员回归验收需求   |
|  已完成 |测试   |经过测试验收后的需求   |
|  已拒绝 |sig组   |经和提交者确认或PMC评审，此需求不接纳   |