Changes between Version 1 and Version 2 of Teams/BHS

Show
Ignore:
Timestamp:
03/02/12 20:43:02 (15 months ago)
Author:
hvilppola@… (IP: 87.222.134.4)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Teams/BHS

    v1 v2  
    11= [wiki:Teams/BHS Bug Hunters Squad] = 
    22 
    3 The Bug Hunters Squad is an essential team in Zentyal Community. It filters 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, for making Zentyal a better product. 
     3The 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. 
    44 
    55== Instructions and tips for bug filtering == 
    66 
    7 Zentyal needs accurate bug tickets for keeping its health. Inaccurate bug reports mean overlooked bugs or developers looking for the wrong things in the wrong corners of the system. 
     7Zentyal 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. 
    88 
    9 Not all reporters know how to fill a good enough ticket. Some bugs may be reported via the [http://forum.zentyal.org forum] rather than via [http://trac.zentyal.org/ trac], or a support question may result in a bug discovery. Usually we ask people to create a ticket but we may occasionally decide to put them in ourselves (for example because of the user's poor English skills). 
     9Not all reporters know how to fill a good enough ticket. Some bugs may be reported via the [http://forum.zentyal.org forum] rather than via [http://trac.zentyal.org/ 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). 
    1010 
    11 1. '''Find unfiltered tickets''': Unfiltered tickets  don't have the '''accepted''' state. You can get a list of them through the page '[http://trac.zentyal.org/report View tickets]' -> '[http://trac.zentyal.org/report/12 New Tickets by Milestone]'. The tickets from the '''Nice to have someday''' milestone should be ignored. 
     111. '''Find unfiltered tickets''': Unfiltered tickets  don't have the '''accepted''' status. You can get a list of them through the page '[http://trac.zentyal.org/report View tickets]' -> '[http://trac.zentyal.org/report/12 New Tickets by Milestone]'. The tickets from the '''Nice to have someday''' milestone should be ignored. 
    1212 
    13 2. '''Make sure that it is really a bug''': First, we must deal with '''spam'''. If the ticket is spam, and I am sure you know it when you view it, just close it with the resolution 'spam'. An admin will review spam tickets periodically and will delete them. Then we have the '''requests of configuration''' help. In this case we 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. They should have the same treatment but we should be aware that this situation can point to a usability problem. 
     132. '''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. 
    1414 
    15 3. '''Set a proper summary''': This is the most important field of the ticket which allows us to recognize its contents. Some tickets are automatically created and have the default '''Bug report from Zentyal server''' as summary. In this cases a proper summary must be set. 
     153. '''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. 
    1616 
    17 4. '''Check for duplicates''': We should not do the same task twice. So use the trac search function for looking for duplicates of the same ticket. In case you found duplicates, set the resolution to '''duplicate''' and include the original ticket number in the comment so the reporter could check more information. It is possible to receive a duplicate of a ticket with is not yet resolved and which gives additional and helpful feedback; in this case it would be helpful to put a comment in the original pointing to the duplicate. 
     174. '''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. 
    1818 
    19 5. '''Set ticket type''': In case the reporter has not set the type, you must set it to the correct one: 
     195. '''Set ticket type''': In case the reporter has not set the type, you must set it correctly: 
    2020 
    21 * '''defect''': a bug in a present feature 
    22 * '''enhancement''': a enhancement in a existing feature 
    23 * '''feature request''': request for adding a new feature 
     21* '''defect''': A bug in a present feature. 
     22* '''enhancement''': An enhancement in a existing feature. 
     23* '''feature request''': A request for adding a new feature. 
    2424 
    25 6. '''Set milestone''': If the user has not set the milestone we have several methods to find and set it: 
     256. '''Set milestone''': If the user has not set the milestone (Zentyal version), you have several methods to find it out and set it correctly: 
    2626 
    27 * Maybe the user told us the version number in the message 
    28 * If they have reported the bug using the Zentyal interface in the zentyal.log file the versions are shown 
    29 * Likewise in the software.log file we can see packages versions maybe the reporter is talking about a feature which is only present in one version 
    30 * If we cannot find the milestone, we must ask him in the ticket. Time spent looking for a problem in a wrong milestone is lost time. 
     27* Maybe the user mentioned the version number in the message. 
     28* If the bug was reported through the Zentyal user interface, you can find the version in the zentyal.log file. 
     29* 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. 
     30* 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. 
    3131 
    32 If the ticket is for a closed milestone, we can resolve the ticket as '''wontfix'''. We don't support those versions anymore. 
     32If the ticket is for a closed milestone, you can resolve the ticket as '''wontfix'''. These versions are not supported any more. 
    3333 
    34 7. '''Set severity''': For bugs the priority must be set weighting the effects of the problem and the chances of triggering it. A small bug which always is fired (like the logo of the splash screen show inverted) is more urgent that a very serious bug which rarely happens (a bug that deletes the hard disk in the 4th of may if we have a user called '''Tarzan''' in the system). The severity could be further refined by Zentyal staff according of the needs of the product, which could not be the same than the reporter's. 
     347. '''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. 
    3535 
    3636The available severities are: 
    3737 
    38 * '''Trivial'''. A very minor inconvenience no frequent or not easily visible. Like a warning logged twice in the log file. 
    39 * '''Minor'''. A bug that either only causes inconveniences or if it can cause data loss happens rarely. For instance, it could be a bug that raises an error when browsing the web interface which goes away after reloading the page. 
    40 * '''Normal'''. The default priority; use it if you don't have any reason to use other priority. 
    41 * '''Major'''. A frequent bug that can cause data loss or stop a important service. For example, a bug which stops the scheduled backup with a specific frequency is chosen. 
    42 * '''Critical'''. A frequent bug which can cause catastrophic data losses or causes the server goes down. Luckily the bugs filed in this category rarely belong really to it. 
     38* '''Trivial'''. A very minor inconvenience, not frequent nor easily visible. E.g. a warning logged twice in the log file. 
     39* '''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. 
     40* '''Normal'''. This is the default priority; use it if you don't have any reason to use other priority. 
     41* '''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. 
     42* '''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. 
    4343 
    44 For features requests and enhancements the priority will depend heavily on the roadmap and workload of the developer so set it either to '''Normal'''. The developers will change it if needed. 
     44For 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. 
    4545 
    46468. '''Set component''': Normally this is the module which is affected by the ticket. There are some caveats: 
    4747 
    48 * we have a component for bugs related with internationalization: i18n. 
    49 * the backup component also covers the Import/Export configuration feature. 
    50 * there is also a component for the documentation 
    51 * if you are not sure set it to '''base''' 
     48* You have a component for bugs related with internationalisation: i18n. 
     49* The backup component also covers the Import/Export configuration feature. 
     50* There is also a component for the documentation. 
     51* If you are not, sure set it to '''base'''. 
    5252 
    53 9. '''Set keywords''': If you want you can add here some keywords to make it easier to find with the search engine. 
     539. '''Set keywords''': If you want, you can add here some keywords to make it easier to locate the ticket with the search engine. 
    5454 
    55 10. '''Help get relevant information''': As it has been said before "Not all reporters know how to fill a good enough ticket". This also includes the lack of information in a ticket, if you spot such tickets and you can think of obvious questions to ask, it might help speed up the resolution if the question doesn't have to wait until a developer asks for it. Information is key, get as much relevant information as you can, so that the bug can be reproduced and be fixed. 
     5510. '''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.