5.8 KiB
Issue Notice
Preface
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 contents that can be discussed in an issue are not limited to the features, the causes of the existing bugs, the research on preliminary scheme, and the corresponding implementation design and code design.
And only when the Issue is approved, the corresponding Pull Request should be implemented.
If an issue corresponds to a large feature, it is recommended to divide it into multiple small issues according to the functional modules and other dimensions.
Specification
Issue title
Title Format: [Issue Type][Module Name] Issue Description
The Issue Type is as follows:
| Issue Type | Description | Example |
|---|---|---|
| Feature | Include expected features and functions | [Feature][api] Add xxx api in xxx controller |
| Bug | Bugs in the program | [Bug][api] Throw exception when xxx |
| Improvement | Some improvements of the current program, not limited to code format, program performance, etc | [Improvement][server] Improve xxx between Master and Worker |
| Test | Specifically for the test case | [Test][server] Add xxx e2e test |
| Sub-Task | Those 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 Name | Description |
|---|---|
| alert | Alert module |
| api | Application program interface layer module |
| service | Application service layer module |
| dao | Application data access layer module |
| plugin | Plugin module |
| remote | Communication module |
| server | Server module |
| ui | Front end module |
| docs-zh | Chinese document module |
| docs | English document module |
| ... | - |
Issue content template
https://github.com/apache/dolphinscheduler/tree/dev/.github/ISSUE_TEMPLATE
Contributor
Except for some special cases, it is recommended to discuss under issue or mailing list to determine the design scheme or provide the design scheme, as well as the code implementation design before completing the issue.
If there are many different solutions, it is suggested to make a decision through mailing list or voting under issue. The issue can be implemented after final scheme and code implementation design being approved. The main purpose of this is to avoid wasting time caused by different opinions on implementation design or reconstruction in the pull request review stage.
Question
-
How to deal with the user who raises an issue does not know the module corresponding to the issue.
It is true that most users when raising issue do not know which module the issue belongs to. In fact, this is very common in many open source communities. In this case, the committer / contributor actually knows the module affected by the issue. If the issue is really valuable after being approved by committer and contributor, then the committer can modify the issue title according to the specific module involved in the issue, or leave a message to the user who raises the issue to modify it into the corresponding title.