| ... | ... | @@ -6,7 +6,11 @@ |
|
|
|
4. 被指定人完成处理后,设置状态标签为`状态3：处理完`;
|
|
|
|
5. 发起人确认处理结果,确认完成将状态标签设为`状态4：已完成`并关闭Issues. 如未完成将状态标签设为`状态5：未完成`并在评论中@指定人说明原因.
|
|
|
|
|
|
|
|
如果被指定人需要发起人进行确认或提供资源的, 应以评论形式@发起人. 如发起人自评论或状态被标记为 `状态3：处理完` 之时起超过7天未响应, 则被指定人可以将此issues的被指定人修改为发起人.
|
|
|
|
>>>
|
|
|
|
确认处理结果应该根据当时的条件来判断，如果当时的资源不具备或Bug不能复现则应认为被指定人已完成。比如发起人提了一个Bug的issues，但被指定人处理时始终无法复现此Bug，则此issues视为完成。
|
|
|
|
|
|
|
|
发起人应将因条件不足而未真正完成的issues中的内容保存到一个新的不设置指定人的issues中以备忘，当条件具备时再将其分配给具体人员。
|
|
|
|
>>>
|
|
|
|
|
|
|
|
# 填写规范
|
|
|
|
|
| ... | ... | @@ -22,10 +26,9 @@ |
|
|
|
|
|
|
|
### 应满足下面原则:
|
|
|
|
|
|
|
|
1. 前置条件具备.
|
|
|
|
2. 列明了所有功能点.
|
|
|
|
3. 附加了所有原型和(或)资源.
|
|
|
|
4. 任何人一看就能明白, 无需再询问和沟通.
|
|
|
|
1. 资源充分(图标, UI切图等).
|
|
|
|
2. 功能点明确, 交互逻辑清晰.
|
|
|
|
3. 任何人一看就能明白, 无需再询问和沟通.
|
|
|
|
|
|
|
|
### 应注意以下事项:
|
|
|
|
|
| ... | ... | |
