Skip to content

馃洜 Issue Triage Process#7603

Description

@jpobst

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions