Difference: BugTriage (1 vs. 8)

Revision 82006-03-06 - murphy

Line: 1 to 1
 

Bug Triage

General Overview

Line: 17 to 17
 Our work as been published at a number of venues. See our publications listing below.
Changed:
<
<		John Anvik, Lyndon Hiew and Gail Murphy (OK, lousy way to put people on this - other suggestions?)
>
>		The people involved are:
  • John Anvik
  • Lyndon Hiew
  • Gail Murphy
 

Bug Report Assignment

Line: 41 to 44
 

Duplicate Detection

Changed:
<
<		Identifying which new bug reports are duplicates of previous reports is one task a bug triager performs. This can be a daunting task in large projects where there are thousands of reports to search through. We use the approach of event detection systems from Topic Detection and Tracking (TDT) research that identify whether a news story describes a new, previously unseen event or a old news event. A tool has been implemented which indicates if a new report is unique or a duplicate. If the report is believed to be a duplicate, the tool suggests which previous reports might be duplicates.
>
>		Triagers need to identify which new bug reports are duplicates of previous reports. In large projects where there are thousands of reports to search through, identifying duplicate bugs can be a daunting task.
 
Changed:
<
<		A study is being conducted to determine how beneficial the duplicate detection tool would be to bug triagers, given the accuracy of the current approach. We are looking at what effects the tool would
>
>		We have developed an approach to suggest to a triager possible duplicates of a new report. Our approach is similar to the techniques used by event detection systems from Topic Detection and Tracking (TDT) research that identify whether a news story describes a new, previously unseen event or a old news event.

We are currently conducting a study to determine how beneficial the duplicate detection tool is for bug triagers. We are looking at what effects the tool would

 have on a triager's duplicate detection accuracy and their workload.

Future plans include implementing the tool as a Firefox extension.

Changed:
<
<		If you are interested in participating in the study or would like to be notified when the tool becomes available, email Lyndon Hiew.
>
>		If you would like to be notified when the tool becomes available, email Lyndon Hiew.
 

Publications

Revision 72006-03-03 - lyndonh

Line: 1 to 1
 

Bug Triage

General Overview

Line: 40 to 40
 

Duplicate Detection

Changed:
<
<

Overview

to be written - Lyndon
>
>		 Identifying which new bug reports are duplicates of previous reports is one task a bug triager performs. This can be a daunting task in large projects where there are thousands of reports to search through. We use the approach of event detection systems from Topic Detection and Tracking (TDT) research that identify whether a news story describes a new, previously unseen event or a old news event. A tool has been implemented which indicates if a new report is unique or a duplicate. If the report is believed to be a duplicate, the tool suggests which previous reports might be duplicates.

A study is being conducted to determine how beneficial the duplicate detection tool would be to bug triagers, given the accuracy of the current approach. We are looking at what effects the tool would have on a triager's duplicate detection accuracy and their workload.

Future plans include implementing the tool as a Firefox extension.

If you are interested in participating in the study or would like to be notified when the tool becomes available, email Lyndon Hiew.

 

Publications

Revision 62006-03-03 - murphy

Line: 1 to 1
 

Bug Triage

General Overview

Line: 17 to 17
 Our work as been published at a number of venues. See our publications listing below.
Added:
>
>		John Anvik, Lyndon Hiew and Gail Murphy (OK, lousy way to put people on this - other suggestions?)
 

Bug Report Assignment

Deleted:
<
<

Overview

As a means of reducing the time spent triaging and improving the triage process, we are developing and validating a machine-learning approach for semi-automating one part of the process: the assignment of a developer to a newly received report.
 
Changed:
<
<		For more detailed information about this project, contact John Anvik.
>
>		One step in bug triaging is assigning a developer to a newly received report. We are developing an approach for semi-automating this assignment. Our approach uses a machine-learning algorithm that is applied to the information about how bugs have been assigned in the past to recommend developers to whom a new bug should be assigned.
 
Changed:
<
<

Bug Assignment Tool

In the near future, we plan to have an assignment tool available that provides a list of recommendations for the following projects:
>
>		In the near future, we will have an assignment tool available that provides a list of recommendations for the following projects:
 
  • Eclipse Platform
  • Firefox Browser
Line: 33 to 32
 
  • A Firefox extension.
  • An Eclipse plug-in.
Changed:
<
<		Please contact John Anvik if you wish to be informed when the tool becomes available.

Using the Bug Assignment Tool with Other Projects

If you would like to use the tool for a project not listed above, please contact John Anvik. Your project must meet the following conditions for consideration:
>
>		E-mail John Anvik if you wish to be informed when the tool becomes available of if you would like to find out if you can use the tool on another project. Note, your project must meet the following conditions to be applicable for our tool:
 
  1. Uses Bugzilla (V.2.16 or higher) for tracking bug reports where the default layout for bug reports has not been altered.
  2. The project contains more than 20 developers who actively fix bugs.
  3. The project had 1000+ reports marked as FIXED in the last 8 months.

Revision 52006-03-02 - JohnAnvik

Line: 1 to 1
 

Bug Triage

General Overview

Line: 37 to 37
 

Using the Bug Assignment Tool with Other Projects

If you would like to use the tool for a project not listed above, please contact John Anvik. Your project must meet the following conditions for consideration:
Changed:
<
<
  1. Uses Bugzilla for tracking bug reports where the default layout for bug reports has not been altered.
>
>
  1. Uses Bugzilla (V.2.16 or higher) for tracking bug reports where the default layout for bug reports has not been altered.
 
  1. The project contains more than 20 developers who actively fix bugs.
  2. The project had 1000+ reports marked as FIXED in the last 8 months.

Revision 42006-03-02 - JohnAnvik

Line: 1 to 1
 

Bug Triage

General Overview

Line: 22 to 22
 

Overview

As a means of reducing the time spent triaging and improving the triage process, we are developing and validating a machine-learning approach for semi-automating one part of the process: the assignment of a developer to a newly received report.
Changed:
<
<		In the near future, we plan to have the tool available to help
>
>		For more detailed information about this project, contact John Anvik.

Bug Assignment Tool

In the near future, we plan to have an assignment tool available that provides a list of recommendations for the following projects:
  • Eclipse Platform
  • Firefox Browser

The tool will be provided in two formats:

  • A Firefox extension.
  • An Eclipse plug-in.

Please contact John Anvik if you wish to be informed when the tool becomes available.

Using the Bug Assignment Tool with Other Projects

If you would like to use the tool for a project not listed above, please contact John Anvik. Your project must meet the following conditions for consideration:
  1. Uses Bugzilla for tracking bug reports where the default layout for bug reports has not been altered.
  2. The project contains more than 20 developers who actively fix bugs.
  3. The project had 1000+ reports marked as FIXED in the last 8 months.
 
Deleted:
<
<		For more information about this subproject, contact John Anvik
 

Duplicate Detection

Line: 32 to 48
 to be written - Lyndon

Deleted:
<
<		 Gail - In general, order publications by most recent first.
 

Publications

Deleted:
<
<
 
Added:
>
>

 

Revision 32006-03-02 - murphy

Line: 1 to 1
 

Bug Triage

General Overview

Changed:
<
<		Most open source software development projects incorporate an open bug repository that allows both developers and users to post problems encountered with the software, suggest possible enhancements, and comment upon existing bug reports. One potential advantage of an open bug repository is that it may allow more bugs to be identified and solved, improving the quality of the software produced.
>
>		Open source software projects typically have a bug repository that allows both developers and users to post problems encountered with the software, suggest possible enhancements, and comment upon existing bug reports. Popular open source projects receive lots of bug reports.
 
Changed:
<
<		However, this potential advantage also comes with a significant cost. Each bug that is reported must be triaged to determine if it describes a meaningful new problem or enhancement,
>
>		Since more bugs are reported than can be easily handled, each bug must be triaged to determine if it describes a meaningful new problem or enhancement,
 and if it does, it must be assigned to an appropriate developer for further handling.
Changed:
<
<		We seek to improve the bug triage process by understanding the triage process and creating tools that support triagers in making their decisions about bug reports. The various subprojects that we are working on are:
>
>		We are investigating approaches to help automate two parts of the bug triage process:
 
