-
Notifications
You must be signed in to change notification settings - Fork 757
Issues Triaging
Triaging an issue is a multi-step process that is collaboratively performed by the several teams working in this codebase and our issue bot. The teams run different triages based on the "area" issue type. Whilst all attempts are made to triage incoming issues and pull-requests as soon as possible, some issues or proposals may take longer to triage, for example, when the feature area owner is not around. Goal of triaging is to set expectation of what will happen to your issue. For example, after your feature request was triaged, you know whether the team plans to tackle the issue, or whether the issue is best tackled by the community.
If an issue lacks information that we need to understand the issue, we assign the "waiting-author-feedback 📭" label. The bot is monitoring all issues labeled "waiting-author-feedback 📭". If we don't receive the needed information within 14 days, the bot will add another label - "no-recent-activity 💤". If another 7 days pass without the feedback, the bot closes the issue.
Labels are used quite extensively in the repo. Some labels represent areas of functionality, some - act as markers of business flows, and some act as indicators to the team and the community about the state of an issue or a pull-request.
For example, the most common labels you likely to encounter:
| Label | Description |
|---|---|
| untriaged | The team is yet to triage the issue |
| waiting-author-feedback 📭 | There is a missing information or there are unanswered questions |
| waiting-on-team | There are questions to or outstanding actions that are waiting for the team's input |
| help wanted | Good issue for external contributors |
| api-suggestion | Early API idea and discussion, it is NOT ready for implementation |
| api-ready-for-review | The proposed API was reviewed by the team, and it is sent to the API Review Board |
| api-approved | API was approved, it can be implemented |
| servicing-consider | The fix is deemed as meeting the servicing requirements, and presented to the servicing committee |
| servicing-approved | The fix is approved by the servicing committee for servicing |
In addition to milestones representing our iterations and releases, we have three milestones with special meaning.
| Milestone | Description |
|---|---|
<Current release milestone>(e.g., 7.0 Preview5) |
Issues that the team is committed to fix in the given milestone. |
<Current release>(e.g., .NET 7.0) |
Issues that the team plans to address in the given release. This commitment is the team's "best attempt", and despite all the best efforts this may not happen. |
Backlog |
The team is in favor of implementing the feature request/fix the issue. However, due to ongoing priorities these aren't expected to be worked on in the current release. |
Despite all the best efforts the team is able to work only on so many issues, which means that some issues do not meet the bar for the team's backlog. If the team feels that an issue may generally be useful, the team would consider community contributions addressing these issues. Such issues are marked as "help wanted".
Any member of the community is welcome to volunteer to work on a fix, and, in this case, the issue will be assigned to the volunteer. If the issue hasn't attracted a volunteer within 120 days, the bot will add another label - "no-recent-activity 💤". If another 60 days pass without an assigned volunteer, the bot closes the issue.