Request new features and report problems in the Backdrop Issue Queue.
Creating new issues
All you need to file an issue is an account at GitHub. Once you're logged in, navigate to the Backdrop Issue Queue. There's a green button at the top right labeled "New issue". Click that button to get started.
We have provided several issue templates that will help you file your issue. You may browse the list of options here, and select the one that best fits your needs. If you don't see a good match, you can still select the link "Open a regular issue" at the bottom of the list.
When creating your issue, give it a short but descriptive title. Follow the template provided (if applicable), and try to be as detailed as you can. Whenever possible, please include steps we can follow to reproduce the problem you are having. Copy & Paste any error messages you're seeing, and post screenshots if you have them. The more information we have, the faster we'll be able to address your concern.
Once you are satisfied with your issue, click the "Submit new issue" button at the bottom - but don't worry - you'll be able to edit the issue if you notice a typo.
Commenting on issues
If you have something to add to an existing discussion, please add a comment! All experience levels are welcome in the issue queue, you don't need to be a developer to tell us what you'd like Backdrop to do, or to do better.
Any time you're interacting with other members of the Backdrop community, please be polite. Even if you are frustrated by misbehaving software, you'll find that you'll get further with honey than you will with vinegar.
Working on issues
If you are working on an issue in the queue, please assign that issue to yourself. You can do that at the top right of the issue, where it says "Assignees". Once you are done, or if you need to stop working on the issue for any reason, please add a comment at the bottom stating what you have tried, and un-assign the issue from yourself.
Please create a Pull Request if you have written code for the issue (it does not need to be in a working state). See the documentation on how to submit pull requests for more on this topic. Once a Pull Request has been created for an issue, please add the label 'status - has pull request' to that issue.
Labels are added to issues to help everyone know at first glance what's going on with that issue. They are also useful for searching the queue, or filtering for a specific type of issue.
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 Gitter 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.
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.
- type - bug report = something is broken
- type - documentation = something needs to be better explained
- type - feature request = I want something new
- type - question = I have a question
- type - task = this label is usually used for code cleanup or similar
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.
- status - cannot reproduce
- status - duplicate
- status - fixed
- status - has pull request
- status - postponed
Pull Request labels
Pull request labels will help us see the status of the PR attached to this issue. These are particularly useful since we don't all have permission to add labels on PRs themselves.
- pr - needs work - Add this label if you think a pull request still needs more work.
- pr - needs review = Add this label if a pull request is ready to be reviewed by others.
- pr - reviewed & tested by the community = Someone who did not create the pull request will need to review the work. If the reviewer approves of the pull request, they can then add this label.
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.
- needs - benchmarks = this issue may have performance implications. We need some benchmarks before merging a PR.
- needs - change notice = this issue will result in an API change, and a notice is necessary for those who are using this API.
- needs - documentation update = this issue will result in a change that will require our User Guide to be updated.
- needs - more feedback = this issue should not move forward without more people in the conversation.
- needs - usage metrics = this issue shouldn't be completed without usage metrics.
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 will not be resolved in core, but could be 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 OpenSource, or Backdrop in particular.
- help wanted = the person working on this issue needs help with something.
- milestone candidate = the person who created this issue thinks it should be a priority. It needs a second person to agree before a milestone can be added.