Heuristics For Labeling Bug Reports

 

This page provides the heuristics that were used for the paper “Who Should Fix This Bug?”.

 

Projects: Eclipse Firefox gcc

 

Eclipse Platform Project (http://www.eclipse.org/platform/index.html)

(These heuristics are extensions of the ones given in “Automatic bug triage using text classification” by Cubranic and Murphy)

 

  1. If the report has not been resolved (i.e. NEW, UNCONFIRMED, REOPENED) label the report with the name of the developer who was last assigned to it.
  2. If the report was resolved by the assigned-to person, label the report with the assigned-to person.
  3. If the report was not resolved by the person who filed the report or who was assigned to the report, label the report with the name of the developer who resolved it.
  4. If the report is marked as FIXED, regardless of who resolved it, label the report with the person who marked it as such.
  5. If the report was resolved as not FIXED (i.e. WONTFIX, WORKSFORME, INVALID) by the person who filed the report and was not assigned to it, label the report with the name of the first person who responded to the report. This covers cases where the submitter retracts a report such as after being asked for more information and not being able to reproduce the problem.
  6. If the report was resolved as not FIXED by the person who filed the report and was not assigned to it, and no one responded to the bug, then the report cannot be labeled. This covers cases when a bug is submitted by error, such as the reporter not knowing the proper operation of Eclipse, and retracts the bugs before anyone else responds to it.
  7. If the report was resolved as LATER or WONTFIX by the person who filed the report and was not assigned to it, label the report with the name of the reporter. This heuristic covers bug reports that are ‘to-do’ items for the developer.
  8. If the report is marked as a DUPLICATE, label the report with the label of the report of which this report is a duplicate of.

Firefox Browser Project (http://www.mozilla.org/products/firefox/)

 

  1. If the report is marked as NEW, UNCONFIRMED, or REOPENED then no one has taken responsibility for the report and it is unknown to which developer it will be assigned. The report is labeled as unclassifiable.
  2. If a report is resolved as WORKSFORME, it was so marked by the person doing the bug triage, and it is unknown which developer would have been assign the report. The report is labeled as unclassifiable.
  3. If the report is marked as ASSIGNED, then a developer has taken responsibility for fixing the report and the report is labeled with their name.
  4. If the report is resolved as FIXED and the report has attachments which were approved by a reviewer, then
    1. If there is only one submitter of approved patches, label the report with their name.
    2. If there is more than one submitter of approved patches, choose the name of the developer who submitted the most patches.
    3. If the submitter(s) of the approved patches cannot be determined, then label the report with the person who is assigned to the report.
  5. If the report was marked as FIXED without an attached patch, then it was likely a regression and the report is labeled with the name of the person who marked the report as fixed.
  6. If the report is marked as INVALID and the person who resolved the report was not the person who submitted the report, label the report with the name of the developer who made the decision.
  7. If the report was marked as INVALID by the person who submitted the report, the report was likely submitted in error and it is unknown which developer would have been assign the report. The report is labeled as unclassifiable.
  8. Reports that are marked as WONTFIX are often resolved after some discussion and the developers reach a consensus. It is unknown which developer would have fixed the bug, so the report is labeled as unclassifiable.
  9. If the report is marked as a DUPLICATE, label the report with the label of the report of which this report is a duplicate of.

 

gcc (http://gcc.gnu.org/)

  1. If the report is NEW, UNCONFIRMED, or REOPENED then no developer is responsible for it and it is unknown who will be assigned. The report is labeled as unclassifiable.
  2. If the report is marked as WAITING or SUSPENDED, then a developer is waiting for more information or some other event to occur, such as another bug being fixed, before this bug can be resolved. As a developer is in the process of resolving the problem, label the report with their name.
  3. If a report is resolved as FIXED, then label the report with the name of the person who marked the report as fixed.
  4. If the report was resolved as INVALID, WONTFIX, or WORKSFORME by the submitter then the report was likely submitted in error and it is unknown who would have been assigned the report. The report is labeled as unclassifiable.
  5. If the report was resolved as INVALID, WONTFIX, or WORKSFORME by someone other than the submitter, then label the report with the developer name that made that determination.
  6. If the report was marked as INVALID and report was for the ‘spam’ component then the report was the result of actions by a spammer and is labeled as unclassifiable.
  7. While the report status CLOSED is not valid for the gcc project, some bug activity logs show that that a bug was marked as such. These appear to be old bug reports that are in the repository so that other reports can reference them, such as duplicates. Such reports are labeled with the name of the developer who last changed the status of the report.
  8. If the report is marked as a DUPLICATE, label the report with the label of the report of which this report is a duplicate of.