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
@@ -154,10 +154,101 @@ Emojis should help reviewers to quickly and visually identify the nature of the
154
154
155
155
## Label
156
156
157
+
Labels should help contributors and reviewers to evaluate effort for a specific issue or pull request.
158
+
159
+
### Immutablity
160
+
161
+
GitHub labels should define immutable informations about issues, in order to avoid non-updated scenarios. States should be defined in project section.
162
+
163
+
**Preferred:**
164
+
```markdown
165
+
- Type: Feature
166
+
- Severity: Low
167
+
```
168
+
169
+
**Not Preferred:**
170
+
```markdown
171
+
- WorkInProgress
172
+
- Critical
173
+
```
174
+
175
+
### Colors
176
+
177
+
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.
196
+
197
+
**Preferred:**
198
+
```markdown
199
+
- Type: Documentation
200
+
- Severity: Medium
201
+
- Change: Minor
202
+
```
203
+
204
+
**Not Preferred:**
205
+
```markdown
206
+
- Question
207
+
- Feature
208
+
- Documentation
209
+
```
210
+
211
+
*Pro tip:* GitHub orders labels aphabetically, so following this format allows to keep categories dislayed in the same order accross every issues.
212
+
213
+
#### Type
214
+
215
+
Type labels should be used to define the type of task done inside the issue:
216
+
217
+
- (**#00cc41**) `Type: Feature`: The issue is the development of a new feature of your project
218
+
- (**#ff0000**) `Type: Bug`: The issue is an identified bug that needs to be fixed
219
+
- (**#ffe700**) `Type: Enhancement`: The issue is a suggestion of enhancement to your project
220
+
- (**#c3b2ef**) `Type: Documentation`: The issue is the creation or refinement of a document.
221
+
222
+
#### Severity
223
+
224
+
Severity labels are mostly used for bug-related issues. It allows to identify the critical aspects of the work implied inside the issue:
225
+
226
+
- (**#000000**) `Severity: Blocker`: The issue is blocking an impending release
227
+
- (**#ff4000**) `Severity: Critical`: The issue causes data loss, crashes or hangs salt processes, makes the system unresponsive, etc
228
+
- (**#ff8100**) `Severity: High`: The issue reports incorrect functionality, bad functionality, a confusing user experience, etc
229
+
- (**#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.
232
+
233
+
#### Type of change
234
+
235
+
Type of change labels are only used for pull requests. They give information about the effort needed to review a pull request:
236
+
237
+
- (**#c3b2ef**) `Change: Minor`: Less than 64 lines changed, or less than 8 core lines changed
238
+
- (**#00cc41**) `Change: Medium`: Less than 256 lines changed, or less than 64 core lines changed
239
+
- (**#ffe700**) `Change: Master`: More than 256 lines changed, or more than 64 core lines changed
0 commit comments