我的书签
添加书签
移除书签参与社区 review
贡献 DolphinScheduler 的方式，除了向 团队 中提到的 GitHub 仓库提交 Issues 和 pull requests 外，另一非常重要的方式是 review 社区的 Issues 或者 Pull Requests。通过别人 Issues 和 Pull Requests，你不仅能知道社区的最新进展和发展方向，还能了解别人代码的设 计思想，同时可以增加自己在社区的曝光、积累自己在社区的荣誉值。
任何人都被鼓励去 review 社区的 Issues 和 Pull Requests。我们还曾经发起过一个 Help Wanted 的邮件讨论，向社区征求贡献者协助 review Issues 以及 Pull Requests，详见 邮件，并将其结果放到了 GitHub Discussion 中。
注意: 这里并不是说只有 GitHub Discussion 中提及的用户才可以协助 review Issue 或者 Pull Requests， 请记住社区的主张是 任何人都被鼓励去 review 社区的 Issues 和 Pull Requests。只是那部分用户在邮件列表意见征集的时候，表达了愿意付 出更多的时间，参与社区的 review。另一个好处是，当社区有不确定的问题的时，除了可以找 团队 中对应的 Members 外，还可以找 GitHub Discussion 中提及的人解答对应的问题。如果你要想要加入到 GitHub Discussion 中，请在该 discussion 中评论并留下你感兴趣的模块，维护者会将你加入到对应的名单中。
怎么参与社区 review
DolphinScheduler 主要通过 GitHub 接收社区的贡献，其所有的 Issues 和 Pull Requests 都托管在 GitHub 中，如果你想参与 Issues 的 review 具体请查看 review Issues 章节，如果你是想要参与 Pull Requests 的 review 具体请查看 review Pull Requests 章节。
Issues
Review Issues 是指在 GitHub 中参与 Issues 的讨论，并在对应的 Issues 给出建议。给出的建议包括但不限于如下的情况
| 情况 | 原因 | 需增加标签 | 需要的动作 |
|---|---|---|---|
| 不需要修改 | 问题在 dev 分支最新代码中已经修复了 | wontfix | 关闭 Issue，告知提出者将在那个版本发布，如已发布告知版本 |
| 重复的问题 | 之前已经存在相同的问题 | duplicate | 关闭 Issue，告知提出者相同问题的连接 |
| 问题描述不清晰 | 没有明确说明问题如何复现 | need more information | 提醒用户需要增加缺失的描述 |
除了个 issue 建议之外，给 Issue 分类也是非常重要的一个工作。分类后的 Issue 可以更好的被检索，为以后进一步处理提供便利。一个 Issue 可以被打上多个标签，常见的 Issue 分类有
| 标签 | 标签代表的情况 |
|---|---|
| UI | UI以及前端相关的 Issue |
| security | 安全相关的 Issue |
| user experience | 用户体验相关的 Issue |
| development | 开发者相关的 Issue |
| Python | Python相关的 Issue |
| plug-in | 插件相关的 Issue |
| document | 文档相关的 Issue |
| docker | docker相关的 Issue |
| need verify | Issue 需要被验证 |
| e2e | e2e相关的 Issue |
| win-os | windows 操作系统相关的 Issue |
| suggestion | Issue 为项目提出了建议 |
标签除了分类之外，还能区分 Issue 的优先级，优先级越高的标签越重要，越容易被重视，并会尽快被修复或者实现，优先级的标签如下
| 标签 | 优先级 |
|---|---|
| priority:high | 高优先级 |
| priority:middle | 中优先级 |
| priority:low | 低优先级 |
以上是常见的几个标签，更多的标签请查阅项目全部的标签列表
在阅读以下内容是，请确保你已经为 Issue 打了标签。
- 回复后及时去掉标签Waiting for reply：在 创建 Issue 的时候，我们会为 Issue 打上特定的标签 Waiting for reply，方便定位还没有被回复的 Issue，所以当你 review 了 Issue 之后，就需要将标签 Waiting for reply 及时的从 Issue 中删除。
- 打上 Waiting for review 标当你不确定这个 Issue 是否被解决：当你查阅了 Issue 后，会有两个情况出现。一是 问题已经被定位或解决，如果创建 Pull Requests 的话，则参考 创建PR。二是你也不确定这个问题是否真的是 被解决，这时你可以为 Issue 打上 Waiting for review 标签，并在 Issue 中
@对应的人进行二次确认
当 Issue 需要被创建 Pull Requests 解决，也可以视情况打上部分标签
| 标签 | 标签代表的PR |
|---|---|
| Chore | 日常维护工作 |
| Good first issue | 适合首次贡献者解决的 Issue |
| easy to fix | 比较容易解决 |
| help wanted | 向社区寻求帮忙 |
注意: 上面关于增加和删除标签的操作，目前只有成员可以操作，当你遇到需要增减标签的时候，但是不是成员是，可以
@对应的成员让其帮忙增减。 但只要你有 GitHub 账号就能评论 Issue，并给出建议。我们鼓励社区每人都去评论并为 Issue 给出解答
Pull Requests
Review Pull 是指在 GitHub 中参与 Pull Requests 的讨论，并在对应的 Pull Requests 给出建议。DolphinScheduler review Pull Requests 与 GitHub 的 reviewing changes in pull requests 一样。你可以为 Pull Requests 提出自己的—>
- 当你认为这个 Pull Requests 没有问题，可以被合并的时候，可以根据 GitHub 的 reviewing changes in pull requests 的 approve 流程同意这个 Pull Requests。
- 当你觉得这个 Pull Requests 需要被修改时，可以根据 GitHub 的 reviewing changes in pull requests 的 comment 流程评论这个 Pull Requests。当你认为存在一定要先修复才能合并的问题，请参照 GitHub 的 reviewing changes in pull requests 的 Request changes 流程要求贡献者修改 Pull Requests 的内容。
为 Pull Requests 打上标签也是非常重要的一个环节，合理的分类能为后来的 reviewer 节省大量的时间。值得高兴的是，Pull Requests 的标签和 Issues 中提及的标签和用法是一致的，这能减少 reviewer 对标签的记忆。例如这个 Pull Requests 是和 docker 并且直接影响到用户部署的，我们可以为他 打上 docker 和 priority:high 的标签。
除了和 Issue 类似的标签外，Pull Requests 还有许多自己特有的标签
| 标签 | 含义 |
|---|---|
| miss document | 该 Pull Requests 缺少文档 需要增加 |
| first time contributor | 该 Pull Requests 贡献者是第一次贡献项目 |
| don’t merge | 该 Pull Requests 有问题 暂时先不要合并 |
注意: 上面关于增加和删除标签的操作，目前只有成员可以操作，当你遇到需要增减标签的时候，可以
@对应的成员让其帮忙增减。但只要你有 GitHub 账号就能评论 Pull Requests，并给出建议。我们鼓励社区每人都去评论并为 Pull Requests 给出建议
