@@ -36,11 +36,13 @@ 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) can identify any which are missing a status label.
Triage is basically filtering the issues/discussions, and categorizing them with the proper labels.
## Triage workflows
The general triage workflow is similar for bug reports and feature requests, but there are some small differences which are documented below.
### Triaging bug reports workflow
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 a 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.
### 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 a 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 a initial judgement of the priority, and add the appropriate 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.
## What a triagist is allowed to do
If you've been given triage rights, you are allowed to do the following things:
...
...
@@ -28,7 +58,7 @@ Don't be afraid to ask for help.
All issues should have labels attached to them.
Read the [issue-labeling guide](https://github.com/renovatebot/renovate/blob/main/docs/development/issue-labeling.md) to get all the necessary info.
In general try to make a good-faith effort to label things correctly.
In general try to make a good-faith effort to label issues correctly.
