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
@@ -99,213 +99,120 @@ Templates should promote a high contribution quality by referring [contributing
99
99
100
100
### Immutablity
101
101
102
-
GitHub labels should define immutable informations about issues. States should be defined in project section.
103
-
104
-
*Why*
105
-
>To avoid non-updated scenarios.
106
-
107
-
#### Examples
108
-
109
-
<details>
110
-
<summary>Excelsior Approved</summary>
102
+
GitHub labels should define immutable informations about issues, in order to avoid non-updating scenarios. States should be defined in project section.
111
103
104
+
**Preferred:**
112
105
```markdown
113
106
- type
114
107
- severity
115
108
```
116
109
117
-
</details>
118
-
<details>
119
-
<summary>Not Recommended</summary>
120
-
110
+
**Not Preferred:**
121
111
```markdown
122
112
- priority
123
113
- status
124
114
```
125
115
126
-
</details>
127
-
128
116
### Colors
129
117
130
-
It is better to use similar color styling accross categories for a stronger visual identification. Colors should be variants of Red-Orange-Green to provide a sense of state. Red being the ones that require the most attention. Green being the ones that require little attention.
131
-
132
-
*Why*
133
-
>Red-Orange-Green variations are commonly used internationally to provide a sense of state. Keeping same color styling accross categories is key for a strong and clear visual identification.
134
-
135
-
#### Excelsior Format
118
+
Colors should be variants of Red-Orange-Green to provide a sense of state. It is better to use similar color styling accross categories for a stronger visual identification. Red being the ones that require the most attention. Green being the ones that require little attention.
Labels should help reviewers to quickly get information about the reviewing effort. Labels should be regrouped into categories. Issues cannot have more than one label from the same category.
195
-
196
-
*Why*
197
-
>To provide the consistent information for every issue.
198
-
199
-
#### Excelsior Format
200
-
201
-
```markdown
202
-
-`Caterogy: Type`
203
-
```
204
-
205
-
#### Examples
206
-
207
-
<details>
208
-
<summary>Excelsior Approved</summary>
140
+
Labels should help reviewers to quickly get information about the reviewing effort. Labels should be categorized to provide the same amount of information for each issue. Issues cannot have more than one label from the same category.
209
141
142
+
**Preferred:**
210
143
```markdown
211
144
-`Severity: Low`
212
-
```
213
-
```markdown
214
145
-`Severity: Medium`
215
-
```
216
-
```markdown
217
146
-`Severity: Critical`
218
-
```
219
-
```markdown
220
147
-`Change: Minor`
221
-
```
222
-
```markdown
223
148
-`Change: Medium`
224
-
```
225
-
```markdown
226
149
-`Change: Master`
227
150
```
228
151
229
-
</details>
230
-
<details>
231
-
<summary>Not Recommended</summary>
232
-
152
+
**Not Preferred:**
233
153
```markdown
234
154
-`Low`
235
-
```
236
-
```markdown
237
155
-`Medium`
238
-
```
239
-
```markdown
240
156
-`Critical`
241
-
```
242
-
```markdown
243
157
-`Blocked`
244
-
```
245
-
```markdown
246
158
-`Feature`
247
-
```
248
-
```markdown
249
159
-`WorkInProgress`
250
160
```
251
161
252
-
</details>
253
-
254
-
255
162
*Pro tip:* GitHub orders labels aphabetically, so following this format allows to keep categories dislayed in the same order accross every issues.
256
163
257
-
#### Type Category
164
+
#### Type
258
165
259
166
Type labels should be used to define the type of task done inside the issue.
The issue concerns a new feature or any addition to the project.
294
201
295
-
#### Type Of Change Category
202
+
#### Type of change
296
203
297
204
Type of change labels are only used for pull requests. They give information about the effort needed to review a pull request. We strongly recommend to define core areas to help define the estimated effort.
0 commit comments