【必读】如何正确的提出一个 Issue

[kuitos]

Issue 的作用

Issue 是一种非常好的可沉淀的交流方式，可跟踪，可复现。

我们使用 GitHub Issue 来与社区交流，它有几种应用场景：

答疑交流
反馈缺陷
提交新需求

答疑交流 Usage

• 钉钉群：https://qiankun.umijs.org/#community
• 注意：该群为社区自助交流群，非官方答疑群（官方更倾向基于 Issue 的异步交流方式）

基于 qiankun 团队跟踪方便的考虑，我们适度接受开发者通过 Issue 的方式来提交使用答疑。
但务必请适度控制问题的范畴，避免打扰，具体答疑的 Issue 提交注意事项和规范，参见下一节。

反馈缺陷 Bug

恭喜，发现一个 Bug 意味着我们的应用又少了一个缺陷，快速 Fix 掉即可。

但为了尽可能的减少沟通成本，高效的解决问题，我们期望你能：

首先要仔细阅读：

『如何向开源项目提交无法解答的问题』
『记录一些常见的沟通问题』
《提问的智慧》

然后期望你能提供：复现步骤，错误日志以及相关配置，请务必按照 Issue 模板填写相关条目，避免挤牙膏似交流。

• 最小可复现仓库
• qiankun 版本
• 浏览器版本：
• NodeJs 版本：
• 操作系统：

尤其是第一项『最小可复现仓库』 ，你可以直接 clone qiankun examples 来复现你的问题，然后上传到自己的 github 仓库里。

没有可复现仓库的 issue 我们大概率只能当成无效 issue 处理了，因为不可复现意味着我们不可排查，这种 issue 我们也无能为力。

绝大部分情况下，在这个过程中你就会自己发现问题了，这是一种非常高效的问题定位方式：

如果发现是使用错误，不是 Bug，请及时关闭 issue，并把解决方式同步进来，方便后来人。
如果发现是小问题（文档错别字修改，小的 bug fix），欢迎直接参与进来，直接提 PR 优化。
如果还不能解决，此时直接上传最小可复现仓库到你的 GitHub ，我们会快速跟进。
BTW：学习 Markdown 语法，贴长段代码用三个 ```

提交新需求 Feature Request

整体流程：通过 issue 发起 RFC 提案 -> 讨论定稿-> 提交 Pull Request -> Code Review -> 发布。

这样便于沉淀，即使是当时没有参与讨论的开发者，事后也能通过 issue 了解某个功能设计的前因后果。

它的模板如下：

背景

• 描述你希望解决的问题的现状
• 附上相关的 issue 地址

思路

描述大概的解决思路，可以包含 API 设计和伪代码等

跟进

后续编辑，附上对应的 Pull Request 地址，可以用 - [ ] some task 的方式。
其他约束：

标题：[RFC] some title
标签：type: proposals

最后，感谢您的信任和理解，高效的问题反馈和沟通才能让开源项目变得更健康走的更远🧑‍💻