Hi,
Thanks a lot for your ideas and opinions. Your opinions are very valuable. I will try to answer this two questions according to the Apache Flink community practice I have investigated before. For the first point, it is true that most users who propose an issue do not know which module the issue belongs to. In fact, this is very common in many open source communities. However, the committer / contributor knows the module affected by the issue. If the issue is really valuable after being approved by the committer or the contributor, then the committer can modify the issue title according to the specific module involved in the issue (I understand that perhaps the committer have the authority to modify the issue title) Or leave a message to the user who raised the issue to modify it to the corresponding title. For example, if a user puts forward an issue, and the title is like [add worker XXX feature], and then committers discuss the issue and approve that the feature is valuable, then the committer can modify the title to [feature] [server] add worker XXX, or leave a message to the issue proposer to modify it. For the second point, maybe we should take a PR as the minimum granularity. The relationship between PR and issue should be one-to-one. Referring to the GitHub pull request page of Apache Flink, we can see that every PR is linked to an issue. Moreover, if a PR only does one thing, the contributor will be easier to complete, the scope of PR influence will be clearer, and the pressure on the reviewer will be less. So avoid the situation that one PR is associated with multiple issues maybe better. I don't know whether the above answer can solve the problem. If anyone have any questions or different opinions, please put them forward. If there are no different opinions in the above answers, I will put the above two situations into the specification document. ------------------------------------ ?????????????????????????????????????????????????????? Apache Flink Community ???????????????????????????????????????? ???????????????????????????????? issue ?????????????? issue ?????????????????????????????????????????????????????????????????????? commiter/contributor ?????????? issue ?????????????????????????? issue ?? commiter ???? contributor approve ???????????????? commiter ?????????????? issue ???????????????????????? issue ???????????? committer ???????????????? issue ?????????????????????????????????????????????? issue ?????????????????????????? ?????????????????????????????? issue???????????????? add worker xxx feature???????????????? issue ?????????????????? feature ???????????? commiter ???????????????? [Feature][server] Add worker xxx???????????????? issue ?????????????????????????????????????????????? ?????????????????????? pr ??????????????pr ?? issue ???????????????????????? Apache Flink ?? Github Pull Request ???????????????????? pr ?????????????? issue?????????????? pr ????????????contributor ??????????pr ?????????????????????????? reviewer ??????????????????????????????pr???????? issue ???????????????????????? ?????????????????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????????????????????????? ------------------ Original ------------------ From: Jave-Chen <[email protected]> Date: Tue,Jul 7,2020 11:05 PM To: dev <[email protected]> Subject: Re: [DISCUSS] Issue and Pull Request specifications design Hi, here are some of my opinions: 1. For Issues On one hand, Since&nbsp;Everyone is free to create issues, It may be a little unrealistic&nbsp; to create issues according to the issue specification. On the other hand, when creating an issue, many people do not know which module&nbsp; it belong to. 2. For PR A PR may be associated with multiple issues, so writing Issue No. in PR titile may&nbsp; not be suitable. ------------------&nbsp;????????&nbsp;------------------ ??????:&nbsp;"xingchun.chen"<[email protected]&gt;; ????????:&nbsp;2020??7??7??(??????) ????3:08 ??????:&nbsp;"dev"<[email protected]&gt;; ????:&nbsp;"?B?????r????"<[email protected]&gt;; ????:&nbsp;??????[DISCUSS] Issue and Pull Request specifications design It's very good! The title format of this issue and pr is indeed standardized I think that in order to facilitate the testing of pr, it is very good to add the influence range of the code submitted by the pr, and the reviewer can also add the missing influence range after viewing the code. ------------------&amp;nbsp;????????&amp;nbsp;------------------ ??????:&amp;nbsp;"Yichao Yang"<[email protected]&amp;gt;; ????????:&amp;nbsp;2020??7??7??(??????) ????12:51 ??????:&amp;nbsp;"dev"<[email protected]&amp;gt;; ????:&amp;nbsp;"?B?????r????"<[email protected]&amp;gt;; ????:&amp;nbsp;[DISCUSS] Issue and Pull Request specifications design Hi all, I refer to `Issue` and `Pull Request` specifications of the Apache Flink Community and @CalvinKirs Documents [1] and [2], and I think we also need some specifications for `Issue` and `Pull Request` to help us avoid unnecessary communication and improve efficiency. 1.Issue a.Brief introduction to Issue Issues function is used to track various Features, Bugs, Functions, etc. The project maintainer can organize the tasks to be completed through issues. Issue is an important step in drawing out a feature or bug, and the discussion in Issue is not only about how to implement the feature and how to fix the bug but also the way the feature should/could be implemented. And only when the Issue is approved, the corresponding Pull Request should be implemented. b.Issue title [`Issue Type`][`Module Name`] `Issue Description` The `Issue Type` is as follows: Issue TypeDescriptionExample Feature Include expected new features and functions [Feature][api] Add xxx api in xxx controller BugBugs in the program [BUG][api] Throw exception when xxx ImprovementSome improvements of the current program, not limited to code format, program performance, etc [Improvement][server] Improve xxx between Master and Worker TestSpecifically for the test case [Test][server] Add xxx e2e test Sub-TaskThose generally are subtasks of feature class. For large features, they can be divided into many small subtasks to complete one by one[Sub-Task][server] Implement xxx in xxx The `Module Name` is as follows: Module NameDescription alert Alert module apiApplication program interface layer module serviceApplication service layer module daoApplication data access layer module pluginPlugin module remoteCommunication module serverServer module uiFront end module ...- 2.Pull Request a.Brief introduction to Pull Request Pull Request is a way of software cooperation, which is a process of bringing code involving different functions into the trunk. During this process, the code can be discussed, reviewed, and modified. In Pull Request, we try not to discuss the implementation of the code. The general implementation of the code and its logic should be determined in Issue. In the Pull Request, we only focus on the code format and code specification, so as to avoid wasting time caused by different opinions on implementation. b.Pull Request title There are quite a few communities using the following approach: [`Open Source Project Name`-`Issue No`][`Module Name`] `Pull Request Description`, but the length of DolphinScheduler is relatively long, so I suggest use the following description: [`Pull Request Type`-`Issue No`][`Module Name`] `Pull Request Description` The corresponding relationship between `Pull Request Type` and `Issue Type` is as follows: Issue TypePull Request TypeExample(Suppose Issue No is 3333) Feature Feature [Feature-3333][server] Implement xxx Bug Hotfix [Hotfix-3333][server] Fix xxx Improvement Improvement [Improvement-3333][alert] Improve the performance of xxx Test Test [Test-3333][api] Add the e2e test of xxx Sub-Task(Parent type corresponding to Sub-Task)[Feature-3333][server] Implement xxx `Issue No` refers to the Issue number corresponding to the current Pull Request to be resolved, `Module Name` is the same as the `Module Name` of Issue. I only put forward the specification design of title, if you have any better suggestions about Issue title, Pull Request title or some&amp;amp;nbsp;specification about&amp;amp;nbsp;procedure, welcome to put forward them. [1]&amp;amp;nbsp;https://lists.apache.org/thread.html/r6318a7891846aefa3ecbdfc1c59c21d7169692b87c5dba2737871084%40%3Cdev.dolphinscheduler.apache.org%3E [2]&amp;amp;nbsp;https://lists.apache.org/thread.html/r589b62b9cdb8ddcb875b6af8486101c99ff40524638b0d5e6b710ab3%40%3Cdev.dolphinscheduler.apache.org%3E Best, Yichao Yang
