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 3f36c9e105ac0adf6c60d151b2103f1faee84aff..56480cbf0f51a7a78fa73639707c56db9627981e 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"
@@ -1,4 +1,149 @@
### 什么是 Issue
+
+Issue 的翻译大致为**议题**、**问题**。
+
+
+
+为了方便你理解，我们更愿意把它称之为**待办清单**、**问题或 bug 列表**、**讨论版**等等。相信这些称呼会让你更容易理解什么是 Issue。
+
+这是一种伟大的协作方式，让你可以更方便的对整个仓库进行跟踪、增强和排错[1]。对于一个公开的仓库来说，Issue 是向所有人开放的，不仅仓库的所有者可以给自己提 Issue，其他人也可以对项目提 Issue。
+
+而根据码云官方的建议，项目相关的技术问题、缺陷报告、建议等信息都可以通过 Issue 进行发布。
+
+
+
### 什么情况下需要提交 Issue
+
+那么什么情况下需要提交 Issue 呢？
+
+常见的 Issue 面板的使用会有以下几种方式：
+
+1. **待办清单 TO DO LIST**
+
+ 比如你要写一本书，共分为八个章节，你选择使用码云来管理你的书籍电子稿。那么你需要提前想好每一章节的标题，以及每个章节内的每个小节需要写点什么，并列个提纲。此时，你可以将每一个小节想好要写的大致脉络分别提一个 Issue，用来提醒自己未来要做的事情。（这也是这本开源指北的协作方式）完成后，你只需要按照规划，将每一个 Issue 中所提到的编写任务完成，你的云端书籍也就完成啦。
+
+2. **问题列表 BUG LIST**
+
+ 一个复杂的项目难免会有这样或那样的 bug，而这些内容被观摩你仓库的朋友们发现之后，可以通过 Issue 给你提出，你可以根据他们指出的复现步骤来定位问题，并最终修复，让你所编写的项目更加健壮而强大。不要害怕自己代码写得很烂，别人提 bug 就是在揭自己的短什么的，因为每发现一个 bug 意味着你的程序又少了一个缺陷，只需要快速修复它即可。当然，你也可以自己发现 bug，并给自己提出 Issue，目的是让自己的项目有充分的留痕，便于后续避免该问题或寻找解决方案等。
+
+3. **讨论版 BBS**
+
+ 可以完全将 Issue 模块当做你的仓库的私人论坛、私人社区来使用。围绕你的项目，你可以做如下的事情：比如提出你下一阶段想要添加的功能，请大家集思广益，这样会非常有利于知识和技术的沉淀，即使是当时没有参加讨论的开发者，事后也可以通过该 Issue 了解进行此功能设计的前因后果；比如其他人有事想对作者询问、探讨，或咨询如何使用；比如其他人想要作者添加点新功能，提出来跟作者讨论讨论等等。甚至，你也可以在 Issue 里给广大开发者提跟你的仓库内容完全无关的事情，比如：`求助！女朋友生气了要怎么哄？`
+
+所以，咱们总结下来，可以这么归纳：
+
+* 对于你自己来说，自己可以使用 Issue 来发布待办清单，给自己提开发任务或 bug，开帖找大家探讨项目下一步的发展方向等等。当然，你也可以用它来提出一些跟仓库内容无关的事情，当然这也是允许的。
+* 如果你想要提 Issue 的仓库不是你自己的，而是他人的的时候，Issue 就是一个很好的协作系统。比如发现了别人项目的 bug 的时候；比如想要别人添加某个新功能的时候；比如有使用上的困难，需要求助作者使用步骤的时候，你都可以给别人的仓库提出 Issue。同时，如果你是一个热心的开发者，你也可以帮助原作者回答一些别人提出的 Issue，这样的行为有时候可以极大地帮助原作者分担压力哦。不要觉得自己是在做临时免费工，解答的过程中你的知识和技术也会得到巩固和提高，有时还能结交到许多志同道合的好朋友哦。我助人，人亦助我。
+
+
+
### 一个好的 Issue 应该写些什么
-### Issue 案例（有价值和无价值）
\ No newline at end of file
+
+那么一个好的 Issue 应该写点什么呢？
+
+这一点对于外部协作者来说尤为重要，因为你要提的 Issue 不是在自己的地盘上，而是需要得到别人的帮助的，所以你尤其要注意 Issue 的礼仪。
+
+#### Issue 的礼仪[2]
+
+1. 提问使用的语言 ：第一，参照维护者的母语，如果仓库所有者的母语是中文则建议优先母语交流。第二，如果不清楚应该使用什么语言，建议选择英文交流。
+2. 提问态度和语气 ：因为你面对的是跟你一样的开发者，不卑不亢，虚心求教就可以了，不必要太咋呼，措辞太夸张等。但是语气之中要表示对作者的尊重，最好多使用`请`、`谢谢`、`please`、`thanks`等词语。
+3. **如有Issue模板，请参照模板写Issue**。如果原作者定义了 Issue 模板，请按模板来写，避免挤牙膏式的交流。如没有，本文会有比较通用的模板提供给大家。总之，撰写的原则是，把事情表述清楚，便于与原作者进行交流。
+
+#### 一个好 Issue 的标准[2]
+
+1. 避免使用术语或晦涩的文字
+2. 问题可以切分，也就是说可以逐步解决的问题
+3. 尽量跟其他问题没有瓜葛，依赖其它问题会降低处理的灵活性
+4. 可以协商，也就说我们有好几种办法达到目标
+5. 问题足够小，可以非常容易的评估出所需时间和资源
+6. 可衡量，我们可以对结果进行测试
+
+> 如果你是仓库的拥有者，你还可以编写一个`CONTRIBUTE.md`文件放在项目中，用来告知其他开发者需要如何参与你的项目。
+
+#### Issue 的标题怎么写？[2]
+
+格式：`[分类、标签或某文件名] + 简短描述`
+
+先使用方括号（也可以使用`【】`替代方括号），里面写上分类、标签或某文件名（比如这个文件有问题待修改），这部分是便于作者进行问题分类的，也方便其他协作者查找（很多人提 Issue 并没有这一部分，建议加上）。然后使用简短的描述，可以让人通过标题快速了解这个 Issue 是讲什么内容的。
+
+案例：`[bug]app.py文件173行运行报错，疑似遗漏一个=号`
+
+#### 提出一个 Issue
+
+咱们先来给一个码云官方通用的模板：
+
+```markdown
+### 该问题是怎么引起的？
+
+
+
+### 重现步骤
+
+
+
+### 报错信息
+```
+
+你可以按照模板来补充 Issue 内容，如果你有更详细的描述，当然也可以扩充模板。如果作者有提供 Issue 模板，请按照作者规定模板提，这样可以方便作者对问题进行后续整理。
+
+> 码云 Gitee 在提 Issue 时是支持 Markdown 格式的，它让我们提出的 Issue 能有更加丰富的内容展现。
+
+当你在敲标题或者 Issue 内容时，项目会自动显示已有的类似 Issue，你可以先查看一下推荐的 Issue 能否解决你的问题，如果不能再提出，避免反复提出同一个问题。
+
+好了，当你完成 Issue 主体内容的填写之后，快去提交给作者吧！
+
+
+
+### Issue 案例（有价值和无价值）
+
+下面我们来看几个 Issue 的案例。
+
+**无价值：**
+
+[https://gitee.com/sentsin/layui/issues/I1SS5Z](https://gitee.com/sentsin/layui/issues/I1SS5Z)
+
+
+
+该案例的标题仅两个字`表格`，作者如果不点进 Issue 的具体内容则无法获知到底这个 Issue 说的是什么。属于无价值案例。
+
+---
+
+[https://gitee.com/sentsin/layui/issues/I1PQVC](https://gitee.com/sentsin/layui/issues/I1PQVC)
+
+
+
+该案例最抓人眼球的应该是那一长串的`!`号，画面都快容不下了，而且作者在看这样的标题的时候也无法获知到底是个什么问题，有一种过分夸张的感觉。属于无价值案例。
+
+---
+
+有价值：
+
+[https://gitee.com/sentsin/layui/issues/I1OFU3](https://gitee.com/sentsin/layui/issues/I1OFU3)
+
+
+
+标题清晰明了，作者可以轻松获知 Issue 的主体内容。内容贴出了自己尝试的代码，便于作者提供帮助。属于有价值案例。
+
+---
+
+[https://gitee.com/sentsin/layui/issues/I1OD1P](https://gitee.com/sentsin/layui/issues/I1OD1P)
+
+
+
+该案例同样的使用了清晰明了的标题表述形式，内容中还具体贴出了自己尝试的代码，便于作者提供帮助或定位问题。属于有价值案例。
+
+---
+
+从上面的几个简单的案例来看，我们发现无价值的案例都有过分夸张、需要表达的观点或内容不清晰等问题。
+
+而有价值的案例，既能在标题中精准反馈某一个点的问题，又能在内容中贴出自己尝试的代码和想法，便于作者提供帮助。
+
+因此，Issue 的精准表述是能获得良好协作的基础，提 Issue 也是一种很好的练习表达的方式。
+
+
+
+### 参考资料
+
+[1] [https://guides.github.com/features/issues/](https://guides.github.com/features/issues/)
+
+[2] [https://zhuanlan.zhihu.com/p/75691927](https://zhuanlan.zhihu.com/p/75691927)
\ No newline at end of file