Hi all,

We will wait another day. If there is no new questions or suggestions, we will 
carry out according to this design.


Thx a lot.


Best,
Yichao Yang




------------------ ???????? ------------------
??????:                                                                         
                                               "Yichao Yang"                    
                                                                
<[email protected]&gt;;
????????:&nbsp;2020??7??11??(??????) ????11:37
??????:&nbsp;"Yichao 
Yang"<[email protected]&gt;;"dev"<[email protected]&gt;;

????:&nbsp;Re??[DISCUSS] Issue and Pull Request specifications design



Hi all,


Can we brainstorm some ways to help users fill in the version information when 
creating a bug type issue?



Best,
Yichao Yang




------------------ ???????? ------------------
??????:                                                                         
                                               "Yichao Yang"                    
                                                                
<[email protected]&gt;;
????????:&nbsp;2020??7??7??(??????) ????12:51
??????:&nbsp;"dev"<[email protected]&gt;;
????:&nbsp;"Yichao Yang"<[email protected]&gt;;
????:&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 specification about 
procedure, welcome to put forward them.


[1] 
https://lists.apache.org/thread.html/r6318a7891846aefa3ecbdfc1c59c21d7169692b87c5dba2737871084%40%3Cdev.dolphinscheduler.apache.org%3E


[2] 
https://lists.apache.org/thread.html/r589b62b9cdb8ddcb875b6af8486101c99ff40524638b0d5e6b710ab3%40%3Cdev.dolphinscheduler.apache.org%3E


Best,
Yichao Yang

Reply via email to