The software does something that it is not supposed to do. Generally, no documentation changes are required since the documentation should describe what the software is supposed to do.

The Issue describes behavior that only occurs with debug builds of the software.

The Issue only requires changes to the user documentation, and not the software.

The Issue is a duplicate of another Issue and therefore closed. Unless there is more detail, in a later Issue, or a later Issue is more accurate, the later Issue should be marked as a duplicate of the earlier Issue.

The Issue describes new functionality for the software. Typically, the Issue will also have the Needs Documentation label, unless the change is simple or obvious, and not typically documented.

The Issue is not valid. If it results from a misunderstanding of the user documentation, consider whether the Issue should describe an improvement to the user documentation with the Issue tagged as Documentation.

The software does what the developer intended it to do, but that behavior is not what user wants, i.e., the user sees it as a bug, and the developer sees it as a feature. If there is an associated change in the user documentation, the Needs Documentation label should also be set.

There are no changes to functionality, and the changes affect performance, either development/testing, or in use.

This is a secondary label to the Technical label, and used to tag issues that only affect CI pipelines

This is a secondary label, typically to an Enhancement or Misfeature label, and indicates that this change requires changes to the user documentation.

The Issue is a big one, and is broken down into a list of smaller issues.

The Issue primarily affects the development/testing process, with no user visible changes.

The Issue is technically correct (e.g., describing a Bug), but we don't plan to fix it (because of the risk of introducing new bugs, because it is an esoteric edge case, etc.).