Documentation Level: 
Documentation Status: 
No known problems

Labels help us organize our work.

Labels are added to issues to help everyone know at first glance what's going on with that issue. They are useful for searching the queue, or filtering for a specific type of issue.

Adding Labels

Anyone who has added a comment to an issue, or created a new issue, should have automatically been granted access to add labels to all issues. If you don't have this ability, please ask someone in the Zulip chat for help.

If you don't know what labels to add to an issue, it's perfectly okay skip this step. It's likely that one of the first people to comment on the issue may add a few for you.

Below you'll find an explanation of all the labels we use on the issue queue. Each label below is linked to a list of current issues with that label.

Type labels

Type labels let us know what type of issue this is. Is it a bug report, or a feature request? These labels will help us choose the appropriate milestone for getting a fix into Backdrop core.

Backdrop releases a minor version every four months. Typically about two weeks prior to the release, there is a feature freeze for that release, which means:

Status labels

Status labels let us know what state an issue is in. These types of labels are useful for both issues that are closed (Has it been fixed already? Is it a duplicate of another? ) as well as those that are open (Is there a pull request?) Most are self-explanatory.

Pull Request labels

Pull Request labels will help us see the status of the PR attached to this issue. These are particularly useful for testers and reviewers since we don't all have permission to add labels to the PRs themselves.

  • pr - needs work = Add this label if you think a pull request still needs more work.
  • pr - needs testing = Add this label if a pull request is ready to be tested by others.
  • pr - needs code review = Add this label if a pull request needs another set of eyes to review the code.
  • pr - works for me = Add this label if you have tested the PR and it works how you'd expect. (You can also add the pr - ready to be committed label if the PR has had a code review).
  • pr - ready to be committed = Someone who did not create the pull request will need to test and review the work. If this person approves of the pull request, they can then add this label.

Needs labels

Need labels let us know what an issue needs, if anything. The most common of these is 'needs more feedback' where we're simply seeking more comments from different people, so we know what the community wants.

Milestone candidate labels

  • milestone candidate - bug = Someone thinks this issue should be included in the next bug-fix release. It needs a second person to agree before that milestone can be added.
  • milestone candidate - minor = Someone thinks this issue should be included in the next minor release. It needs an advocate who will drive it to the finish line before that milestone can be added.

Misc labels

There are a few other miscellaneous labels that are not prefixed with anything. These are labels we have also come to need.

  • contrib candidate = This issue is not likely to be resolved in core, but could be resolved in a contributed module, theme, or layout.
  • design = This issue needs a designer to participate in the conversation, and perhaps provide mockups in addition to design direction.
  • good first issue = This issue would be a good one for people starting to contribute to Backdrop or OpenSource.
  • help wanted = The person working on this issue needs help with something.
  • blocked = This issue cannot be committed until another problem is resolved.