Screening duplicate bugs

Si has estado confirmando bugs SIN CONFIRMAR o viendo nuevos bugs, te habrás dado cuenta de que todos los bugs que son enviados por reporteros inexperimentados son bugs DUPLICADOS. A pesar de que menos de la mitad resultan ser duplicados, lo mejor es asumir que cada uno lo es hasta que uno se convenza de lo contrario.

Esto es una guía que sirve para ayudarle a identificar la máxima cantidad posible de bugs duplicados que llegan de la manera mas eficiente. Se asume que siente cierta comodidad usando Searching Bugzilla.

Este tutorial está escrito como si fueras a sentarte y a buscar bugs DUPLICADOS (DUPs) uno tras otros, pero muchos de estos se aplican, no importa como llegues a un bug potencialmente duplicado. Si quieres intentar identificar los bugs DUPLICADOS uno por uno al final de la lista hay una lista de bugs, que indica los tipos de bugs que usualmente están DUPLICADOS.

Mientras que estés revisando los reportes de bugs para ver si hay DUPLICADOS, por favor confirma los bugs SIN CONFIRMAR, agrega o simplifica casos de prueba, mejora los pasos para reproducirlo, mejora el resumen, reporta si lo has reproducido en otra plataforma, y/o si has hecho algo mas que tenga sentido antes de moverte al próximo, si el bug no parece ser un DUPLICADO.

Para marcar a un bug como DUPLICADO, tu necesitas el permiso "Puedes editar todos los aspectos de cualquier bug". Si no tienes este permiso, manda un e-mail a Gerv o a [email protected], y pregunta si lo pueden agregar a tu cuenta de Bugzilla. Mientras tanto, agrega un comentario a cualquier bug mencionando de que es, o puede ser un duplicado.

Los bugs rápidos y obvios

Si no lo has hecho todavía, por favor tomate tu tiempo con la lista de los bugs más frecuentemente reportados de Mozilla y la sección de los Problemas Conocidos en notas de versiones de Firefox.

 

Si el reporte se parece a una regresión reciente, fijate en los bugs recientemente reportados por el equipo de QA team, y en el newsgroup (netscape.public.mozilla.builds) para ver si el problema ya es conocido.

 

También puedes ver más en la lista de bugs de hoy para Firefox y Thunderbird. Mira la página de smoketesting si quieres concentrarte en esta área.

Tendrás menos dicultades escogiendo los bugs duplicados que tu ya cononces que se han reportado. En lugar de ir a través de la lista de bugs en orden, busca en ella bugs cuyos resúmenes parecen familiares, para que puedas tener tantos duplicados como se pueda sin reordenar las busquedas no guiadas.  Los DUPs que tu has reportado o que has encontrado deberían de ser los más fáciles de encontrar, y los más productivos al resolverlos, desde que eres capaz de reconocer y evaluar los identicos rápidamente. 

 

Some ways to narrow down the query based on what you remember:

• If you can remember an e-mail address associated with the existing bug, enter it into one of the Email sections and set the appropriate role(s). Do the same if you think you added a comment to the existing bug.
• If you can remember roughly when the bug entered the system, choose "[Bug Creation]" in the Where the field(s) field, and set a date range in the dates and to fields.
• If you know you've seen some mail from [email protected] on the subject of an existing bug that's a candidate for a match lately, enter a number in the Changed in the last [ ] days field.

If you get no matches, your recall may be fallible, so try the search again without the restriction.
 

If you were able to quickly find the correct bug report to mark a new bug a DUP of, but its summary contains none of the words the reporter of the new bug might have tried to search with, consider adding those words to the summary, or, if you can't do that, including them in a comment suggesting that they be added to the summary -- especially if the bug looks likely to get more duplicates.

Searching

The first field, Status, is normally preset to find NEW, ASSIGNED, and REOPENED bugs. Add UNCONFIRMED (use Ctrl-click in Windows, Command-click in MacOS) to find duplicates among newly-entered bugs too.
 

To cast a wider net, add RESOLVED and VERIFIED, or deselect everything in the Status field. Do this if you wouldn't otherwise expect a long bug list, or when trying again if you got a relatively short list with no matches. It can be easier to find earlier DUPLICATE bugs (which will be RESOLVED) and follow them to the "real" bug, especially if there are several DUPs already. The existing bug you are hunting for may also have been fixed already.
 

