We use GitHub labels on our issues in order to classify them. Whenever they use the same colour it's because they are intended to be used at most once per issue.

When adding a new label talk to repo owners first, we want to keep the number of labels manageable therefore a new label should be added only when it's going to be used broadly.

We have the following mandatory categories per issue. See the triaging guide for rules on how to apply them.

These area-* labels (e.g. area-Runtime: JIT) call out the part of a logical unit of work or an assembly the issue applies to. In addition to labels per unit of code, we have a few other area labels: area-Infrastructure, for issues that relate to our build or test infrastructure, and area-General for issues that deal with the repository itself, our processes, etc.

For large source code areas we have we use hierarchical labels and the most specific area is prefered over general (e.g. area-Runtime: GC instead of area-Runtime).

Each issue has exactly one Area label.

When no Issue Type label is used we assume the issue is a bug and we don't have a special label for it. For the rest, we use the following labels to classify the type of the issue.

• documentation: Issues related to documentation (e.g. incorrect documentation).
• enhancement: Improvements (e.g. performance, functionality, etc.)
• flaky bug: Bugs in the tests or user code which are hard to reproduce.
• question: Questions about the product, source code, etc.
• regression: Functional or performance regression introduced in recent versions.
• test enhancement: Improvements in the tests for a specific part (e.g. improving test coverage).

Each issue has no or exactly one Issue Type label.

Any issue which is platform or architecture specific has one or more of the following labels applied. However, most of the reported issues are general and won't have any of them used.

• os-* labels: Marks issues which are OS specific.
• target-* labels: Used for issues which are specific to a certain target architecture (e.g. target-arm64).

• needs more info: Issues which need more information to be actionable. Usually, this will be because we cannot reproduce the problem. We'll close these issues after a certain period of time if we haven't gotten actionable information. Anyone who has acquired more information is welcomed to reopen the issue.
• good first issue: Small sections of work which we believe are well scoped. These sorts of issues are a good place to start if you are a new to Mono. Anyone is free to work on these issues.

In addition to the above, we have a handful of other labels we use to help classify our issues.