Assigning bug reports using a vocabulary-based expertise model of developers

Matter, Dominique; Kuhn, Adrian; Nierstrasz, Oscar

doi:10.1109/msr.2009.5069491

Cited by 178 publications

(129 citation statements)

References 25 publications

Supporting

Mentioning

128

Contrasting

Unclassified

Order By: Relevance

“…It is interesting to note that the names of the developers who fixed the issue in question are not present in the official maintainers list of the kernel for releases 3.11 nor 3.12. Through this scenario, we suggest that the FEVER database can be of use to identify feature expertise, and possibly facilitate bug triaging (Matter et al 2009). A maintainer in charge of bug triage may use a simple query with information on potentially faulty features to find which developers can provide insight on an issue or even fix it.…”

Section: Fever For Software Development Activitiesmentioning

confidence: 99%

“…To alievate some of those issues, several approaches have been designed to facilitate the identification of experts capable of fixing a bug (Ahsan et al 2009;Matter et al 2009). Most of those solutions rely on previous fixes to determine, based on bug report content, who is the most likely to be able to provide an answer to a bug report.…”

Section: Fever For Software Development Activitiesmentioning

confidence: 99%

See 1 more Smart Citation

FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

2017

View full text Add to dashboard Cite

The evolution of highly configurable systems is known to be a challenging task. Thorough understanding of configuration options their relationships, and their implementation in various types of artefacts (variability model, mapping, and implementation) is required to avoid compilation errors, invalid products, or dead code. Recent studies focusing on co-evolution of artefacts detailed feature-oriented change scenarios, describing how related artefacts might change over time. However, relying on manual analysis of commits, such work do not provide the means to obtain quantitative information on the frequency of described scenarios nor information on the exhaustiveness of the presented scenarios for the evolution of a large scale system. In this work, we propose FEVER and its instantiation for the Linux kernel. FEVER extracts detailed information on changes in variability models (KConfig files), assets (preprocessor based C code), and mappings (Makefiles). We apply this methodology to the Linux kernel and build a dataset comprised of 15 releases of the kernel history. We performed an evaluation of the FEVER approach by manually inspecting the data and compared it with commits in the system's history. The evaluation shows that FEVER accurately captures feature related changes for more than 85% of the 810 manually inspected commits. We use the collected data to reflect on occurrences of co-evolution (2018) 23:905-952 in practice. Our analysis shows that complex co-evolution scenarios occur in every studied release but are not among the most frequent change scenarios, as they only occur for 8 to 13% of the evolving features. Moreover, only a minority of developers working on a given release will make changes to all artefacts related to a feature (between 10% and 13% of authors). While our conclusions are derived from observations on the evolution of the Linux kernel, we believe that they may have implications for tool developers as well as guide further research in the field of co-evolution of artefacts.Empir Software Eng

show abstract

Section: Fever For Software Development Activitiesmentioning

confidence: 99%

Section: Fever For Software Development Activitiesmentioning

confidence: 99%

FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

2017

View full text Add to dashboard Cite

show abstract

“…Anvik et al [6] removed unresolved, reopened defect reports and defect reports assigned to the developers who no longer worked there or inexperienced developers. Matter et al [20] used vocabulary found in source code.…”

Section: Features Used In Defect Report Triagementioning

confidence: 99%

A Survey on Automatic Defect Report Triage

Sayali¹,

S.²

2017

IJCA

View full text Add to dashboard Cite

“…Another recent approach to facilitate bug triaging uses graph based model based on Markov chains, which capture bug reassignment history [18]. Matter et al [25] used the similarity of textual terms between a given bug report of interest and source code changes (i.e., word frequencies of the diff given changes from source code repositories). A collection of past bug reports is not required by their approach.…”

Section: Related Workmentioning

confidence: 99%

Triaging incoming change requests: Bug or commit history, or code authorship?

Linares‐Vásquez

Hossen

Dang

et al. 2012

2012 28th IEEE International Conference on Software Maintenance (ICSM)

View full text Add to dashboard Cite

-There is a tremendous wealth of code authorship information available in source code. Motivated with the presence of this information, in a number of open source projects, an approach to recommend expert developers to assist with a software change request (e.g., a bug fixes or feature) is presented. It employs a combination of an information retrieval technique and processing of the source code authorship information. The relevant source code files to the textual description of a change request are first located. The authors listed in the header comments in these files are then analyzed to arrive at a ranked list of the most suitable developers. The approach fundamentally differs from its previously reported counterparts, as it does not require software repository mining. Neither does it require training from past bugs/issues, which is often done with sophisticated techniques such as machine learning, nor mining of source code repositories, i.e., commits.An empirical study to evaluate the effectiveness of the approach on three open source systems, ArgoUML, JEdit, and MuCommander, is reported. Our approach is compared with two representative approaches: 1) using machine learning on past bug reports, and 2) based on commit logs. The presented approach is found to provide recommendation accuracies that are equivalent or better than the two compared approaches. These findings are encouraging, as it opens up a promising and orthogonal possibility of recommending developers without the need of any historical change information.

show abstract

Assigning bug reports using a vocabulary-based expertise model of developers

Cited by 178 publications

References 25 publications

FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

FEVER: An approach to analyze feature-oriented changes and artefact co-evolution in highly configurable systems

A Survey on Automatic Defect Report Triage

Triaging incoming change requests: Bug or commit history, or code authorship?

Contact Info

Product

Resources

About