diff --git a/docs/development/issue-labeling.md b/docs/development/issue-labeling.md
index 4038478ff0bf40fcf0033f10139d7a576565597e..43c0fdfd5e423d9ddbf27a6706ba1d7a860e38c2 100644
--- a/docs/development/issue-labeling.md
+++ b/docs/development/issue-labeling.md
@@ -36,13 +36,11 @@ Most issues should have a label relating to either a platform, manager, datasour
status:blocked
status:ready
status:in-progress
- status:waiting-on-response
</details>
Use these to label the status of an issue.
For example, use `status:requirements` to mean that an issue is not yet ready for development to begin.
-If we need the original poster or somebody else to respond to a query of ours, apply the `status:waiting-on-response` label.
All open issues should have some `status:*` label applied, and [this search](https://github.com/renovatebot/renovate/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Astatus%3Arequirements+-label%3Astatus%3Aready+-label%3Astatus%3Ain-progress+-label%3Astatus%3Ablocked+-label%3Astatus%3Awaiting-on-response+) can find any which are missing a status label.
### Type of issue
@@ -54,14 +52,12 @@ All open issues should have some `status:*` label applied, and [this search](htt
type:docs
type:feature
type:refactor
- type:help
</details>
Use these to label the type of issue.
For example, use `type:bug` to label a bug type issue, and use `type:feature` for feature requests.
Only use `type:refactor` for code changes, don't use `type:refactor` for documentation type changes.
-Use the `type:help` label for issues which should be converted to a discussion post.
Any issue which has the label `status:ready` should also have a `type:*` label, and [this search](https://github.com/renovatebot/renovate/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Atype%3Abug+label%3Astatus%3Aready+-label%3Atype%3Afeature+-label%3Atype%3Adocs+-label%3Atype%3Arefactor+) can find any which are missing one.
@@ -88,22 +84,6 @@ At a high level: critical = needs immediate fix, high = to be prioritized ahead
Use [this search](https://github.com/renovatebot/renovate/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Apriority-1-critical+-label%3Apriority-2-high+-label%3Apriority-3-medium+-label%3Apriority-4-low++-label%3Apriority-5-triage) to find any issues which are missing a priority label.
-### Impact
-
-<details>
- <summary>Impact</summary>
-
- impact:small
- impact:medium
- impact:large
-
-</details>
-
-Use these to assign an impact level to an issue.
-Impact means risk to the end users or their use cases.
-It's used to identify which changes can be made relatively quickly versus those which require great care before merging, due to their chance of negatively impacting a wide number of users if there's a bug.
-It does _not_ mean "amount of work for the maintainers".
-
### Platform
<details>
@@ -188,10 +168,12 @@ Apply these labels when somebody opens a `feature` type issue requesting a new d
duplicate
good first issue
help wanted
- logs:problem
- needs-code-formatting
- reproduction:needed
- reproduction:provided
+ auto:bad-vibes
+ auto:logs
+ auto:needs-code-formatting
+ auto:needs-details
+ auto:no-coverage-ignore
+ auto:reproduction
</details>
@@ -202,16 +184,31 @@ This label is sometimes picked up by tools or websites that try to encourage peo
Add the label `help wanted` to indicate that we need the original poster or someone else to do some work or it is unlikely to get done.
-Add a label `logs:problem` to indicate that there's a problem with the logs, and the contributor needs to do one of these things:
+Add a label `auto:bad-vibes` to any discussion containing rude comments such as excessive criticism or ungratefulness.
+
+Add a label `auto:discussion-closed` to close a discussion which had persistent or very bad vibes.
+
+Add a label `auto:discussion-first` to any PR which needs discussing first.
+
+Add a label `auto:format-code` to any Discussion which needs code formatting.
+
+Add a label `auto:logs` to indicate that there's a problem with the logs, and the contributor needs to do one of these things:
1. Provide logs (if there are none yet)
1. Provide more logs (in case current logs are insufficient)
1. Format their logs properly
-Add a label `needs-code-formatting` to issues with logs/code that needs to be formatted.
+Add a label `auto:needs-code-formatting` to discussions with logs/code that needs to be formatted.
+
+Add a label `auto:needs-details` to discussions which need more details to move forward.
+
+Add a label `auto:no-coverage-ignore` if PR authors avoid needed unit tests by istanbul ignoring code with the `// istanbul ignore` comment.
+
+Add a label `auto:no-done-comments` if PR authors unnecessary "Done" comments, or type comments to ask for a review instead of requesting a new review through GitHub's UI.
+
+Add a label `auto:reproduction` if nobody's reproduced it in a public repo yet and such a reproduction is necessary before further work can be done.
-Add a label `reproduction:needed` if nobody's reproduced it in a public repo yet and such a reproduction is necessary before further work can be done.
-Add the label `reproduction:provided` once there is a public reproduction.
+Add a label `auto:retry-latest` to any Discussion where the user should retry the latest version of Renovate to see if the problem persists.
### Self-hosted
diff --git a/docs/development/triage-guide.md b/docs/development/triage-guide.md
index 3365a9b1758220b65d55765fc8dbc033e27ad172..948b226ecf6831c90311186d41e12f9f0d923b85 100644
--- a/docs/development/triage-guide.md
+++ b/docs/development/triage-guide.md
@@ -17,7 +17,6 @@ Take the following steps on an incoming bug report:
1. Check what version of Renovate is used, if not on current major version then ask the reporter to retry with the latest version of Renovate and report their findings.
1. Determine if this is a duplicate of an open issue, if duplicate: link to earlier issue, apply `duplicate` label and close the issue.
1. Check if the _relevant_ logs are provided. If not apply the `logs:problem` label.
-1. If we need the original poster or somebody else to respond to a query of ours, apply the `status:waiting-on-response` label.
1. If it's an easy issue for somebody new to Renovate to help us with: apply the `good first issue` label.
1. If the issue is hard to fix without outside help apply the `help wanted` label.
@@ -30,7 +29,6 @@ Take the following steps on an incoming feature request:
1. Determine if this is a duplicate of an open issue, if duplicate: link to earlier issue, apply `duplicate` label and close the issue.
1. Make a best-effort judgement if this is a reasonable feature to put into Renovate. If in doubt, let the core maintainers decide.
1. Make an initial judgement of the priority, and add the correct priority label.
-1. If we need the original poster or somebody else to respond to a query of ours, apply the `status:waiting-on-response` label.
1. If it's an easy feature for somebody new to Renovate to help us with: apply the `good first issue` label.
1. If the feature is hard to start work on without outside help apply the `help wanted` label.
@@ -103,13 +101,7 @@ You can request a review from one of the maintainers, in case this is needed to
### Lock and unlock discussions
Sometimes a discussion can go sour, like when people call each other names, or post spam, or veer off-topic.
-In those cases you can lock the discussion to prevent further escalation.
-
-### Individually convert issues to discussions
-
-Sometimes an issue that's raised at the Renovate repository is not really a bug or a feature request.
-This happens most often because a user files a bug for things that are really a mistake in the Renovate configuration.
-Those "configuration help" issues are then moved to the discussions board for further help.
+Ideally warn the user with an `auto:bad-vibes` label first, and then use `auto:discussion-closed` if problems persist.
### Moving issues from `status:requirements` to `status:ready`