Thank you for your explanation. At least, let's have a try. On Thu, Jul 9, 2020 at 9:03 PM JUN GAO <[email protected]> wrote:
> It`s a good idea. I agree with you. > > Yichao Yang <[email protected]> 于2020年7月8日周三 下午8:05写道： > > > 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;"丅①秒╮濄呿"<[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;"丅①秒╮濄呿"<[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 > > > > -- > > DolphinScheduler(Incubator) PPMC > Jun Gao 高俊 > [email protected] >
