loading up the forgejo repo on tangled to test page performance
Document our new labeling strategy (#27523)
+12
-9
+12
-9
CONTRIBUTING.md
+12
-9
CONTRIBUTING.md
···
225
225
226
226
### Labels
227
227
228
-
Every PR should be labeled correctly with every label that applies. \
229
-
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)). \
230
-
Furthermore,
228
+
Almost all labels used inside Gitea can be classified as one of the following:
229
+
230
+
- `modifies/…`: Determines which parts of the codebase are affected. These labels will be set through the CI.
231
+
- `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.
232
+
- `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).
233
+
- `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`
234
+
235
+
Every PR should be labeled correctly with every label that applies.
236
+
237
+
There are also some labels that will be managed automatically.\
238
+
In particular, these are
231
239
232
240
- the amount of pending required approvals
233
-
- whether this PR is `blocked`, a `backport` or `breaking`
234
-
- if it targets the `ui` or `api`
235
-
- if it increases the application `speed`
236
-
- reduces `memory usage`
237
-
238
-
are oftentimes notable labels.
241
+
- has all `backport`s or needs a manual backport
239
242
240
243
### Breaking PRs
241
244