Skip to content

议题 Issue

每一个开发者都不可能在开发代码时考虑到以下情况:

  • 程序可执行的所有平台, 不同的平台程序执行或许会有所差异, 比如臭名昭著的windows系统的路径分割采用\符号, 而Mac OS和linux采用/符号

  • 程序未来的使用场景, 也许一个程序在诞生之初是为了帮你完成某个工作, 但更多的用户需求驱使你扩展出更多的功能或者更好的交互体验, 比如手机和电脑系统的持续迭代, 游戏版本的持续更新

以上的两种情景可以概括出程序开发生命周期中的两大元素, BUG和新功能.

那如何给一个项目提出bug和新功能呢, 这就是我们本章节所要谈论的主角: issue.

开始创建一个issue

issue可以说是连接开发者和使用者之间的桥梁.

首先你得产生一个问题, 比如程序缺少你想要的功能, 比如你在使用中遇到了一个bug.

其次, 把你的问题清楚地描述出来, 指明这是一个bug报告还是提出新的功能. 如果是报告BUG并尽可能地详细描述你的bug产生步骤和环境. 这一点在issue的整个生命周期是最重要的, 清楚地描述问题能够节省程序开发者的大量时间, 问题也就更加容易解决.

提交, 并等待开发者的回复, 也许你等不到, 如果等不到或者issue直接被关闭, 你应该反思一下你有没有做到人家的要求?

issue的提交模板

有的项目的作者, 为了防呆, 会给你一些提bug或者功能的模板, 在创建时请留意是否有issue模板.

如果你是项目的开发者, 你也可以编写自己的模板, 在项目的根目录下新增一个文件夹.github(.github文件夹用于存放github相关的内容, github会读取这个文件夹里面的内容, 比如issue模板, 比如工作流), 然后在.github文件夹下创建一个子文件夹叫ISSUE_TEMPLATE, 最后在ISSUE_TEMPLATE文件夹下添加各种md文件格式的模板文件. 添加完成之后尝试新增一个issue, 你会发现模板列表.

issue的状态

一些关注度比较高的仓库或者流行的仓库, 可能会有成千上万个issue, 要让开发者一个个去看显然是不现实的, 因此issue的状态就变得至关重要, 它将决定issue的优先级.

新功能和bug之间显然是bug的优先级更高, 文档补充也比新功能优先级更高, 如果某个功能issue是一个里程碑(milestone), 那么它的优先级显然比普通的功能issue高.

你可以在创建issue时在右侧指定它的label, 所属的里程碑, 也可以在编辑时更改. 如果你是仓库管理员, 也可以在issues的列表勾选来批量更改issue的状态.

MIT Licensed