回复：[Discuss]RIP DolphinScheduler Community

[Yichao Yang <10...@qq.com>]

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







------------------ 原始邮件 ------------------
发件人:&nbsp;"Kirs"<acm_master@163.com&gt;;
发送时间:&nbsp;2020年7月1日(星期三) 晚上9:41
收件人:&nbsp;"dev"<dev@dolphinscheduler.apache.org&gt;;

主题:&nbsp;[Discuss]RIP DolphinScheduler Community





I read RIP-14 RocketMQ Community Operation Conventions, I think we also need to make such a specification, as follows


1:Test


Standardized testing can reduce the cost of review and quickly find problems to confirm the problem, so the test code link is more important than the code itself to a certain extent. When new code is submitted, we should also care about the quality of the test code.


2:Commit Message


Good commit messages should contain some contextual information. We can get the specific work of the commit from the commit messages, and we can use git instructions to quickly track related issues.


3:Isuess 


Good issues labeling and naming can help us organize existing problems in the community, and can also effectively avoid repeated problems


Label Conventions


ISSUE Label Conventions


Each issue needs to be labeled. Generally, an issue needs to have two types of labels, including


Type
&nbsp; new feature
&nbsp; bug
&nbsp; enhancement
&nbsp; test
&nbsp; code style
&nbsp; doc
&nbsp; question
&nbsp; discuss
&nbsp; wontfix
&nbsp; duplicate
&nbsp; ...
Module
&nbsp;&nbsp; server
&nbsp;&nbsp; remote
&nbsp;&nbsp; service
&nbsp;&nbsp; spi
&nbsp;&nbsp; ...
&nbsp;


4:Pull Request


A good pull request can help the reviewer quickly understand the purpose of the request and improve the efficiency of the reviewer. We should make format requirements for the relevant requests and organize the standard documents.


Related documentation reference：
https://docs.google.com/document/d/1fo_Z4_nUOyykkmQOE2kEmxcLwhhFiQENQwQiy852XUM/edit#heading=h.nwczedg8v2na
Best regards！
CalvinKirs