-
Notifications
You must be signed in to change notification settings - Fork 990
Issues Triaging
Triaging an issue is a multi-step process that is collaboratively performed by the Windows Forms team and our issue bot. The team runs several different triages based on an issue type. For example, the runtime and designer issues are generally triaged on a weekly cadence, and API proposals are triaged on a fortnightly cadence. However, 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 ":mailbox_with_no_mail: waiting-author-feedback" label. The bot is monitoring all issues labeled ":mailbox_with_no_mail: waiting-author-feedback". If we don't receive the needed information within 14 days, the bot will add another label - ":zzz: 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 |
waiting-review | The issue or pull-request is waiting for the team's review |
🪲 bug | The issue is recognized as a bug |
enhancement | Product code improvement that does NOT require public API changes/additions |
help wanted | Good issue for external contributors |
good first issue | Issue should be easy to implement, good for first-time contributors |
ready-to-merge | Pull-request has been reviewed by one of the team members, but expects more reviews from the team |
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. |
Future |
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. |
Help wanted |
This milestone contains issues that do not meet the bar for the team's backlog. However, the team recognizes these issues may generally be useful and would consider community contributions addressing these issues. |
VS release |
Issues with Visual Studio Windows Forms out-of-process designer. |
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" and are assigned to Help wanted
milestone.
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 - ":zzz: no-recent-activity". If another 60 days pass without an assigned volunteer, the bot closes the issue.
- Dependencies
- ARM64