Line: 25 to 22
 

Overview

As a means of reducing the time spent triaging and improving the triage process, we are developing and validating a machine-learning approach for semi-automating one part of the process: the assignment of a developer to a newly received report.
Added:
>
>		In the near future, we plan to have the tool available to help
 For more information about this subproject, contact John Anvik

Line: 33 to 32
 to be written - Lyndon

Added:
>
>		 Gail - In general, order publications by most recent first.
 

Publications

Revision 22006-03-01 - JohnAnvik

Line: 1 to 1
 

Bug Triage

General Overview

Changed:
<
<		Most open source software developments incorporate an open bug repository that allows
>
>		Most open source software development projects incorporate an open bug repository that allows
 both developers and users to post problems encountered with the software, suggest possible enhancements, and comment upon existing bug reports. One potential advantage of an open bug repository is that it may allow more bugs to be identified and solved, improving the quality of the software produced.

However, this potential advantage also comes with a significant cost. Each bug that is reported must be triaged to determine if it describes a meaningful new problem or enhancement, and if it does, it must be assigned to an appropriate developer for further handling.

Deleted:
<
<		Consider the case of the Eclipse Platform open source project over a four month period (January 1, 2005 to April 30, 2005) when 3426 reports were filed, averaging 29 reports per day. Assuming that a triager takes approximately five minutes to read and handle each report, two person-hours per day is being spent on this activity. If all of these reports led to improvements in the code, this might be an acceptable cost to the project. However, since many of the reports are duplicates of existing reports or are not valid reports, much of this work does not improve the product. For instance, of the 3426 reports for Eclipse, 1190 (36\%) were marked either as invalid, a duplicate, a bug that could not be replicated, or one that will not be fixed.
 
Changed:
<
<		We seek to improve the bug triage process by understanding the triage process and creating tools that support triagers in their decisions about bug reports.
>
>		We seek to improve the bug triage process by understanding the triage process and creating tools that support triagers in making their decisions about bug reports.
 The various subprojects that we are working on are:

Changed:
<
<		Our work as been published in a variety of venues.
>
>		Our work as been published at a number of venues. See our publications listing below.
 

Bug Report Assignment

Overview

Changed:
<
<		to be written - John
>
>		As a means of reducing the time spent triaging and improving the triage process, we are developing and validating a machine-learning approach for semi-automating one part of the process: the assignment of a developer to a newly received report.

For more information about this subproject, contact John Anvik

 

Duplicate Detection

Line: 39 to 34
 

Publications

Changed:
<
<
>
>
 

Revision 12006-02-28 - JohnAnvik

Line: 1 to 1
Added:
>
>

Bug Triage

General Overview

Most open source software developments incorporate an open bug repository that allows both developers and users to post problems encountered with the software, suggest possible enhancements, and comment upon existing bug reports. One potential advantage of an open bug repository is that it may allow more bugs to be identified and solved, improving the quality of the software produced.

However, this potential advantage also comes with a significant cost. Each bug that is reported must be triaged to determine if it describes a meaningful new problem or enhancement, and if it does, it must be assigned to an appropriate developer for further handling. Consider the case of the Eclipse Platform open source project over a four month period (January 1, 2005 to April 30, 2005) when 3426 reports were filed, averaging 29 reports per day. Assuming that a triager takes approximately five minutes to read and handle each report, two person-hours per day is being spent on this activity. If all of these reports led to improvements in the code, this might be an acceptable cost to the project. However, since many of the reports are duplicates of existing reports or are not valid reports, much of this work does not improve the product. For instance, of the 3426 reports for Eclipse, 1190 (36\%) were marked either as invalid, a duplicate, a bug that could not be replicated, or one that will not be fixed.

We seek to improve the bug triage process by understanding the triage process and creating tools that support triagers in their decisions about bug reports. The various subprojects that we are working on are:

Our work as been published in a variety of venues.

Bug Report Assignment

Overview

to be written - John

Duplicate Detection

Overview

to be written - Lyndon

Publications

View topic | History: r8 < r7 < r6 < r5 | More topic actions...
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback