Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: review.md

Beside submit Issues and pull requests to the GitHub repository mentioned in , 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 , we put the results of mail thread in . Note: It is only users mentioned in the can review Issues or Pull Requests, Community advocates Anyone is encouraged to review Issues and Pull Requests. Users in 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 , you can also find some help in people. If you want to join the , please comment in that discussion and leave a module you are interested in, and the maintainer will add you to the list. 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 , if you prefer Pull Requests please go to section . Review Issues means discuss 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 | | Close Issue, inform creator the fixed version if it already release | | duplicate issue | Had the same problem before | | Close issue, inform creator the link of same issue | | Description not clearly | Without detail reproduce step | | 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 and front-end related | | | Security Issue | | | User experience Issue | | | Development Issue | | | Python Issue | | | Plug-in Issue | | | Document Issue | | | Docker Issue | | | Need verify Issue | | | E2E Issue | | | windows operating system Issue | | | 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

The priority label are as follows | Label | priority | ||--| | | High priority | | | Middle priority | | | Low priority | All the labels above in common label. For all labels in this project you could see in Before reading following content, please make sure you have labeled the Issue. Remove label after replying: Label added when . 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 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 when necessary. Secondly, you are not sure about this issue, you can labeled 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 for project | | | Good first issue for new contributor | | | Easy to fix, harder than `Good first issue` | | | 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 <!-- markdown-link-check-disable --> Review Pull mean discussing in in GitHub and giving suggestions to it. DolphinScheduler's Pull Requests reviewing are the same as . You can give your suggestions in Pull Reque--> When you think the Pull Request is OK to be merged, you can agree to the Pull Request according to the "Approve" process in . When you think Pull Request needs to be changed, you can comment it according to the "Comment" process in . And when you think issues that must be fixed before they merged, please follow "Request changes" in to ask contributors modify it. <!-- markdown-link-check-enable --> 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 , 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 and . Pull Requests have some unique labels of it own | Label | Mean | |--|-| | | Pull Requests miss document, and should be add | | | Pull Requests submit by first time contributor | | | 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