diff --git "a/\347\254\254\344\270\211\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md" "b/\347\254\254\344\270\211\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md"
index 17afcef00e8845b13339be36240e21f26eab7234..f514993c7cc01cdf9168bf55694e04d684574b1c 100644
--- "a/\347\254\254\344\270\211\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md"
+++ "b/\347\254\254\344\270\211\351\203\250\345\210\206\342\200\224\342\200\224\345\260\235\350\257\225\345\217\202\344\270\216\345\274\200\346\272\220/\346\217\220\344\272\244\347\254\254\344\270\200\344\270\252 Issue.md"
@@ -2,7 +2,7 @@
Issue 的翻译大致为**议题**、**问题**。
-
+
为了方便你理解，我们更愿意把它称之为**待办清单**、**问题或 bug 列表**、**讨论版**等等。相信这些称呼会让你更容易理解什么是 Issue。
@@ -20,20 +20,25 @@ Issue 的翻译大致为**议题**、**问题**。
1. **待办清单 TO DO LIST**
- 比如你要写一本书，共分为八个章节，你选择使用 Gitee 来管理你的书籍电子稿。那么你需要提前想好每一章节的标题，以及每个章节内的每个小节需要写点什么，并列个提纲。此时，你可以将每一个小节想好要写的大致脉络分别提一个 Issue，用来提醒自己未来要做的事情。（这也是这本开源指北的协作方式）完成后，你只需要按照规划，将每一个 Issue 中所提到的编写任务完成，你的云端书籍也就完成啦。
+ 比如你要写一本书，共分为八个章节，你选择使用 Gitee 来管理你的书籍电子稿。那么你需要提前想好每一章节的标题，以及每个章节内的每个小节需要写点什么，并列个提纲。此时，你可以将每一个小节想好要写的大致脉络分别提一个 Issue，用来提醒自己未来要做的事情。（这也是你正在看的这本`开源指北`的协作方式）完成后，你只需要按照规划，将每一个 Issue 中所提到的编写任务完成，你的云端书籍也就完成啦。
2. **问题列表 BUG LIST**
- 一个复杂的项目难免会有这样或那样的 bug，而这些内容被观摩你仓库的朋友们发现之后，可以通过 Issue 给你提出，你可以根据他们指出的复现步骤来定位问题，并最终修复，让你所编写的项目更加健壮而强大。不要害怕自己代码写得很烂，别人提 bug 就是在揭自己的短什么的，因为每发现一个 bug 意味着你的程序又少了一个缺陷，只需要快速修复它即可。当然，你也可以自己发现 bug，并给自己提出 Issue，目的是让自己的项目有充分的留痕，便于后续避免该问题或寻找解决方案等。
+ 一个复杂的项目难免会有这样或那样的 bug，而这些内容被观摩你仓库的朋友们发现之后，可以通过 Issue 给你提出，你可以根据他们指出的复现步骤来定位问题，并最终修复，让你所编写的项目更加健壮而强大。不要害怕自己代码写得很烂，感觉别人提 bug 就是在揭自己的短什么的，因为每发现一个 bug 意味着你的程序又少了一个缺陷，只需要快速修复它即可。当然，你也可以自己发现 bug，并给自己提出 Issue，目的是让自己的项目有充分的留痕，便于后续避免该问题或寻找解决方案。
3. **讨论版 BBS**
- 可以完全将 Issue 模块当做你的仓库的私人论坛、私人社区来使用。围绕你的项目，你可以做如下的事情：比如提出你下一阶段想要添加的功能，请大家集思广益，这样会非常有利于知识和技术的沉淀，即使是当时没有参加讨论的开发者，事后也可以通过该 Issue 了解进行此功能设计的前因后果；比如其他人有事想对作者询问、探讨，或咨询如何使用；比如其他人想要作者添加点新功能，提出来跟作者讨论讨论等等。甚至，你也可以在 Issue 里给广大开发者提跟你的仓库内容完全无关的事情，比如：`求助！女朋友生气了要怎么哄？`
+ 可以完全将 Issue 模块当做你的仓库的私人论坛、私人社区来使用。围绕你的项目，你可以做如下的事情：
+
+ * 提出你下一阶段想要添加的功能，请大家集思广益，这样会非常有利于知识和技术的沉淀，即使是当时没有参加讨论的开发者，事后也可以通过该 Issue 了解进行此功能设计的前因后果。
+ * 其他人有事想对作者询问、探讨，或咨询如何使用
+ * 其他人想要作者添加点新功能，提出来跟作者讨论讨论
+ * 甚至，你也可以在 Issue 里给广大开发者提跟你的仓库内容完全无关的事情，比如：`求助！女朋友生气了要怎么哄？`
-所以，咱们总结下来，可以这么归纳：
+所以，咱们总结下来，可以有如下结论：
-* 对于你自己来说，自己可以使用 Issue 来发布待办清单，给自己提开发任务或 bug，开帖找大家探讨项目下一步的发展方向等等。当然，你也可以用它来提出一些跟仓库内容无关的事情，当然这也是允许的。
-* 如果你想要提 Issue 的仓库不是你自己的，而是他人的的时候，Issue 就是一个很好的协作系统。比如发现了别人项目的 bug 的时候；比如想要别人添加某个新功能的时候；比如有使用上的困难，需要求助作者使用步骤的时候，你都可以给别人的仓库提出 Issue。同时，如果你是一个热心的开发者，你也可以帮助原作者回答一些别人提出的 Issue，这样的行为有时候可以极大地帮助原作者分担压力哦。不要觉得自己是在做临时免费工，解答的过程中你的知识和技术也会得到巩固和提高，有时还能结交到许多志同道合的好朋友哦。我助人，人亦助我。
+* 对于你自己来说，自己可以使用 Issue 来发布待办清单，给自己提开发任务或 bug，开帖找大家探讨项目下一步的发展方向等等。当然，你也可以用它来提出一些跟仓库内容无关的事情，这也是允许的。
+* 如果你想要提 Issue 的仓库不是你自己的，而是他人的的时候，Issue 就是一个很好的多人协作系统。比如发现了别人项目的 bug 的时候；比如想要别人添加某个新功能的时候；比如有使用上的困难，需要求助作者使用步骤的时候，你都可以给别人的仓库提出 Issue。同时，如果你是一个热心的开发者，你也可以帮助原作者回答一些别人提出的 Issue，这样的行为可以极大地帮助原作者分担压力哦。不要觉得自己是在做临时免费工，解答的过程中你的知识和技术也会得到巩固和提高，有时还能结交到许多志同道合的好朋友哦。我助人，人亦助我。
@@ -45,13 +50,13 @@ Issue 的翻译大致为**议题**、**问题**。
#### Issue 的礼仪[2]
-1. 提问使用的语言 ：第一，参照维护者的母语，如果仓库所有者的母语是中文则建议优先母语交流。第二，如果不清楚应该使用什么语言，建议选择英文交流。
-2. 提问态度和语气 ：因为你面对的是跟你一样的开发者，不卑不亢，虚心求教就可以了，不必要太咋呼，措辞太夸张等。但是语气之中要表示对作者的尊重，最好多使用`请`、`谢谢`、`please`、`thanks`等词语。
-3. **如有 Issue 模板，请参照模板写 Issue**。如果原作者定义了 Issue 模板，请按模板来写，避免挤牙膏式的交流。如没有，本文会有比较通用的模板提供给大家。总之，撰写的原则是，把事情表述清楚，便于与原作者进行交流。
+1. 提问使用的语言 ：第一，参照维护者的母语，如果仓库所有者的母语是中文则建议优先中文交流。第二，如果不清楚应该使用什么语言，建议选择英文交流。
+2. 提问态度和语气 ：因为你面对的是跟你一样的开发者，不卑不亢，虚心求教就可以了，不必要太咋呼，措辞太夸张等。但是言语之间要表示对作者的尊重，最好多使用`请`、`谢谢`、`please`、`thanks`等词语。
+3. **如有 Issue 模板，请参照模板写 Issue**。如果原作者定义了 Issue 模板，请按模板来写，避免挤牙膏式的交流。如没有，本文会有比较通用的模板提供给大家。总之，撰写的原则是，把事情表述清楚，便于原作者处理和与你交流。
#### 一个好 Issue 的标准[2]
-1. 避免使用术语或晦涩的文字
+1. 避免使用术语或晦涩的文字，尽量不要堆砌术语即可，不是说禁止使用术语
2. 问题可以切分，也就是说可以逐步解决的问题
3. 尽量跟其他问题没有瓜葛，依赖其它问题会降低处理的灵活性
4. 可以协商，也就说我们有好几种办法达到目标
@@ -84,7 +89,7 @@ Issue 的翻译大致为**议题**、**问题**。
### 报错信息
```
-你可以按照模板来补充 Issue 内容，如果你有更详细的描述，当然也可以扩充模板。如果作者有提供 Issue 模板，请按照作者规定模板提，这样可以方便作者对问题进行后续整理。
+你可以按照模板来补充 Issue 内容，如果你有更详细的描述，当然也可以扩充模板。如果作者有提供 Issue 模板，请按照作者规定的模板提，这样可以方便作者对问题进行后续整理。
> Gitee 在提 Issue 时是支持 Markdown 格式的，它让我们提出的 Issue 能有更加丰富的内容展现。
@@ -96,9 +101,9 @@ Issue 的翻译大致为**议题**、**问题**。
自己创建 Issue 模板，可在仓库中创建`.gitee`目录，并创建对应的模板文件：
-1. `.gitee/ISSUE_TEMPLATE.zh-CN.md`，`Issue` 中文模板
-2. `.gitee/ISSUE_TEMPLATE.en.md`，`Issue` 英文模板
-3. `.gitee/ISSUE_TEMPLATE.zh-TW.md`，`Issue` 繁体模板
+1. `.gitee/ISSUE_TEMPLATE.zh-CN.md`，Issue 中文模板
+2. `.gitee/ISSUE_TEMPLATE.en.md`，Issue 英文模板
+3. `.gitee/ISSUE_TEMPLATE.zh-TW.md`，Issue 繁体模板
> Q: 不同类型的模板，有什么作用？
>
@@ -132,7 +137,7 @@ Issue 的翻译大致为**议题**、**问题**。
---
-有价值：
+**有价值：**
[https://gitee.com/sentsin/layui/issues/I1OFU3](https://gitee.com/sentsin/layui/issues/I1OFU3)
@@ -146,7 +151,7 @@ Issue 的翻译大致为**议题**、**问题**。
-该案例同样的使用了清晰明了的标题表述形式，内容中还具体贴出了自己尝试的代码，便于作者提供帮助或定位问题。属于有价值案例。
+该案例同样使用了清晰明了的标题表述形式，内容中还具体贴出了自己尝试的代码，便于作者提供帮助或定位问题。属于有价值案例。
---
@@ -160,7 +165,7 @@ Issue 的翻译大致为**议题**、**问题**。
### Issue 的进阶使用
-掌握了 Issue 的基础使用之后，作为一个优秀的开发者，我们还应该掌握一些进阶的知识，它能让你压榨干净 Issue 的每一分价值。
+掌握了 Issue 的基础使用之后，作为一个优秀的开发者，我们还可以掌握一些进阶的知识，它能让你压榨干净 Issue 的每一分价值。
#### Issue 的详细设置
@@ -168,7 +173,7 @@ Issue 的翻译大致为**议题**、**问题**。
-* **负责人**：负责人指的是谁来负责处理这个 Issue，可以设置用户为负责人或协作者。对于个人版来说，只能选择自己。如果是组织或者企业，可以指派他人。同一个 Issue 仅能有一个负责人，但问题可能由多个人协作解决，可以添加多个协作者。其它权限是一样的。对于企业版用户来说，设置负责人可以很好地统计任务完成情况（个人版无此功能，因此负责人也可以不设置），如图所示：
+* **负责人**：负责人指的是谁来负责处理这个 Issue，可以设置用户为负责人或协作者。对于个人版来说，只能选择自己。如果是组织或者企业，可以指派他人。同一个 Issue 仅能有一个负责人，但问题可能由多个人协作解决，所以可以添加多个协作者。其它权限是一样的。对于企业版用户来说，设置负责人可以很好地统计任务完成情况（个人版无此功能，因此负责人也可以不设置），如图所示：
@@ -198,10 +203,10 @@ Issue 的翻译大致为**议题**、**问题**。
-* **里程碑**：里程碑是某功能或某个时间段的一堆问题的集合，比如我们要写一本书，一个章节为一个里程碑，而这个章节里面的每一个小节我们就可以分别提多个 Issue，最后将这些 Issue 关联到这个章节的里程碑中，方便管理，可以很容易看到整个章节的完成进度。我们可以根据自己的需要，来使用里程碑的功能。下面是一些使用里程碑功能的例子[1]：
+* **里程碑**：里程碑是某功能或某个时间段的一堆问题的集合。比如我们要写一本书，一个章节如果设置为一个里程碑，那这个章节里面的每一个小节我们就可以分别提多个 Issue，最后将这些 Issue 关联到这个章节的里程碑中，方便管理，可以很容易看到整个章节的完成进度。我们可以根据自己的需要，来使用里程碑的功能。下面是一些使用里程碑功能的例子[1]：
- **发布测试**——在你发布项目的 Beta 版之前，包含你需要修复的 bug 文件相关的 Issue。这样可以确保你不会漏掉什么。
- - **十月冲刺**——记录你再十月份应该做的问题清单。相当于一个工作清单，时刻提醒你应该重点完成哪些工作。（当然，你设定一个九月要做的事情的清单也是可以的）
+ - **十月冲刺**——记录你在十月份应该做的问题清单。相当于一个工作清单，时刻提醒你应该重点完成哪些工作。（当然，你设定一个九月要做的事情的清单也是可以的）
- **重新设计**——记录与重新设计项目的问题清单。这是一种收集灵感的好方法。
> 如何创建自己的里程碑？（所有用户均可创建）
@@ -289,7 +294,7 @@ Gitee 支持的提交方式有（比如我们需要关闭的 Issue 编号为 24
不知道大家是否在 Issue 中有一些任务需要分步骤完成呢？如下面示例的 Issue，可以实现待办清单的功效[4]。可以根据后续的需要，勾选或者取消勾选待办清单中的分项任务，实现 checklist 的效果。
-> 勾选或取消勾选后，重新进入该 Issue，选择的状态依然存在，而且这种操作会保存到该 Issue 的操作日志当中去。修改状态，不再需要重新编辑该 Issue 了。非常方便。
+> 勾选或取消勾选后，刷新页面或者关闭该 Issue 页面重新打开，选择的状态依然存在，而且这种操作会保存到该 Issue 的操作日志当中去。修改状态，不再需要重新编辑该 Issue 了，非常的方便。
@@ -305,7 +310,9 @@ Gitee 支持的提交方式有（比如我们需要关闭的 Issue 编号为 24
* [ ] 吃晚餐
```
-通过`* [x]`来创建已勾选的事项，通过`* [ ]`来创建未勾选的事项即可。请注意，未勾选时，方括号之间会有一个空格，不要漏掉了。
+通过`* [x]`来创建已勾选的事项，通过`* [ ]`来创建未勾选的事项即可。
+
+> 请注意，设置未勾选状态时，方括号之间会有一个空格`[ ]`，不要漏掉了。