Bug Hunters Squad

The Bug Hunters Squad is an essential team in Zentyal Community. The members of this team filter bugs from misconfigurations, ensure that bug reports are complete, find duplicate bug reports, and classify bugs according to their severity and module. All of these activities allow for a better debugging process and, in short, help making Zentyal a better product.

Instructions and tips for bug filtering

Zentyal needs accurate bug reports (tickets) for staying in good health. Inaccurate bug reports mean overlooked bugs or developers looking for the wrong things in the wrong corners of the system.

Not all reporters know how to fill a good enough ticket. Some bugs may be reported via the  forum rather than via  trac, or a support question may result in a bug discovery. Usually you should ask people to create a ticket, but occasionally you may decide to file them in by yourself (for example, because of the user's poor English skills).

1. Find unfiltered tickets: Unfiltered tickets don't have the accepted status. You can get a list of them through the page ' View tickets' -> ' New Tickets by Milestone'. The tickets from the Nice to have someday milestone should be ignored.

2. Make sure that it is really a bug: First, we must deal with spam. If the ticket is spam, and you are sure about it, just close it with the resolution 'spam'. An admin will review spam tickets periodically and will delete them. Then there are the configuration help requests. In these cases you should gently remind that trac is for bug reports and that configuration questions should be asked in the Forum. Normally this is straightforward, but there are some configuration errors which could be mistaken for software errors. These errors should have the same treatment as feature requests, but we should be aware that repeatedly reported configuration errors can point to a usability problem.

3. Set a proper summary: This is the most important field of the ticket as the description should allow the Dev. Team to reproduce and fix the issue. Some tickets are automatically created and have the default Bug report from Zentyal server as summary. When this is not the case, you should set a proper summary.

4. Check for duplicates: There should not be any repeated bug reports. So, use the trac search function to find out if there are any duplicates of the same ticket. In case you find duplicates, set the resolution to duplicate and include the original ticket number in the comment so the reporter can check out for additional information. It is possible to receive a duplicate of a ticket which is not yet resolved and which gives additional and helpful feedback; in this case it is helpful to add a comment in the original ticket pointing to the duplicate.

5. Set ticket type: In case the reporter has not set the type, you must set it correctly:

• defect: A bug in a present feature.
• enhancement: An enhancement in a existing feature.
• feature request: A request for adding a new feature.

6. Set milestone: If the user has not set the milestone (Zentyal version), you have several methods to find it out and set it correctly:

• Maybe the user mentioned the version number in the message.
• If the bug was reported through the Zentyal user interface, you can find the version in the zentyal.log file.
• Likewise, you can see the package versions in the software.log file. Maybe the reporter is talking about a feature which is only present in a specific version and you can deduce the version.
• If you cannot find the milestone, you must ask for it in the ticket. Time spent looking for a problem in a wrong milestone is lost time.

If the ticket is for a closed milestone, you can resolve the ticket as wontfix. These versions are not supported any more.

7. Set severity: The priority of the bugs must be set considering the effects of the problem and the chances it is triggered. A minor bug that occurs always (e.g. logo of the splash screen always shows inverted) is more urgent that a very serious bug that happens rarely (e.g. a bug that deletes the hard disk on the 4th of May if you have a user called Tarzan in the system). The severity could be further refined by Zentyal staff considering more general product development goals, which could not be the same than the reporter's goals.

The available severities are:

• Trivial. A very minor inconvenience, not frequent nor easily visible. E.g. a warning logged twice in the log file.
• Minor. A bug that only causes inconveniences or data loss rarely. E.g. a bug that gives an error when browsing the web interface and disappears after reloading the page.
• Normal. This is the default priority; use it if you don't have any reason to use other priority.
• Major. A frequent bug that can cause data loss or stop an important service. E.g. a bug that stops the scheduled backup when a specific frequency is chosen.
• Critical. A frequent bug that can cause catastrophic data losses or causes the server to go down. Luckily the bugs filed in this category rarely really belong to it.

For feature and enhancements requests the priority will depend heavily on the roadmap and workload of the Dev. Team so set it to Normal. The developers will change it if needed.

8. Set component: Normally this is the module which is affected by the ticket. There are some caveats:

• You have a component for bugs related with internationalisation: i18n.
• The backup component also covers the Import/Export configuration feature.
• There is also a component for the documentation.
• If you are not, sure set it to base.

9. Set keywords: If you want, you can add here some keywords to make it easier to locate the ticket with the search engine.

10. Help to get relevant information: As mentioned before, unfortunately not all reporters know how to fill a good enough ticket and this might make it impossible to fix the bug. This might also mean that there is not enough information in a ticket. If you spot such tickets and you can think of obvious questions to ask, ask them: it might help speed up the resolution as it is not necessary to wait until a developer asks it. Information is the key: get as much relevant information as you can, so that the bug can be reproduced and fixed.