Labels and when to use them

Labels and when to use them

List of all the labels.

Release notes

In order to make it easier to create release notes, all pull requests must have at least one of these labels:

• bug: the pull request fixes a bug, and should be shown in the list of fixed bugs in the release notes.
• enhancement: the pull request is a significant enhancement of some kind, and worth mentioning in the release notes.
• breaking-change: the pull request is a breaking change that should be mentioned in the release notes.
• community: the pull request is a community contribution, and should be listed in the release notes as such.
• note-deprecation: a deprecation worth mentioning in the release notes. Typically there's a specific "Deprecated" section where these pull requests should be.
• note-infrastructure: use this for infrastructure work that's worth mentioning in the release notes
• note-mention: the release notes should mention this pull request, but there's no reason to highlight it in any way
• note-highlight: the release notes should show this pull request prominently
• not-notes-worthy: don't mention this pull request at all in the release notes
• regression: the pull request is a bug fix for a regression, and should be shown in the list of fixed bugs in the release notes.

It's possible to use more than one of these labels at the same time (for instance enhancement and note-highlight to make the enhancement highlighted in the release notes).

CI

• build-package: only applicable when building a pull request on internal Jenkins: in which case Jenkins will produce a package (it has no effect on public Jenkins)
• disable-packaged-mono: builds Mono from source instead of using the packaged Mono
• enable-device-build: the public Jenkins build may decide that device support isn't needed (to make the test run faster); this will enable device support (and thus may also run tests that depend on device support). This does not meaning running tests on device, but merely that the tests that build for device might run.
• run-all-tests: runs all the tests. There should usually be other labels as well to disable tests that don't make much sense (this will for instance try to run device tests, even if the bot in question doesn't have devices attached).
• skip-all-tests: don't run any tests at all.
• run-*-tests: runs the specified tests
• run-sample-tests: runs the sample tests (only applicable when building a pull request on internal Jenkins, it has no effect on public Jenkins)
• run-internal-tests: runs the tests for this pull request on internal Jenkins (by default internal Jenkins won't build pull requests; this can modified by setting either the build-package or the run-internal-tests label).
• skip-*-tests: skips the specified tests
• skip-public-jenkins: don't do anything on public Jenkins. This is typically used for pull requests from the origin repository, in which case the private Jenkins may already do a test run, in which case the public Jenkins test run is redundant.
• trigger-device-tests: trigger device tests for pull requests built on private Jenkins.

External

There are a few areas where issues may be filed in our repository, but other teams own:

• external-designer: issues for the designer
• external-live-run: issues for the live run team
• external-objective-sharpie: issues related to ObjectiveSharpie
• external-visual-studio-for-mac: issues for the VSMac team
• external-xamarin-vs: issues for the XVS team
• external-xsdk: issues for the XSDK team
• mobcat: issues for the mobcat team

Other uses

• do-not-merge: do not merge this pull request
• documentation: this is an issue related to documentation
• dotnet: this is an issue/pull request related to the .NET 6 effort
• generator: this is an issue/pull request related to the generator
• good first issue: this issue is a good first issue
• help wanted: help wanted with this issue or pull request; we will probably not spend time on it
• high-priority: this issue or pull request is high priority
• iOS: this issue affects Xamarin.iOS (includes tvOS and watchOS)
• macOS: this issue affects Xamarin.Mac
• low-priority: this is a low-priority issue/pull request
• msbuild: this is an issue/pull request related to the MSBuild code
• need-info: this issue does not have enough info to act upon
• needs-babysitting-🍼: this pull request needs constant vigilance because it needs to be merged as soon as possible
• networking: this issue or pull request is related to networking
• not-regression: this issue is not a regression
• performance: this issue or pull request is related to performance
• pr-change-not-shipping: this pull request does not change any shipping code. This label is important when approval is needed to merge the pull request, because approving a pull request that does not change what we ship is much easier.
• pr-need-sample: the pull request is missing a sample
• question: this issue is a question from a customer
• regression: this issue is a regression
• request-for-comments: this issue or pull request is a request for comments (a draft PR is usually more appropriate for pull requests)
• requires-approval-before-merge: the pull requests must be approved because the target branch is frozen
• support: this issue is a customer who needs support
• test-only-issue: this issue only affects our tests
• vs-sync: assign this label to create a mirror issue in Azure DevOps (a link to the mirror issue will be added to the issue description)
• xharness: this issue only affects xharness
• xtro: this issue only affects the xtro tests
• qa-ci-failure: not used anymore
• requires-qa-before-merge: not used anymore