๐ 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.
- MAUI/Java.Interop/.NET Runtime/BCL: Use GitHub's "Transfer Issue" feature to move the issue to the correct repository.
- AndroidX: Ask the author to refile in xamarin/AndroidX.
- GooglePlayServices: Ask the author to refile in xamarin/GooglePlayServicesComponents.
- Visual Studio IDE/Designer: Ask the author to refile using the tools built in to Visual Studio.
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 exampleArea: App+Library Build
orArea: 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
, orquestion
.
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.