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]
