Issues 功能被用来追踪各种特性,Bug,功能等。项目维护者可以通过 Issues 来组织需要完成的任务。
Issue 是引出一个 Feature 或 Bug 等的重要步骤,在单个 Issue 中可以讨论的内容包括但不限于 Feature 的包含的功能,存在的 Bug 产生原因,前期方案的调研,以及其对应的实现设计和代码思路。
并且只有当 Issue 被 approve 之后才需要有对应的 Pull Request 去实现。
如果是一个 Issue 对应的是一个大 Feature,建议先将其按照功能模块等维度分成多个小的 Issue。
标题格式:[Issue 类型
][模块名
] Issue 描述
其中Issue 类型
如下:
其中模块名
如下:
https://github.com/apache/dolphinscheduler/tree/dev/.github/ISSUE_TEMPLATE
当您发现一个 Bug 时,请提交一个 Issue 类的 Bug,提交前:
请在 issues 页面中提交 Bug。
一个高质量的 Bug 通常有以下特征:
下面是 Bug 的 Markdown 内容模板,请按照该模板填写 issue。
**标题** 标题格式: [BUG][Priority] bug标题 Priority分为四级: Critical、Major、Minor、Trivial **问题描述** [清晰准确描述遇到的问题] **问题复现步骤:** 1. [第一步] 2. [第二步] 3. [...] **期望的表现:** [在这里描述期望的表现] **观察到的表现:** [在这里描述观察到的表现] **屏幕截图和动态GIF图** ![复现步骤的屏幕截图和动态GIF图](图片的url) **DolphinScheduler版本:(以1.1.0为例)** -[1.1.0] **补充的内容:** [请描述补充的内容,比如] **需求或者建议** [请描述你的需求或者建议]
提交前:
请在 issues 页面中提交 Feature。
一个高质量的 Feature 通常有以下特征:
以下是 Feature 的 Markdown 内容模板,请按照该模板填写 issue 内容。
**标题** 标题格式: [Feature][Priority] feature标题 Priority分为四级: Critical、Major、Minor、Trivial **Feature的描述** [描述新Feature应实现的功能] **为什么这个新功能是对大多数用户有用的** [解释这个功能为什么对大多数用户是有用的] **补充的内容** [列出其他的调度是否包含该功能,是如何实现的]
除一些特殊情况之外,在开始完成 Issue 之前,建议先在 Issue 下或者邮件列表中和大家讨论确定设计方案或者提供设计方案,以及代码实现思路。
如果存在多种不同的方案,建议通过邮件列表或者在 Issue 下进行投票决定,最终方案和代码实现思路被 approve 之后,再去实现,这样做的主要目的是避免在 Pull Request review 阶段针对实现思路的意见不同或需要重构而导致 waste time。
当出现提出 Issue 的用户不清楚该 Issue 对应的模块时的处理方式。
确实存在大多数提出 Issue 用户不清楚这个 Issue 是属于哪个模块的,其实这在很多开源社区都是很常见的。在这种情况下,其实 committer/contributor 是知道这个 Issue 影响的模块的,如果之后这个 Issue 被 committer 和 contributor approve 确实有价值,那么 committer 就可以按照 Issue 涉及到的具体的模块去修改 Issue 标题,或者留言给提出 Issue 的用户去修改成对应的标题。