To exclude obviously extraneous bugs, narrow the search by making a choice under Product. Usually it will be "Core" (for Browser, HTML composition, and text-editing bugs) or "Firefox" or "Thunderbird".
 

If the proper component for previously reported bug is obvious (as could be expected for, as an example, most "Bookmarks" bugs), choose that component. You can select multiple components at once. Be prepared, though, to retry you query without specifying a component if you don't find a match - not all bugs end up where you'd expect.
 

The same will apply to the Keywords field. Not all bugs that should be labelled "fonts", for instance, necessarily are.
 

Beside each of the Summary, Description entry, and URL fields. There is a drop-down that lets you choose the type of matching. Choose among "case-insensitive substring","case-sensitive substring", "all words", "any words", or "regular expression", as appropriate (hints on which work best for several common search scenarios are available in the Text Searching tutorial). Although searching within the Description entry is much slower than any other field, go ahead and use it if it makes sense or the search terms available might not show up in the summary, but try to restrict the search with other fields at the same time if you can.
 

Boolean Charts are an advanced feature that can let you do searches that are otherwise impossible. You can use any kind of match with almost any field, and set up boolean ands and ors. The first chart always ands with the rest of the query form. As a trivial example, to search for bugs about the tab key and exclude bugs about tables, add [Summary] [Does not contain (case-insensitive) substring] ["table"] after putting "tab" in the Summary field.{C}
 

If you don't find a match on the bug list generated by your first query, it is usually worth trying at least one or two more queries.

Matching

When the bug list appears, scan it for anything that looks like a possible match. It's useful to open bugs in a new window to preserve the list. At the top of each column, clicking on its name will sort the bugs by that field. You can add other fields to the bug list by clicking on Change columns; for some searches, the Components column can be very useful.
 

If you find a clear and certain match, add a comment stating which bug the duplicate bug is a DUPLICATE of (if the bug report that matches is itself a DUP, follow the trail of "This bug has been marked as a duplicate of 00000" comments). If you had to read deep into the existing bug or puzzle out the connection, mention the date of the comment that explains the match or describe the connection.
 

If you are not certain of the match, but it looks probable or even possible, add a comment, but also say how sure you are. Even if you are not completely certain that a new bug is a DUP at all, if you think it probably is or even might be, add a comment saying that.
 

If the original report is deficient enough that you had to try to reproduce the bug before you could understand what the report was saying, please add enough detail so that the next person reading the bug won't have that problem, and will have an easier time confirming or verifying the match. Even if you don't find a match at all, please do this to make it easier for the next person, who might make the connection immediately given your improved description.
 

If the existing bug that the DUPLICATE matches to is in a different component, change the Component field to match the existing bug.
 

Finally, if you are sure that the bug is a DUPLICATE, go ahead and click on the radio button beside Resolve bug, mark it as duplicate of bug # [     ] and enter the bug number of the existing bug. Be sure to check for a typo or transposition error before clicking on [Commit].
 

If, to the best of your knowledge, a new UNCONFIRMED bug is not a DUP, please follow the steps outlined in the Confirming Unconfirmed Bugs guidelines before moving on to the next.

Which is the Duplicate?

Other things being equal, newer bugs should be made DUPLICATES of older bugs, but, more importantly, whichever bug is further along in the process of getting fixed should not be made a duplicate. Signs that progess has been made include:

• the bug is marked FIXED, a patch is attached or a fix is promised soon
• the bug is ASSIGNED to the right Component and developer
• the bug has been analyzed by developers
• the bug has been given a higher priority (e.g., [PDT+], beta2) or an imminent milestone
• the bug report has a explanation of how to reliably reproduce the bug and/or it has a simplified testcase

UNCONFIRMED and "General" bugs should never have another bug made a duplicate of them unless the other bug is also an UNCONFIRMED or "General" bug. Even then, the bug reports that have less detail and work should be made duplicate of the bug reports that are further along, even if those are older. At that point the bug that receives the DUP should normally be confirmed, if it is not already.
 

If you are stumped, add a comment resembling the following:

This bug appears to be a duplicate of bug nnnnn, but 
I'm not sure which should be made DUPLICATE of which.

One Down, or, Keeping in the Groove

