Bug Squad: How to work the issue queue

• Start at the back of the active queue and work forwards.
• Check for duplicates.
• Verify the Views submission guidelines have been met.
• Verify the issue settings are correct.
• If everything is correct, act on the issue where possible.

Start at the back of queue

When setting out to provide real help in the Views' queue, work from the back of the queue, which is to say, the oldest issues first. The default lists of issues provide the most recently touched issues first. That's great, if you're carrying on conversation. But the queue is very active, and things fall off the first few pages almost within minutes sometimes. Go to the oldest active issues and work forward to ensure that the issues that fall through the cracks get addressed.

Verify the submission guidelines

When a user submits an issue to the Views' queue, the user is presented with a link to the submission guidelines. While many users follow this link and read, many others do not.

The submission guidelines provide a long list of things that a submitter should do when submitting an issue. This is to try to ensure that enough information is given and that issues are submitted to the right place. Issues that do not meet the requirements should be responded to with a link to the guidelines, a short summary of what is wrong, and either set to postponed (maintainer needs more info) for minor errors, or closed (won't fix) for flagrantly ignoring the guidelines.

Check for duplicates.

Issue statistics indicate that roughly 10% of all issues in the Views' queue are currently marked closed (duplicate). It is therefore imperative that a Bug Squad member perform the searches on the issue queue that the submitter did not, and possibly did not know how to. As a Bug Squad member gains experience, it will become clear that some issues get duplicated more often than others, and it will also become easier to figure out which keywords can be used on searches.

If an issue is a duplicate, paste a link to the issue that is being duplicated. Sometimes a short explanation may be necessary.

It is sometimes necessary to discern what is similar from what is duplicate. As an example, users will often run into errors with the javascript/ajax functionality of the UI which contains very generic errors. In order to determine if the error is a duplicate of another, it may be necessary to get more information from the user first, such as getting data from the apache/watchdog/php logs as well as using firebug to look at post/response data.

Other times, the same PHP error will appear but in completely different files, or when executing completely different operations. Often these will appear to be duplicates but will not, in fact, be duplicates.

Verify the issue settings

First, verify that the settings of the issue are even correct. The most important parts of the issue settings to verify are the category, priority, status and title. Another thing bug submitters often do by mistake is to assign the issue to themselves. Unless it is very clear that a submitter actively intends to work an issue (i.e, file a patch for a bug) this is almost certainly a mistake, and you should correct this for them.

Issue category

• support issues should be general questions about how to perform a specific task in the software. Many support requests are often misfiled as bugs, because people assume that because they do not understand how to perform a task, that means the software is broken. Many bugs are often files as support requests because users are unsure if what they are seeing is a bug or not, so they want verification.
• bug reports are when the software actually behaves incorrectly. The best bug reports are reproducible, and include an export of the view and any associated data needed to reproduce it. Not all bug reports are going to be reproducible, but it is extremely difficult to fix bug reports that are not. Bug reports should be specific and narrow.
• feature requests are requests by users to add new features to Views. Views internally supports only core, so feature requests involving other modules must be very very large modules, or submitted against the other module. Feature requests must be generally useful. Feature requests asking for better support for existing data, new ways to output data, new sorts and new filters are generally acceptable. Feature requests asking for specific output styles or limited use data will often be denied.
• tasks are TODO items used by Views maintainers and people working closely with the maintainers only. General users will often use the task category when they mean bug report or feature request. Tasks are more or less feature requests that have been accepted and need to be worked on. Tasks that are not assigned to a user are open, hoping someone will pick them up. Important tasks might need to be advertised via other channels. It is appropriate to tweet about unassigned tasks if it seems important.

Issue priority

• critical priority is reserved for hard crash issues. If the feature causes Views to white screen or otherwise damage the site or its data, it may be considered critical. Tasks may be marked critical if they are something we strongly desire go into the next version. Items that negatively affect accessibility and usability are good candidates for major.
• major priority is reserved for bugs that severely impact the ability to get things done with Views, but do not crash or damage the site. Bugs with features that simply do not work but should can be considered major only if those bugs impact the ability to use Views.
• normal priority is everything else. No support request should ever be marked with a higher priority than normal.
• minor priority is for bugs or feature requests that are more or less cosmetic only. They should have minimal impact on the ability to use the software.

Issue status

• active issues are open questions or bug reports that have not yet been addressed. Unassigned active issues are the domain of the Bug Squad (except for unassigned active tasks). This is the default state that new issues should be submitted in, and should remain in this issue as long as no further action is needed from the submitter.
• closed (duplicate) should means that the issue was submitted as a duplicate of another. Usually the oldest issue is the one kept active, but sometimes older issues are marked dup in favor of newer issues which contain better information or more conversation. Sometimes duplicates are marked in error. If this is the case, simply change them to an appropriate status.
• needs review and needs work are reserved for issues with patches. More experienced members of the Bug Squad who are also PHP developers might spend time reviewing patches, but this is not the main purpose of the bug squad. Users sometimes inadvertently submit issues marked needs review because they believe their issue needs to be reviewed by someone. Issues without patches should be changed to active.
• fixed indicates that the issue has been addressed. In the case of a bug report, task or feature request, a commit has been made to the code or change to supporting documentation. In the case of a support request, the question has been answered as well as is possible. When a Bug Squad member has answered a question, even if the answer might be incomplete, fixed is the best status to use. It is unfortunately common for Views' maintainers to forget to use this status and leave answered support requests as active. These can simply be marked fixed. If the user finds that the answer is insufficient, they are free to mark the issue active again when they request further information.
• postponed (maintainer needs more info) means that the submitter has provided enough to make us believe that this issue is legitimate, but not enough to act on it. Issues that are in this state are awaiting the requested information. It is very common for submitters to not realize they need to set this state back to active, so reminding them to do so when changing an issue to this state is advised.
• closed (cannot reproduce), closed (won't fix) and closed (works as designed) are all indicators that the issue is done, and that no action will be taken. While these are mostly self explanatory, closed (won't fix) is good for questions that are simply too complex or time-consuming for volunteer support to answer. For particularly complex questions, pointing people to Acquia, which does paid support, may be helpful, but it can also appear condescending so be careful with this.

Issue title

Often overlooked, the issue title is invaluable for ensuring that someone scanning the issue queue can get a sense of what the issue is about right away. The Bug Squad is responsible for improving the titles of user submitted titles whenever possible. Users without the proper experience are very likely to not understand how to properly title issues, and this is okay. Simply find the best, concise wording you can, correct mistakes, and change the title accordingly. Titles should include the best keywords to use for searching as well, as these are given higher weight by the search algorithm.

Issue tags

Users will often misunderstand the purpose of this field and add a lot of superfluous tags, including tags that duplicate other issue fields. Remove tags that are inaccurate, or that duplicate existing information (component, version, status, etc.).

Examples of tags that should always be removed: "views," "views 3," "bug," and so on.

Acting on the issue

Acting on the issue depends largely upon the category of the issue.

Support requests should be answered to the best of the ability of the Bug Squad member, or they are interesting, difficult questions, they should be promoted to esmerel who can answer or figure out who is best to answer the question.

Bug reports should be verified as valid and if possible, duplicated. The minimal steps necessary to duplicate should be summarized. The bug report can then be assigned to merlinofchaos or dereine. (In general, issues against Drupal 6 go to merlinofchaos and against Drupal 7 go to dereine).

Feature requests should pass the sniff test for "Yes that makes sense" and ensure that the submitter was clear and understandable. These can then be assigned to merlinofchaos who can figure out what to do with them.

If you set an issue as postponed (maintainer needs more info), please consider assigning the issue to yourself. By doing so, you will make it easier to find that issue and continue a conversation, preventing another Bug Squad member from having to repeat the work you've already done on the issue. That said, please be kind; if you have issues assigned to yourself, please remember to check the queue for these issues from time to time, as Bug Squad members may actively ignore issues that are assigned to a user!

In general, if you feel an issue should be promoted and you're not sure who it should be assigned to, assign it to esmerel and she will figure out who it should belong to.