@@ -142,49 +142,80 @@ Internal APIs:
142142
143143## Managing Issues
144144
145−### User Impacting Changes
146−
147−__RULE__: Any commit that may affect the end user in some way MUST have either a
148−changelog entry OR MUST have an issue marked with one of the following labels
149−OR both. We can have more than one of these labels on the same issue e.g.
150−breaking, enhancement:
151−
152−* breaking
153−* deprecating
154−* enhancement
155−* performance
156−* usability
157−* documentation
158−* bug
159−
160−Note that if you are making a big feature change you may have a single issue
161−for that feature and attach many commits with it. So you do not necessarily
162−need to have an issue for each commit.
163−
164−### Maintenance Changes
165−
166−Commits that do not impact the end user in any way are not required to have a
167−changelog entry or an issue. Issues that do not have a corresponding commit
168−may be left without a label but preferably should be marked with one of the
169−following:
145+We label the issues in different dimensions based on the lifecyle and different
146+management aspects of the issue. The folowing sections discuss the labels used
147+to manage the issues. If a new label is required, it should be discussed before
148+creating it.
149+
150+### Disposition
151+
152+The level-1 triaging of the issue determines the current disposition
153+of the issue. If no change is required the issue must have one of the
154+following labels:
170155
156+* invalid
171157* question
172158* discussion
173−* maintenance
174−* testing
175−* invalid
159+* duplicate
176160* wontfix
177161
178−### Feature Labels
162+If a change is required we need to do level-2 triage of the issue, see the
163+sections below.
179164
180−For big features with many issues we can introduce a custom feature label to
181−group the issues together.
165+### Change type
182166
183−### Other Labels
167+When a change is required we need to put one of the __change type__
168+labels as part of level-2 triaging:
184169
185−* help wanted
186−* duplicate
187−* deferred
170+* performance: User visible impact on performance.
171+* usability: It is not convenient to use the library.
172+* documentation: documentation is not correct or sufficient.
173+* bug: A functionality issue, not working as expected.
174+* enhancement: A new feature or enhancement of the product.
175+* maintenance: A refactor or any other change with no user visible impact.
176+
177+### Aspect
178+
179+In addition we can put a __product aspect__ label describing a feature name or
180+any other product specific classification bucket.
181+
182+* aspect:<aspect name>
183+
184+### Severity
185+
186+Optionally we can add a severity label to indicate how severe is the
187+impact of the bug/issue, which may determine how important it is to fix it. By
188+default the severity is normal, if it is high we put a label:
189+
190+* severity:high
191+
192+### Change impact
193+
194+For a user visible issue whether it has a release/changelog impact:
195+
196+* enhancement: includes a new feature or enhancement
197+* breaking: has a breaking impact on existing deployments
198+* deprecating: deprecates an existing functionality
199+
200+__RULE__: Any commit that may affect the end user in some way MUST have
201+either a changelog entry OR MUST have an issue marked with one of the
202+above labels OR both.
203+
204+### Priority
205+
206+By default the issues are normal priority. We use a label for high priority
207+issues:
208+
209+* priority:high
210+
211+### Scheduling
212+
213+If the issue is assigned to someone then it is considered scheduled. Otherwise
214+it is unscheduled. Unassigned issues may have the following labels:
215+
216+* deferred: blocked on any other fix or a decision to be made, or deliberately
217+ deferred for some reason.
218+* help-wanted: anyone can take the issue and contribute
188219
189220## Correlating Changes, Issues and Releases
190221