|
|
# 处理流程
|
|
# 处理流程
|
|
|
1. 发起人提出Issues,按规范填写内容并保存;
|
|
1. 发起人提出Issues,按规范填写内容并保存;
|
|
|
2. 被指定人收到提醒后,设置状态标签为`我已看到`;
|
|
2. 被指定人收到提醒后,设置状态标签为`状态1：已看到`;
|
|
|
3. 被指定人进行处理时,设置状态标签为`正在处理`.同一时间只应存在一个正在处理的Issue,没有正在处理的应该设为`暂时搁置`.
|
|
3. 被指定人进行处理时,设置状态标签为`状态2：处理中`;
|
|
|
4. 被指定人完成处理后,设置状态标签为`已经解决`;
|
|
4. 被指定人完成处理后,设置状态标签为`状态3：处理完`;
|
|
|
5. 发起人必须及时确认处理结果,确认完成后将状态标签设为`确认解决`并关闭Issues（Close issue）.如果存在问题在评论中说明并@指定人让其继续处理,指定人根据当前情况修改状态标签.对于超过3天没有确认的,开发负责人可以直接关闭.
|
|
5. 发起人确认处理结果,确认完成将状态标签设为`状态4：已完成`并关闭Issues. 如未完成将状态标签设为`状态5：未完成`并在评论中@指定人说明原因.
|
|
|
|
|
|
|
|
# 填写规范
|
|
# 填写规范
|
|
|
提出Issues时，请规范填写。尤其注意:Title、Description、Assignee、Labels的填写。
|
|
提出Issues时，请规范填写。尤其注意:Title、Description、Assignee、Labels的填写。
|
| ... | @@ -22,17 +22,11 @@ |
... | @@ -22,17 +22,11 @@ |
|
|
需求变更或发现问题,选择功能原来的指定人。原指定人可以通过搜索查询(Issues页面切换标签到All,然后输入关键字搜索),如原指定人离职则与开发负责人协商确定.
|
|
需求变更或发现问题,选择功能原来的指定人。原指定人可以通过搜索查询(Issues页面切换标签到All,然后输入关键字搜索),如原指定人离职则与开发负责人协商确定.
|
|
|
|
|
|
|
|
## 标签（Labels）
|
|
## 标签（Labels）
|
|
|
分为类型标签和状态标签两种类型，**一个Issues在同一时间只应分别存在一个类型标签和状态标签**!
|
|
分为类型标签和状态标签两种类型，以**状态**开头的就是状态标签, 一个Issues在同一时间只应存在状态标签, 修改状态标签时请先去除其它已选状态标签!
|
|
|
|
|
|
|
|
### 类型标签
|
|
|
|
|
新的需求、变更需求、发现问题
|
|
|
|
|
|
|
|
|
|
### 状态标签
|
|
|
|
|
我已看到、暂时搁置、正在处理、已经解决、确认解决、不予处理
|
|
|
|
|
|
|
|
|
|
# 特别说明
|
|
# 特别说明
|
|
|
一个Issue只处理一个需求（或问题）！发起人和指定人之间应该保持紧密沟通,并穷尽一切方式及时推进Issue的完成.
|
|
一个Issue只处理一个需求（或问题）！发起人和指定人之间应该保持紧密沟通,并穷尽一切方式及时推进Issue的完成.
|
|
|
|
|
|
|
|
>>>
|
|
>>>
|
|
|
需求沟通采取QQ项目群或邮件方式(抄送负责人)。**沟通结果指定人必须记录在相应Issue的评论中**，并注明何时，何人(@相关人员)，沟通结果。指定人所有针对Issue的Git提交必须在提交说明的最前方添加`#问题数字编号`的标记,将提交的代码与Issues关联起来.
|
|
**沟通结果指定人必须记录在相应Issue的评论中**，并注明何时，何人(@相关人员)，沟通结果。指定人的所有针对Issue的Git提交必须在提交说明的最前方添加`#问题数字编号`的标记,将提交的代码与Issues关联起来.
|
|
|
>>> |
|
>>> |
|
|
|
\ No newline at end of file |
