Documentation Level: 
Introduction
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.

  • = Something is broken.
  • = Something needs to be better explained.
  • = I want something new.
  • = I have a question.
  • = This label is usually used for code cleanup.

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:

  • No PR for an issue labeled can be merged into the release after that date;
  • PRs for issues labeled and may still be merged into the release (if work on the issues is complete).

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.

  • = Add this label if you think a pull request still needs more work.
  • = Add this label if a pull request is ready to be tested by others.
  • = Add this label if a pull request needs another set of eyes to review the code.
  • = Add this label if you have tested the PR and it works how you'd expect. (You can also add the label if the PR has had a code review).
  • = 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.

  • = This Pull Request needs to have tests added before it can be merged.
  • = This issue may have performance implications. We need some benchmarks before merging a PR.
  • = This issue will result in an API change, and a notice will need to be added to api.backdropcms.org.
  • = This issue will result in a change that will require our User Guide to be updated.
  • = This issue needs an update on its translation(s).
  • = This issue needs more opinions, and more people in the conversation.
  • = This issue shouldn't be completed without usage metrics.

Milestone candidate labels

  • = 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.
  • = 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.

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