You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dolphinscheduler.apache.org by Yichao Yang <10...@qq.com> on 2020/07/02 02:31:04 UTC
Re：[Discuss]RIP DolphinScheduler Community
Hi,
I agree with you, and I also have some ideas about practice from learning Apache Flink Community Specifications. I will go from the generation of an issue to the completion of the corresponding PR.
1.Issue
I quite agree with you about issue needs to be labeled, and I think we should also pay attention to the information of the issue itself. The user who proposed the issue or the person who answered the issue should help complete the detail of issue's description. Git has provided the relevant information example need to be filled in when proposing an issue.
Bug type: [https://github.com/apache/incubator-dolphinscheduler/issues/new?assignees=&labels=bug&template=bug_report.md&title=%5BBUG%5D+bug+title+]
Feature type: [https://github.com/apache/incubator-dolphinscheduler/issues/new?assignees=&labels=new+feature&template=feature_request.md&title=%5BFeature%5D]
Reason: The detailed issue information will help committer to decide whether the bug is indeed exists or the feature is valuable, and also will help the user quickly locate whether the issue can solve his problem and meet his need.
2.Code
Good code should be of high quality and follow the code style specifications of `style/checkstyle.xml`.
Reason: High quality and standard format code will make subsequent maintenance easier.
3.Test
Test cases should be of high quality, and it will pass after at least one committer reviewed.
Reason: For better robustness of project code and test case code.
4.Commit Message
Commit Message need be filled in as detailed as possible according to the git specifications example of the commit message like below. If the commit message is incomplete, the corresponding contributor should complete it before PR reviewed or merged.
## *Tips*
- *Thanks very much for contributing to Apache DolphinScheduler.*
- *Please review https://dolphinscheduler.apache.org/en-us/community/index.html before opening a pull request.*
## What is the purpose of the pull request
*(For example: This pull request adds checkstyle plugin.)*
## Brief change log
*(for example:)*
- *Add maven-checkstyle-plugin to root pom.xml*
## Verify this pull request
*(Please pick either of the following options)*
This pull request is code cleanup without any test coverage.
*(or)*
This pull request is already covered by existing tests, such as *(please describe tests)*.
(or)
This change added tests and can be verified as follows:
*(example:)*
- *Added dolphinscheduler-dao tests for end-to-end.*
- *Added CronUtilsTest to verify the change.*
- *Manually verified the change by testing locally.*
Reason: It is not convenient for users to query the specific implementation of some features if there are not specific and detailed commit message. At present, although there are relevant git commit message specifications example when creating pull requests, most pull requests still have nonstandard commit messages.
5.Pull Request
Before completing and submitting PR, a corresponding issue which can track the original issue information should be created (roughly divided into feature and bug type).
The first is the PR of the `bugfix type`, which should have at least one committer to confirm that the bug is indeed exist, and then it needs to be assigned to the contributor to complete. When reviewing this PR, the reviewer should consider whether this bugfix implementation is the best from a global perspective, and check if there are any potential bugs in this implementation.
The second is the PR of the `feature type`, which should have at least one or two committers to confirm that the feature is indeed valuable, and then it needs to be assigned to the contributor to complete. The PR should be covered by detailed test cases.
Reason: At present, some submitted PRs have been submitted without linked issues or confirmation from the committer, and if these PRs are confirmed as unnecessary, it may waste committer who are reviewing this PR or some corresponding contributors time.
If my understanding is wrong, please point it out.
Best regards!
Yichao Yang
Re: [Discuss]RIP DolphinScheduler Community
Posted by Kirs <ac...@163.com>.
Very good, in addition, we better add some wrong examples and good cases
| |
Kirs
|
|
邮箱：acm_master@163.com
|
Signature is customized by Netease Mail Master
On 07/02/2020 10:31, Yichao Yang wrote:
Hi,
I agree with you, and I also have some ideas about practice from learning Apache Flink Community Specifications. I will go from the generation of an issue to the completion of the corresponding PR.
1.Issue
I quite agree with you about issue needs to be labeled, and I think we should also pay attention to the information of the issue itself. The user who proposed the issue or the person who answered the issue should help complete the detail of issue's description. Git has provided the relevant information example need to be filled in when proposing an issue.
Bug type: [https://github.com/apache/incubator-dolphinscheduler/issues/new?assignees=&labels=bug&template=bug_report.md&title=%5BBUG%5D+bug+title+]
Feature type: [https://github.com/apache/incubator-dolphinscheduler/issues/new?assignees=&labels=new+feature&template=feature_request.md&title=%5BFeature%5D]
Reason: The detailed issue information will help committer to decide whether the bug is indeed exists or the feature is valuable, and also will help the user quickly locate whether the issue can solve his problem and meet his need.
2.Code
Good code should be of high quality and follow the code style specifications of `style/checkstyle.xml`.
Reason: High quality and standard format code will make subsequent maintenance easier.
3.Test
Test cases should be of high quality, and it will pass after at least one committer reviewed.
Reason: For better robustness of project code and test case code.
4.Commit Message
Commit Message need be filled in as detailed as possible according to the git specifications example of the commit message like below. If the commit message is incomplete, the corresponding contributor should complete it before PR reviewed or merged.
## *Tips*
- *Thanks very much for contributing to Apache DolphinScheduler.*
- *Please review https://dolphinscheduler.apache.org/en-us/community/index.html before opening a pull request.*
## What is the purpose of the pull request
*(For example: This pull request adds checkstyle plugin.)*
## Brief change log
*(for example:)*
- *Add maven-checkstyle-plugin to root pom.xml*
## Verify this pull request
*(Please pick either of the following options)*
This pull request is code cleanup without any test coverage.
*(or)*
This pull request is already covered by existing tests, such as *(please describe tests)*.
(or)
This change added tests and can be verified as follows:
*(example:)*
- *Added dolphinscheduler-dao tests for end-to-end.*
- *Added CronUtilsTest to verify the change.*
- *Manually verified the change by testing locally.*
Reason: It is not convenient for users to query the specific implementation of some features if there are not specific and detailed commit message. At present, although there are relevant git commit message specifications example when creating pull requests, most pull requests still have nonstandard commit messages.
5.Pull Request
Before completing and submitting PR, a corresponding issue which can track the original issue information should be created (roughly divided into feature and bug type).
The first is the PR of the `bugfix type`, which should have at least one committer to confirm that the bug is indeed exist, and then it needs to be assigned to the contributor to complete. When reviewing this PR, the reviewer should consider whether this bugfix implementation is the best from a global perspective, and check if there are any potential bugs in this implementation.
The second is the PR of the `feature type`, which should have at least one or two committers to confirm that the feature is indeed valuable, and then it needs to be assigned to the contributor to complete. The PR should be covered by detailed test cases.
Reason: At present, some submitted PRs have been submitted without linked issues or confirmation from the committer, and if these PRs are confirmed as unnecessary, it may waste committer who are reviewing this PR or some corresponding contributors time.
If my understanding is wrong, please point it out.
Best regards!
Yichao Yang