A Motivating Example
Let us present a motivating example in our collected data that leads to our
approach. Figure 1 depicts a bug report from Eclipse dataset, with the relevant
fields including the fixing developer (AssignedTo), a short summary (Summary),
and a full description (Description) of the bug.
Click here for full
bug report #6021
The bug report describes an issue that the layout of the wizard for CVS
repository connection was not properly implemented. Analyzing Eclipse’s
documentation, we found that this issue is related to a technical aspect:
version control and management (VCM) for software artifacts. This aspect of
VCM can be recognized in the report’s contents via its descriptive terms such as
CVS, repository, connection, and path. It is project-specific since not all
systems have it. Checking the corresponding fixed code in Eclipse, we found that
the bug occurred in the code implementing an operation of VCM: CVS repository
connection. The bug was assigned to and fixed by a developer named James
Moody.
Searching and analyzing other Eclipse’ bug reports, we found that James
also fixed several other VCM-related bugs, for example, bug #0002 (Figure 2).
The description states that the system always used its default editor to open
any resource file (e.g. a GIF file) regardless of its file type. This aspect of
VCM is described via the terms such as repository, resource, and editor. This
observation suggests that James Moody probably has the expertise, knowledge, or
capability with respect to fixing the VCM-related bugs in Eclipse.
Click here for full
bug report #0002
This example suggests us the following:
-
A software system has several
technical aspects. Each could be associated with some descriptive technical
terms. A bug report is related to one or multiple technical aspects.
-
If a
developer frequently fixes the bugs related to a technical aspect, we could
consider him to have bug- xing expertise/capability on that aspect, i.e., he
could be a capable/ competent fixer for a future bug related to that aspect.
Based on those two implications, we approach to solve the problem of automated
bug triaging using the following key philosophy:
"Who have the most bug-fixing
capability/expertise with respect to the reported technical aspect(s) in a
given bug report should be the fixer(s)".
