Community Review

Beside submit Issues and pull requests to the GitHub repository mentioned in team, another important way to contribute to DolphinScheduler is reviewing GitHub Issues or Pull Requests. You can not only know the latest new and direction of the community, but also understand the good design in others during you reviewing. At the same time, you can increase your exposure in the community and accumulate your honor.

Anyone is encouraged to review Issues and Pull Requests. We also raise a Help Wanted email discussion to solicit contributors from the community to review them. You could see detail in mail, we put the results of mail thread in GitHub Discussion.

Note: It is only users mentioned in the GitHub Discussion can review Issues or Pull Requests, Community advocates Anyone is encouraged to review Issues and Pull Requests. Users in GitHub Discussion show their willing to review when we collect in the mail thread. The advantage of this list is when the community has discussion, in addition to the mention Members in team, you can also find some help in GitHub Discussion people. If you want to join the GitHub Discussion, please comment in that discussion and leave a module you are interested in, and the maintainer will add you to the list.

How Reviewing

DolphinScheduler receives community contributions through GitHub, and all its Issues and Pull Requests are hosted in GitHub. If you want to join community by reviewing, please go to section review Issues, if you prefer Pull Requests please go to section review Pull Requests.

Issues

Review Issues means discuss Issues in GitHub and give suggestions on it. Include but are not limited to the following situations

Situation	Reason	Label	Action
wont fix	Has been fixed in dev branch	wontfix	Close Issue, inform creator the fixed version if it already release
duplicate issue	Had the same problem before	duplicate	Close issue, inform creator the link of same issue
Description not clearly	Without detail reproduce step	need more information	Inform creator add more description

In addition give suggestion, add label for issue is also important during review. The labeled issues can be retrieved better, which convenient for further processing. An issue can with more than one label. Common issue categories are:

Label	Meaning
UI	UI and front-end related
security	Security Issue
user experience	User experience Issue
development	Development Issue
Python	Python Issue
plug-in	Plug-in Issue
document	Document Issue
docker	Docker Issue
need verify	Need verify Issue
e2e	E2E Issue
win-os	windows operating system Issue
suggestion	Give suggestion to us

Beside classification, label could also set the priority of Issues. The higher the priority, the more attention pay in the community, the easier it is to be fixed or implemented. The priority label are as follows

Label	priority
priority:high	High priority
priority:middle	Middle priority
priority:low	Low priority

All the labels above in common label. For all labels in this project you could see in full label list

Before reading following content, please make sure you have labeled the Issue.

• Remove label Waiting for reply after replying: Label Waiting for reply added when creating an Issue. It makes positioning un reply issue more convenient, and you should remove this label after you reviewed it. If you do not remove it, will cause others to waste time looking on the same issue.
• Mark Waiting for review when not sure whether issue is resolved or not: There are two situations when you review issue. One is the problem has been located or resolved, maybe have to Create PR when necessary. Secondly, you are not sure about this issue, you can labeled Waiting for review and mention others to make a second confirmation.

When an Issue need to create Pull Requests, you could also labeled it from below.

Label	Mean
Chore	Chore for project
Good first issue	Good first issue for new contributor
easy to fix	Easy to fix, harder than Good first issue
help wanted	Help wanted

Note: Only members have permission to add or delete label. When you need to add or remove lebals but are not member, you can @ members to do that. But as long as you have a GitHub account, you can comment on issues and give suggestions. We encourage everyone in the community to comment and answer issues

Pull Requests

Review Pull mean discussing in Pull Requests in GitHub and giving suggestions to it. DolphinScheduler's Pull Requests reviewing are the same as GitHub's reviewing changes in pull requests. You can give your suggestions in Pull Requests

• When you think the Pull Request is OK to be merged, you can agree to the Pull Request according to the “Approve” process in GitHub's reviewing changes in pull requests.
• When you think Pull Request needs to be changed, you can comment it according to the “Comment” process in GitHub's reviewing changes in pull requests. And when you think issues that must be fixed before they merged, please follow “Request changes” in GitHub's reviewing changes in pull requests to ask contributors modify it.

Labeled Pull Requests is an important part. Reasonable classification can save a lot of time for reviewers. The good news is that the label's name and usage of Pull Requests are the same in Issues, which can reduce the memory. For example, if there is a Pull Request is related to docker and block deployment. We can label it with docker and priority:high.

Pull Requests have some unique labels of it own

Label	Mean
miss document	Pull Requests miss document, and should be add
first time contributor	Pull Requests submit by first time contributor
don't merge	Pull Requests have some problem and should not be merged

Note: Only members have permission to add or delete label. When you need to add or remove lebals but are not member, you can @ members to do that. But as long as you have a GitHub account, you can comment on Pull Requests and give suggestions. We encourage everyone in the community to review Pull Requests