Bug triaging assigns a bug report, which is also known as a work item, an issue, a task or simply a bug, to the most appropriate software developer for fixing or implementing it. However, this task is tedious, time-consuming and error-prone if not supported by effective means. Current techniques either use information retrieval and machine learning to find the most similar bugs already fixed and recommend expert developers, or they analyze change information stemming from source code to propose expert bug solvers. Neither technique combines textual similarity with change set analysis and thereby exploits the potential of the interlinking between bug reports and change sets. In this paper, we present our approach to identify potential experts by identifying similar bug reports and analyzing the associated change sets. Studies have shown that effective bug triaging is done collaboratively in a meeting, as it requires the coordination of multiple individuals, the understanding of the project context and the understanding of the specific work practices. Therefore, we implemented our approach on a multi-touch table to allow multiple stakeholders to interact simultaneously in the bug triaging and to foster their collaboration. In the current stage of our experiments we have experienced that the expert recommendations are more specific and useful when the rationale behind the expert selection is also presented to the users.
"Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org."
Our approach is based on the assumption that for any unassigned bug, a developer who has previously addressed textually similar bugs (i.e. a higher cosine similarity between the two bugs), has a higher expertise than someone who has addressed less textually similar bugs. Thus, for the expertise recommendation, we first retrieve textually similar bugs and then determine the experts based on the change sets which are associated to the textually similar bug reports (see fig. 1).
Our prototypical implementation offers a bug management perspective (see fig. 2a), which allows to organize and edit the bugs related to a project. Once the team decides to triage a specific bug, the button Analyze (see rectangle 1 in fig. 2a) displays the bug analysis perspective (see fig. 2 b), which displays textually similar bugs (see rectangle 1 in fig. 2b) along with the associated change sets (see rectangle 2 in fig. 2b) and the developers who commited these change sets (see rectangle 3 in fig. 2b).