issue.md 5.8 KB
Newer Older
1 2 3
# Issue Notice

## Preface
4

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
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:

<table>
    <thead>
        <tr>
            <th style="width: 10%; text-align: center;">Issue Type</th>
            <th style="width: 20%; text-align: center;">Description</th>
            <th style="width: 20%; text-align: center;">Example</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td style="text-align: center;">Feature</td>
33
            <td style="text-align: center;">Include expected features and functions</td>
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132
            <td style="text-align: center;">[Feature][api] Add xxx api in xxx controller</td>
        </tr>
        <tr>
            <td style="text-align: center;">Bug</td>
            <td style="text-align: center;">Bugs in the program</td>
            <td style="text-align: center;">[Bug][api] Throw exception when xxx</td>
        </tr>
        <tr>
            <td style="text-align: center;">Improvement</td>
            <td style="text-align: center;">Some improvements of the current program, not limited to code format, program performance, etc</td>
            <td style="text-align: center;">[Improvement][server] Improve xxx between Master and Worker</td>
        </tr>
        <tr>
            <td style="text-align: center;">Test</td>
            <td style="text-align: center;">Specifically for the test case</td>
            <td style="text-align: center;">[Test][server] Add xxx e2e test</td>
        </tr>
        <tr>
            <td style="text-align: center;">Sub-Task</td>
            <td style="text-align: center;">Those generally are subtasks of feature class. For large features, they can be divided into many small subtasks to complete one by one</td>
            <td style="text-align: center;">[Sub-Task][server] Implement xxx in xxx</td>
        </tr>
    </tbody>
</table>

The `Module Name` is as follows:

<table>
    <thead>
        <tr>
            <th style="width: 10%; text-align: center;">Module Name</th>
            <th style="width: 20%; text-align: center;">Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td style="text-align: center;">alert</td>
            <td style="text-align: center;">Alert module</td>
        </tr>
        <tr>
            <td style="text-align: center;">api</td>
            <td style="text-align: center;">Application program interface layer module</td>
        </tr>
        <tr>
            <td style="text-align: center;">service</td>
            <td style="text-align: center;">Application service layer module</td>
        </tr>
        <tr>
            <td style="text-align: center;">dao</td>
            <td style="text-align: center;">Application data access layer module</td>
        </tr>
        <tr>
            <td style="text-align: center;">plugin</td>
            <td style="text-align: center;">Plugin module</td>
        </tr>
        <tr>
            <td style="text-align: center;">remote</td>
            <td style="text-align: center;">Communication module</td>
        </tr>
        <tr>
            <td style="text-align: center;">server</td>
            <td style="text-align: center;">Server module</td>
        </tr>
        <tr>
            <td style="text-align: center;">ui</td>
            <td style="text-align: center;">Front end module</td>
        </tr>
        <tr>
            <td style="text-align: center;">docs-zh</td>
            <td style="text-align: center;">Chinese document module</td>
        </tr>
        <tr>
            <td style="text-align: center;">docs</td>
            <td style="text-align: center;">English document module</td>
        </tr>
        <tr>
            <td style="text-align: center;">...</td>
            <td style="text-align: center;">-</td>
        </tr>
    </tbody>
</table>

### 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.

133 134 135 136
  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.
137