dotnet/android

๐Ÿ›  Issue Triage Process

Closed this issue ยท 0 comments

Quick Queries

Pre-Triage

The first step of triage is to get an issue to its correct team or owner (or closer to the correct location if you don't know exactly where it goes).

For issues that belong in dotnet/android this generally just means changing the assignee to the correct person.

For issues that belong to other teams it can be a little messier.

While asking the author to refile isn't an ideal scenario, it is not possible to move issues to other organizations, and issues for other teams left in our repository are rarely resolved.

Triage

The goal of triage is to quickly assess a new issue and make a few classifications about it to help determine next steps.

  • Area: Issues should be assigned an Area: * label to help group it with related issues, for example Area: App+Library Build or Area: App Runtime.
    • If an area is getting too big, consider breaking it down into multiple areas.
  • Milestone: Issues that are obvious priorities should be placed in the upcoming .NET milestone, like .NET 9. Issues that will likely need to be backported to released versions should be assigned a servicing milestone, like .NET 8 Servicing.
  • Type: If it is immediately obvious, add a label for the type of request, like bug, enhancement, or question.

If more information is needed from the author to perform triage, use the needs-info label. If the author does not respond after 7 days, the issue will be automatically closed.

Once triage has been performed, remove the needs-triage label from the issue.