Take another look at the bug list after making a match: there may well be another DUPLICATE of the same bug lurking there. You might also see two bugs on the list that look suspiciously similar even though neither matches the bug you started with.
 

After some time you will naturally become much more familiar with some types of issues and some components than others. Go with that, focus on the areas you can make sense of quickly. You might also have some existing expertise or experience that makes it easier for you to evaluate some bugs. If you know javascript well, for instance, it makes sense to check over new-to-you DOM bugs before identifying duplicates in any other area.
 

Similarly, let your tools guide you, to some extent at least. If you know how to use a Debugger, you can make more of a contribution to evaluating Crashers than others can, so it makes sense to look at them. Similarly, some bugs that are reported on Linux, Macs, or other platforms are specific to the platform or platform/OS combination that they were reported on. Someone unfamiliar with that platform won't be as efficient, so if you regularly use something other than Microsoft Windows, please look at bugs reported on your platform first, by selecting it on the query page. Use the Edit this query link at the bottom of a bug list to get back to the query form if you can't use the [Back] button.
 

By concentrating on the bug reports that you have the skills and experience to evaluate quickly and surely, you will be able to help more in the time you can contribute.

Specific Types of Duplicates

Some types of bug reports need or can benefit from special handling:

1. Bug reports about a particular URL: Check first for a substring (usually just the domain name is appropriate) of the URL in the URL field, matching against bugs with any Status. Obvious exact DUPs should show up easily that way, so long as the reporter filled in the URL field. In case that was not done, check in the Description entry field if there is no match in the URL field.
2. Reports of Crashes: Crashes are identified by what specific code crashed, not how they are reproduced, so some sort of debugging output may be required before a determination can be made whether a crash report is a DUP. If you reproduce a crash on a previously unreported platform or OS, or using a current binary when the reporter was using a milestone release, please add as much detail as you can. If a module name is reported or you can generate a stack trace, search in Bugzilla for bugs with the crash keyword. If you don't find a match, add "crash" to the keywords field, so long as you were able to reproduce the crash.
3. Multiply-DUPLICATE reports: Some bug reports describe a number of often unrelated problems. If all of the problems mentioned are clearly duplicates of existing bug reports, mark the new bug report as a DUPLICATE based on the first issue. If it is clear that all but one of the problems have already been reported, state that, citing the bug numbers if possible, and adjust the Summary to refer to the remaining problem.
4. "General" bug reports: Be sure to move the bug to the appropriate Component if you can identify it, and copy over the QA contact, at the same time that you mark it as a DUP, so that it can be verified by someone familiar with the existing bug report.
5. Same Exact Bug, two bug numbers: Sometimes a bug report ends up in the Bugzilla database twice in a row. If you see two bugs with the same summary and adjacent bug numbers, mark one as a DUP of the other immediately, before both get comments -- but look at both first, in case one has comments already.
6. An ASSIGNED bug may be a DUP: It does sometimes happen that one assigned bug is a duplicate of another. If both are assigned to the same engineer, add a comment to the one that is not as far along as the other; if two different engineers are involved, add a comment to both, pointing out the existence of the other and why it appears to be a DUP. Do not resolve ASSIGNED bugs as DUPs yourself; the assignee should do that.

Lists Where Duplicates Lurk

The greatest concentration of duplicate bugs is in those that enter the database as UNCONFIRMED, although plenty of NEW bugs also turn out to be DUPs. Bugs do occasionally get ASSIGNED before being found to be a DUP, but that is what duplicate-screening is meant to prevent, so please concentrate on UNCONFIRMED and NEW bugs.
 

The bug lists below are displayed in rough descending order of prevalence of duplicates. They will appear in new windows; you may want to open bugs from the list in new windows too, to preserve the list. Happy matching; if you find only one DUP, you'll have earned the thanks of a busy software enginner.
 

• UNCONFIRMED Firefox bugs changed in the last week | Linux-only | Mac-only | Customize

• Today's & Yesterday's UNCONFIRMED and NEW Firefox and Thunderbird Bugs | Customize
  (UNCONFIRMED-only | NEW-only
• UNCONFIRMED Thunderbird bugs changed in the last week | Linux-only | Mac-only | Customize

(Thanks to Jan Leger, Eli Goldberg, David Baron, John Morrison, Matthew Thomas, Gervase Markham, Liz Henry, and Terry Weissman for contributing to this document. Additional suggestions welcome.)