@@ -142,49 +142,80 @@ Internal APIs:
143## Managing Issues
143## Managing Issues
145−### User Impacting Changes
145+We label the issues in different dimensions based on the lifecyle and different
146−
146+management aspects of the issue. The folowing sections discuss the labels used
147−__RULE__: Any commit that may affect the end user in some way MUST have either a
147+to manage the issues. If a new label is required, it should be discussed before
148−changelog entry OR MUST have an issue marked with one of the following labels
148+creating it.
149−OR both. We can have more than one of these labels on the same issue e.g.
149+
150−breaking, enhancement:
150+### Disposition
152−* breaking
152+The level-1 triaging of the issue determines the current disposition
153−* deprecating
153+of the issue. If no change is required the issue must have one of the
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.
164−### Maintenance Changes
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:
154+following labels:
171* question
157* question
172* discussion
158* discussion
173−* maintenance
159+* duplicate
178−### Feature Labels
162+If a change is required we need to do level-2 triage of the issue, see the
180−For big features with many issues we can introduce a custom feature label to
165+### Change type
181−group the issues together.
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:
185−* help wanted
170+* performance: User visible impact on performance.
186−* duplicate
171+* usability: It is not convenient to use the library.
187−* deferred
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.
179+In addition we can put a __product aspect__ label describing a feature name or
180+any other product specific classification bucket.
182+* aspect:<aspect name>
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:
194+For a user visible issue whether it has a release/changelog impact:
196+* enhancement: includes a new feature or enhancement
197+* breaking: has a breaking impact on existing deployments
198+* deprecating: deprecates an existing functionality
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.
206+By default the issues are normal priority. We use a label for high priority
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:
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
189## Correlating Changes, Issues and Releases
220## Correlating Changes, Issues and Releases