处理流程

1. 发起人提出Issues,按规范填写内容并保存;
2. 被指定人收到提醒后,设置类型标签,设置状态标签为状态1：已看到;
3. 被指定人进行处理时,设置状态标签为状态2：处理中;
4. 被指定人完成处理后,设置状态标签为状态3：处理完;
5. 发起人确认处理结果,确认完成将状态标签设为状态4：已完成并关闭Issues. 如未完成将状态标签设为状态5：未完成并在评论中@指定人说明原因.

确认处理结果应该根据当时的条件来判断，如果当时的资源不具备或Bug不能复现则应认为被指定人已完成。比如发起人提了一个Bug的issues，但被指定人处理时始终无法复现此Bug，则此issues视为完成。

发起人应将因条件不足而未真正完成的issues中的内容保存到一个新的不设置指定人的issues中以备忘，当条件具备时再将其分配给具体人员。

填写规范

提出Issues时，请规范填写。尤其注意:Title、Description、Assignee的填写选择。

标题（Title）

应指明菜单或模块, 然后加问题概要. 例如：巡线管理>报警管理：列表显示错位。标题文本框前有"Choose a template"下拉框的, 应选择相应模板.

描述（Description）

有模板的, 按模板填写, 不要修改非小括号部分的内容.

应满足下面原则:

1. 资源充分(图标, UI切图等).
2. 功能点明确, 交互逻辑清晰.
3. 任何人一看就能明白, 无需再询问和沟通.

应注意以下事项:

1. 提供的原型或资源必须先添加到文档库中, 然后给出它在文档库中的相对路径. 去除文档库本身的路径后的部分就是相对路径, 比如文档库在你电脑上的路径是 D:/wd , 首页切图的UI资源在文档库中完整路径是 D:/wd/青岛热电厂/01UI/青岛切图/01首页切图, 则你应给出的路径是 青岛热电厂/01UI/青岛切图/01首页切图 . 所有文件都以原始形态放入文档库, 不得压缩.
2. 需求的任何变更发起人都必须修改到Issues的描述和原型中, 始终保持Issues的描述和原型是最新的. 修改完毕后应立即发出评论@被指定人, 告知变更要点. 评论仅作过程记录, 一切以Issues的描述和原型为准!
3. 需求应以文字或原型的方式描述清楚, 尽量做到格式清晰内容简洁明了. 任何视频, 录音及其它文件不作为确认Issues是否完成的依据!

被指定人（Assignee）

新的需求与开发负责人协商确定,或直接选择负责人;

需求变更或发现问题,选择功能原来的指定人。原指定人可以通过搜索查询(Issues页面切换标签到All,然后输入关键字搜索),如原指定人离职则与开发负责人协商确定.

标签（Labels）

被指定人看到issues后应按流程标记类型标签和状态标签. 以状态开头的标签只能选择一个, 修改状态标签时应先去除当前已选的状态标签!

类型标签有: 类型1.发现问题, 类型2.新加功能, 类型3.完善优化, 发起人无需选择.

评论

沟通结果被指定人必须记录在评论中，并注明何时，何人(@此人)，沟通结果。

特别说明

1. 一个Issues只处理一个需求（或问题）！发起人和指定人之间应该保持紧密沟通,并穷尽一切方式及时推进Issue的完成.
2. 被指定人的所有Git源码提交, 必须在提交说明的最前方添加 npp/(工程名称)#(Issues编号) 标记, 将提交的代码与Issues关联起来.
3. 一个Issues被标记为处理完后, 只要满足Issues描述或原型, 即为完成. 如此时有变更, 请用新的Issues提出.