Document our new labeling strategy (#27523)

CONTRIBUTING.md

@@ -225,17 +225,20 @@ PRs without a milestone may not be merged.
 
 ### Labels
 
-Every PR should be labeled correctly with every label that applies. \
-This includes especially the distinction between `bug` (fixing existing functionality), `feature` (new functionality), `enhancement` (upgrades for existing functionality), and `refactoring` (improving the internal code structure without changing the output (much)). \
-Furthermore,
+Almost all labels used inside Gitea can be classified as one of the following:
+
+- `modifies/…`: Determines which parts of the codebase are affected. These labels will be set through the CI.
+- `topic/…`:  Determines the conceptual component of Gitea that is affected, i.e. issues, projects, or authentication. At best, PRs should only target one component but there might be overlap. Must be set manually.
+- `type/…`: Determines the type of an issue or PR (feature, refactoring, docs, bug, …). If GitHub supported scoped labels, these labels would be exclusive, so you should set **exactly** one, not more or less (every PR should fall into one of the provided categories, and only one).
+- `issue/…` / `pr/…`: Labels that are specific to issues or PRs respectively and that are only necessary in a given context, i.e. `issue/not-a-bug` or `pr/need-2-approvals`
+
+Every PR should be labeled correctly with every label that applies.
+
+There are also some labels that will be managed automatically.\
+In particular, these are
 
 - the amount of pending required approvals
-- whether this PR is `blocked`, a `backport` or `breaking`
-- if it targets the `ui` or `api`
-- if it increases the application `speed`
-- reduces `memory usage`
-
-are oftentimes notable labels.
+- has all `backport`s or needs a manual backport
 
 ### Breaking PRs