Skip to content

Issues Triaging

Igor Velikorossov edited this page Aug 23, 2022 · 14 revisions

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.

Requesting Information

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.

Categorizing Issues

Labels

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

Milestones

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.

"Help wanted" issues

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.