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
+62Lines changed: 62 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,6 +97,68 @@ Templates should promote a high contribution quality by referring [contributing
97
97
98
98
## Label
99
99
100
+
We believe GitHub labels should define immutable informations about issues.
101
+
102
+
We consider having to change labels over time to be a bad practice. Indeed, changing labels manually multiple times on issues can be very time consumming and prone to errors. Moreover, we believe that if the information about the issue is changing, it is surely not a relevant information to have as a label. Almost everytime, you will see that variable informations about an issue can be managed in another way which will be much more efficient in the end. If you consider this, you will tremendously reduce useless labels creation, and see that you have more than enough information through it.
103
+
104
+
We believe that labels should be regrouped into categories and that you only need three of them. We also recommend to use similar color styling accross categories for a stronger visual identification.
105
+
Here are what we believe to be the best labels to use and what they mean.
106
+
We recommend to use the label name, color hex code as they are and use the rest as the description.
107
+
108
+
### Type
109
+
110
+
Type labels should be used to define the type of task done inside the issue.
111
+
112
+
-`Type: Feature`**#00cc41**
113
+
The issue is the development of a new feature of your project.
114
+
115
+
-`Type: Bug`**#ff0000**
116
+
The issue is an identified bug that needs to be fixed.
117
+
118
+
-`Type: Enhancement`**#ffe700**
119
+
The issue is a suggestion of enhancement to your project.
120
+
121
+
-`Type: Documentation`**#c3b2ef**
122
+
The issue is the creation or refinement of a document.
123
+
124
+
### Severity
125
+
126
+
Severity labels are mostly used for bug-related issues. It allows to identify the critical aspects of the work implied inside the issue.
127
+
128
+
-`Severity: Blocker`**#ff0000**
129
+
The issue is blocking an impending release.
130
+
131
+
-`Severity: Critical`**#ff4000**
132
+
The issue causes data loss, crashes or hangs salt processes, makes the system unresponsive, etc.
133
+
134
+
-`Severity: High`**#ff8100**
135
+
The issue reports incorrect functionality, bad functionality, a confusing user experience, etc.
136
+
137
+
-`Severity: Strong`**#ffe700**
138
+
The issue concerns changes to the core areas of the project.
139
+
140
+
-`Severity: Medium`**#00cc41**
141
+
The issue reports cosmetic items, formatting, spelling, colors, etc.
142
+
143
+
-`Severity: Low`**#c3b2ef**
144
+
The issue concerns a new feature or any addition to the project.
145
+
146
+
### Type of change
147
+
148
+
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.
149
+
150
+
-`Change: Minor`**#c3b2ef**
151
+
Less than 64 lines changed, or less than 8 core lines changed.
152
+
153
+
-`Change: Medium`**#00cc41**
154
+
Less than 256 lines changed, or less than 64 core lines changed.
155
+
156
+
-`Change: Master`**#ffe700**
157
+
More than 256 lines changed, or more than 64 core lines changed.
0 commit comments