Issue 规范化建议
Issue 规范化建议
目的(Objective)
使用 Issue 对软件工程的过程进行记录，对软件工程各种议题进行流程记录，方便复盘和分析统计。
本次不对以下议题进行讨论:
- 缺陷管理流程
- 缺陷描述技巧
- 缺陷解决方法
要求(Requirements)
内容(Content)
必备元素:
- 问题描述
- 相关日志
最好有复现的图片、动图或视频
以下是温州二号线 Bug Issue 模版:
## 概要
(简明扼要的描述你遇到的BUG)
## 相关方
(抄送给谁)
## 运行环境描述
(如服务器运行在哪台机器，数据库用的是哪个，分别都是什么操作系统，ip 都是什么)
## 复现步骤
复现概率: 100%
(怎么样让这个问题复现以及概率？ 非常重要！)
## 期待的正确现象是什么?
(该功能正常运行的现象是什么)
## 相关日志、截图
(把相关日志粘贴在这里， 请使用代码块格式(```)来显示命令行输出或日志)
以下是温州二号线 Feature Issue 模版:
## 描述理想的解决方案或功能请求
(对功能进行清晰简洁的描述)
### 难度、影响评估
(实现难度与对目前功能或代码的影响)
### 使用频率评估
(该功能使用频率)
### 需求追踪
(添加更多关于谁提出这个需求，即公司，个人(以及其身份)，他们付给我们多少钱，他们的等级是什么。)
标签(Label)
对项目总结， Issue 大致分为:
- 缺陷(Bug)
- 需求(Feature)
- 其他: 运维(Ops), 问题(Question)
大部分为缺陷。
对于缺陷，我们关注以下几点:
- 是否是业主上报
- 是否导致现场功能不可用
- 是否是实验室人员上报
- 导致缺陷的原因是什么
- 导致缺陷的人是谁
对于需求，我们关注以下几点:
- 是否是必须实现的
- 是否是业主提出的
- 是否是内部提出的优化项
所以提议对 Issue 标签(Label)的具体结构进行设计:
-
缺陷
- 来源: 现场
-
来源: 内部
- 缺陷关闭: 逻辑错误
- 缺陷关闭: 环境/操作问题
- 缺陷关闭: 误报
- 缺陷关闭: 无法复现
- 缺陷关闭: 重复
-
缺陷关闭: 其他
- 失误: 研发人员1
-
失误: 研发人员2
- 需求: 必须
- 需求: 优化
来源: 现场: 包括来源为现场实施人员和外部输入（标书、业主人员、总包人员、对接厂商人员）。- 标签为
需求: xxx或缺陷需要标识对应的来源: xxx。 - 标签为
来源: 现场在关闭时，需要标识对应缺陷关闭: xxx。 - 标签为
缺陷关闭: 逻辑错误的，需要标识对应的失误: xxx。
Label 应拥有统一的配色。
-
缺陷(#ff0000)
- 来源: 现场(#ff0000)
-
来源: 内部(#AD4363)
- 缺陷关闭: 逻辑错误(#ff0000)
- 缺陷关闭: 环境/操作问题(#5843AD)
- 缺陷关闭: 误报(#5843AD)
- 缺陷关闭: 无法复现(#5843AD)
- 缺陷关闭: 重复(#5843AD)
-
缺陷关闭: 其他(#5843AD)
- 失误: 研发人员1(#AD8D43)
-
失误: 研发人员2(#AD8D43)
- 需求: 必须(#007FFF)
- 需求: 优化(#44AD8E)
配色效果如下：
