You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+91Lines changed: 91 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,8 +97,99 @@ Templates should promote a high contribution quality by referring [contributing
97
97
98
98
## Label
99
99
100
+
Labels should help contributors and reviewers to evaluate effort for a specific issue or pull request.
101
+
102
+
### Immutablity
103
+
104
+
GitHub labels should define immutable informations about issues, in order to avoid non-updated scenarios. States should be defined in project section.
105
+
106
+
**Preferred:**
107
+
```markdown
108
+
- Type: Feature
109
+
- Severity: Low
110
+
```
111
+
112
+
**Not Preferred:**
113
+
```markdown
114
+
- WorkInProgress
115
+
- Critical
116
+
```
117
+
118
+
### Colors
119
+
120
+
Colors should help contributors and reviewers to quickly and visually identify the effort to be done. It is better to use similar color styling accross categories for a consistent and stronger visual identification. Colors should be variants of Red-Orange-Green to provide a sense of priority. Red being the ones that require the most attention. Green being the ones that require little attention.
Labels should be regrouped into categories to provide consistent information about every issue. Issues cannot have more than one label from the same category.
139
+
140
+
**Preferred:**
141
+
```markdown
142
+
- Type: Documentation
143
+
- Severity: Medium
144
+
- Change: Minor
145
+
```
146
+
147
+
**Not Preferred:**
148
+
```markdown
149
+
- Question
150
+
- Feature
151
+
- Documentation
152
+
```
153
+
154
+
*Pro tip:* GitHub orders labels aphabetically, so following this format allows to keep categories dislayed in the same order accross every issues.
155
+
156
+
#### Type
157
+
158
+
Type labels should be used to define the type of task done inside the issue:
159
+
160
+
- (**#00cc41**) `Type: Feature`: The issue is the development of a new feature of your project
161
+
- (**#ff0000**) `Type: Bug`: The issue is an identified bug that needs to be fixed
162
+
- (**#ffe700**) `Type: Enhancement`: The issue is a suggestion of enhancement to your project
163
+
- (**#c3b2ef**) `Type: Documentation`: The issue is the creation or refinement of a document.
164
+
165
+
#### Severity
166
+
167
+
Severity labels are mostly used for bug-related issues. It allows to identify the critical aspects of the work implied inside the issue:
168
+
169
+
- (**#000000**) `Severity: Blocker`: The issue is blocking an impending release
170
+
- (**#ff4000**) `Severity: Critical`: The issue causes data loss, crashes or hangs salt processes, makes the system unresponsive, etc
171
+
- (**#ff8100**) `Severity: High`: The issue reports incorrect functionality, bad functionality, a confusing user experience, etc
172
+
- (**#ffe700**) `Severity: Strong`: The issue concerns changes to the core areas of the project
- (**#c3b2ef**) `Severity: Low`: The issue concerns a new feature or any addition to the project.
175
+
176
+
#### Type of change
177
+
178
+
Type of change labels are only used for pull requests. They give information about the effort needed to review a pull request:
179
+
180
+
- (**#c3b2ef**) `Change: Minor`: Less than 64 lines changed, or less than 8 core lines changed
181
+
- (**#00cc41**) `Change: Medium`: Less than 256 lines changed, or less than 64 core lines changed
182
+
- (**#ffe700**) `Change: Master`: More than 256 lines changed, or more than 64 core lines changed
0 commit comments