Issue 规范化建议

目的(Objective)

使用 Issue 对软件工程的过程进行记录，对软件工程各种议题进行流程记录，方便复盘和分析统计。

本次不对以下议题进行讨论:

1. 缺陷管理流程
2. 缺陷描述技巧
3. 缺陷解决方法

要求(Requirements)

内容(Content)

必备元素:

1. 问题描述
2. 相关日志

最好有复现的图片、动图或视频

以下是温州二号线 Bug Issue 模版:

## 概要

(简明扼要的描述你遇到的BUG)

## 相关方

(抄送给谁)

## 运行环境描述

(如服务器运行在哪台机器，数据库用的是哪个，分别都是什么操作系统，ip 都是什么)

## 复现步骤

复现概率: 100%

(怎么样让这个问题复现以及概率？ 非常重要！)

## 期待的正确现象是什么?

(该功能正常运行的现象是什么)

## 相关日志、截图

(把相关日志粘贴在这里， 请使用代码块格式(```)来显示命令行输出或日志)

以下是温州二号线 Feature Issue 模版:

## 描述理想的解决方案或功能请求

(对功能进行清晰简洁的描述)

### 难度、影响评估

(实现难度与对目前功能或代码的影响)

### 使用频率评估

(该功能使用频率)

### 需求追踪

(添加更多关于谁提出这个需求，即公司，个人(以及其身份)，他们付给我们多少钱，他们的等级是什么。)

标签(Label)

对项目总结， Issue 大致分为:

1. 缺陷(Bug)
2. 需求(Feature)
3. 其他: 运维(Ops), 问题(Question)

大部分为缺陷。

对于缺陷，我们关注以下几点:

1. 是否是业主上报
2. 是否导致现场功能不可用
3. 是否是实验室人员上报
4. 导致缺陷的原因是什么
5. 导致缺陷的人是谁

对于需求，我们关注以下几点:

1. 是否是必须实现的
2. 是否是业主提出的
3. 是否是内部提出的优化项

所以提议对 Issue 标签(Label)的具体结构进行设计:

• 缺陷

• 来源: 现场

• 来源: 内部

• 缺陷关闭: 逻辑错误

• 缺陷关闭: 环境/操作问题

• 缺陷关闭: 误报

• 缺陷关闭: 无法复现

• 缺陷关闭: 重复

• 缺陷关闭: 其他

• 失误: 研发人员1

• 失误: 研发人员2

• 需求: 必须

• 需求: 优化

1. 来源: 现场: 包括来源为现场实施人员和外部输入（标书、业主人员、总包人员、对接厂商人员）。
2. 标签为需求: xxx或 缺陷 需要标识对应的来源: xxx。
3. 标签为来源: 现场在关闭时，需要标识对应缺陷关闭: xxx。
4. 标签为缺陷关闭: 逻辑错误的，需要标识对应的失误: xxx。

Label 应拥有统一的配色。

• 缺陷(#ff0000)

• 来源: 现场(#ff0000)

• 来源: 内部(#AD4363)

• 缺陷关闭: 逻辑错误(#ff0000)

• 缺陷关闭: 环境/操作问题(#5843AD)

• 缺陷关闭: 误报(#5843AD)

• 缺陷关闭: 无法复现(#5843AD)

• 缺陷关闭: 重复(#5843AD)

• 缺陷关闭: 其他(#5843AD)

• 失误: 研发人员1(#AD8D43)

• 失误: 研发人员2(#AD8D43)

• 需求: 必须(#007FFF)

• 需求: 优化(#44AD8E)

配色效果如下：