Labels and when to use them

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

Labels and when to use them

Release notes

CI

External

Other uses

Contributing

Bindings

Tips & tricks