chore: drop status:ready and improve triage docs

.github/ISSUE_TEMPLATE/administration-only.yml

@@ -1,6 +1,6 @@
 name: Administration only
 description: For administrators only
-labels: ['status:ready', 'priority-3-medium', 'needs-discussion']
+labels: ['priority-3-medium', 'needs-discussion']
 body:
   - type: markdown
     attributes:

docs/development/issue-labeling.md

@@ -34,14 +34,12 @@ Most issues should have a label relating to either a platform, manager, datasour
 
     status:requirements
     status:blocked
-    status:ready
     status:in-progress
 
 </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.
-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
 
@@ -59,7 +57,8 @@ 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.
 
-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.
+All issues should have a `type:*` label.
+Use [this search](https://github.com/renovatebot/renovate/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Atype%3Abug+-label%3Atype%3Afeature+-label%3Atype%3Adocs+-label%3Atype%3Arefactor+) to find issues without a `type:*` label.
 
 Add the `breaking` label for Issues or PRs which have changes that are not backwards compatible and require a major version bump.
 
@@ -113,7 +112,9 @@ Keep in mind that an issue can be both affecting a platform and a self-hosted in
     core:dashboard
     core:git
     core:onboarding
+    core:package-rules
     core:schedule
+    core:vulnerabilities
 
 </details>
 
@@ -167,11 +168,15 @@ Apply these labels when somebody opens a `feature` type issue requesting a new d
     good first issue
     help wanted
     auto:bad-vibes
+    auto:discussion-closed
+    auto:discussion-first
+    auto:format-code
     auto:logs
-    auto:needs-code-formatting
     auto:needs-details
     auto:no-coverage-ignore
+    auto:no-done-comments
     auto:reproduction
+    auto:retry-latest
 
 </details>
 
@@ -196,8 +201,6 @@ Add a label `auto:logs` to indicate that there's a problem with the logs, and th
 1. Provide more logs (in case current logs are insufficient)
 1. Format their logs properly
 
-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.

docs/development/triage-guide.md

@@ -2,7 +2,7 @@
 
 ## What is triage?
 
-Triage is basically filtering the issues/discussions, and categorizing them with the proper labels.
+Triage means filtering the issues/discussions, and categorizing them with the proper labels.
 
 ## Triage workflows
 
@@ -12,25 +12,31 @@ The general triage workflow is similar for bug reports and feature requests, but
 
 Take the following steps on an incoming bug report:
 
-1. Determine if this is a valid issue at all, close and optionally delete obvious spam.
-1. If poster is asking a configuration question, or has not made a convincing case that it's really a bug, then convert to discussion, add either a response or at least a note that it's been converted, and issue can be deleted by an admin.
-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 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.
+1. Determine if this is a valid bug report at all, close and optionally delete obvious spam.
+1. If poster is asking a configuration question, or has not made a convincing case that it's really a bug, then convert to a "Ask a question" discussion, add either a response or at least a note that it's been converted.
+1. Determine if this is a duplicate of an open issue/discussion, if duplicate: link to earlier issue/discussion, apply `duplicate` label and close the issue/discussion.
+1. Check what version of Renovate is used, if not on current major version: apply the `auto:retry-latest` label. This makes a bot comment to try again with a newer version of Renovate.
+1. Check if the _relevant_ logs are provided. If not apply the `auto:logs` label.
 
 ### Triaging feature requests workflow
 
 Take the following steps on an incoming feature request:
 
 1. Determine if this is a valid feature request at all, close and optionally delete obvious spam.
-1. If poster is asking a configuration question, or has not made a convincing case that it's really a feature request, then convert to discussion, add either a response or at least a note that it's been converted, and issue can be deleted by an admin.
-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. If poster is asking a configuration question, or has not made a convincing case that it's really a feature request, then convert to a "Ask a question" discussion, add either a response or at least a note that it's been converted.
+1. Determine if this is a duplicate of an open issue, if duplicate: link to earlier issue/discussion, apply `duplicate` label and close the issue/discussion.
+1. Check what version of Renovate is used, if not on current major version: apply the `auto:retry-latest` label. This makes a bot comment to try again with a newer version of Renovate.
 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 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.
+
+## Creating new issues from discussions
+
+We want _actionable_ issues, so only _maintainers_ (and other approved users) may create them.
+In short: users create discussions, and when it's clear what we need to do, the maintainers create the issue.
+
+### Special labels for issues
+
+- If it's an easy issue for somebody new to Renovate to help us with: apply the `good first issue` label
+- If we need outside help on the issue, apply the `help wanted` label
 
 ## What a triagist is allowed to do
 
@@ -41,7 +47,7 @@ If you've been given triage rights, you are allowed to do the following things:
 - Mark duplicate issues and pull requests
 - Request pull request reviews
 - Lock and unlock discussions
-- Individually convert issues to discussions
+- Individually convert issues to discussions (do _not_ bulk convert issues)
 
 **Note:** We don't use milestones or project boards.
 
@@ -56,7 +62,7 @@ Don't be afraid to ask for help.
 All issues should have labels attached to them.
 Read the [issue-labeling guide](./issue-labeling.md) to get all the necessary info.
 
-In general try to make a good-faith effort to label issues correctly.
+In general, make a good-faith effort to label issues correctly.
 
 ### Closing issues
 
@@ -65,47 +71,52 @@ You can close an issue yourself if it's:
 - Spam
 - Obviously fixed
 
-For really old issues, it's probably a good idea to ask the maintainers to decide if they want to keep or close the issue.
+For really old issues, it's a good idea to ask the maintainers to decide if they want to keep or close the issue.
 
 ### Closing pull requests
 
-It's not very often that you'll need to close a PR, but you can certainly do it in case of spam or malicious content in the PR diff.
+You won't need to close PRs very often, but you can certainly do it in case of spam or malicious content in the PR diff.
 
 ### Reopen issues
 
 Sometimes a bug is fixed with a PR that links to an issue.
 When the PR is merged, the issue is automatically closed.
 Sometimes the bug was not really fixed, and someone says: "Hey this is still broken for me."
-In that case, re-open the issue only if it's definitely the same problem (users often associate different problems together incorrectly).
+In that case, re-open the issue only if it's _definitely_ the same problem (users often associate different problems together incorrectly).
 Otherwise, ask the user to open a new issue if it seems like it is different.
 
 ### Assign issues
 
-You can assign an issue to yourself, so that others know you're going to work on the issue.
-GitHub allows issues to be assigned to any project collaborator or to any non-collaborator who has created or commented on the issue, so you can also assign in either of those cases if it makes sense.
+You can assign an issue to yourself, or to somebody else, so that others know who's going to work on the issue.
+GitHub allows issues to be assigned to:
+
+- any project collaborator, or
+- to any non-collaborator who has _created_ or _commented_ on the issue
+
+You can assign whoever makes sense.
 
 ### Mark duplicate issues and pull requests
 
-If you see an issue that's an obvious duplicate:
+If you see an issue/discussion that's an obvious duplicate:
 
 1. Attach a `duplicate` label
 1. Use the "Duplicate of" functionality [GitHub docs, about duplicate issues and pull requests](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests)
-1. Close the issue
+1. Close the issue/discussion
 
 Follow the same workflow to mark duplicate PRs.
 
 ### Request PR reviews
 
-You can request a review from one of the maintainers, in case this is needed to get the PR review process rolling.
+You can request a review from one of the maintainers, if needed, to get the PR review process rolling (again).
 
 ### Lock and unlock discussions
 
 Sometimes a discussion can go sour, like when people call each other names, or post spam, or veer off-topic.
-Ideally warn the user with an `auto:bad-vibes` label first, and then use `auto:discussion-closed` if problems persist.
+Ideally warn the user with an `auto:bad-vibes` label first, and then use the `auto:discussion-closed` label if problems persist.
 
-### Moving issues from `status:requirements` to `status:ready`
+### Going from `status:requirements` to actionable issue
 
-One of the most important non-code contributions people can do is help features and fixes go from `status:requirements` to `status:ready`.
+One of the most important non-code contributions people can do is help features and fixes go from `status:requirements` to a actionable issue.
 We use the label `status:requirements` to mean "more information or research is needed before someone could start coding this".
 
 It can sometimes be an oversight of the maintainers, but more often it's because there are requirements or edge cases to consider and the user hasn't got an opinion or time to think about them and contribute enough.