We try to keep issues well-classified through use of labels. Any repository collaborator can apply labels according to the below guidelines.
The general idea is that we have:
- manager (
manager:) - versioning (
versioning:) - datasource (
datasource:) - platform (
platform:) - core functionality (
core:)
The majority of issues should have at least one of those labels. These labels should also map approximately to our Conventional Commit scopes.
You should know about platforms, package managers, datasources and versioning to label issues effectively.
- To learn about platforms, read the Renovate docs on Platforms.
- To learn about managers, read the Renovate docs on Managers.
- To learn about datasources, read the Renovate docs on Datasources.
- To learn more about versioning, read the Renovate docs on Versioning.
Most issues should have a label relating to either a platform, manager, datasource, versioning or worker topic.
Status of issue
status:requirements
status:blocked
status:ready
status:in-progress
status:waiting-on-response
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 can identify any which are missing a status label.
Type of issue
type:bug
type:docs
type:feature
type:refactor
type:help
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 can identify any which are missing one.
Add the breaking label for Issues or PRs which contain changes that are not backwards compatible and require a major version bump.
Priority
priority-1-critical
priority-2-important
priority-3-normal
priority-4-low
priority-5-triage
Use these to assign a priority level to an issue.
Incoming issues are labeled priority-5-triage by default, this label should be replaced with a proper priority (low/normal/important/critical).
Make a best-effort attempt to select a proper priority.
Nothing bad will happen if you select a "wrong" priority.
At a high level: critical = needs immediate fix, important = to be prioritized ahead of others, normal = default priority, low = trivial issue, or impacts a very small % of the user base.
Use this search to find any issues which are missing a priority label.
Platform labels
platform:azure
platform:bitbucket
platform:bitbucket-server
platform:gitea
platform:github
platform:gitlab
Use these to mark the platform that is affected by this issue. Keep in mind that an issue can be both affecting a platform and a self hosted instance.
Core labels
core:automerge
core:changelogs
core:dashboard
core:onboarding
core:schedule
The purpose of these labels is to allow browsing of open issues by the most commonly-used functionality, such as automerging or Dependency Dashboard.
"manager" is short for "package manager".
Add the relevant manager: labels to the issue.
If there are multiple managers affected, add labels for all of them.
Use a datasource: label when it is applicable specifically to particular datasources (for example, as defined in the docs list of datasources).
Worker
worker:branch
worker:global
worker:onboarding
worker:pr
A worker is the "core" logic of Renovate. Use these labels to differentiate between the different internal Renovate working stages.
New stuff
new datasource
new package manager
new platform
new versioning
Apply these labels when somebody opens a feature type issue requesting a new datasource, package manager, platform, or new versioning scheme.
Housekeeping
good first issue
help wanted
logs:problem
reproduction:needed
reproduction:provided
duplicate
Add a label good first issue to issues that are small, easy to fix, and do-able for a newcomer.
This label is sometimes picked up by tools or websites that try to encourage people to contribute to open source.
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:
- Provide logs (if there are none yet)
- Provide more logs (in case current logs are insufficient)
- Format their logs properly
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 duplicate to issues/PRs that are a duplicate of an earlier issue/PR.
Self hosted
self-hosted
Use the self-hosted label to identify when an issue is applicable only to users who self-administer their own bot.