Article Preview
Top1. Introduction
During the maintenance phase of large open source software projects, issues and defects usually show up. Bug reports are submitted to document these defects. The bug report includes the issue’s information; such as bug id, summary, reporter name, severity, priority and submission date. Issue tracking systems (ITS) such as Bugzilla (Bugzilla, 2014) and Jira (Jira Software, n.d.) are used to manage and track the submitted reports (A. Hamdy & G. Ezzat 2020). Bug triage process is the assignment of each bug report to one of the developers, who is qualified enough to fix the assigned bug (Alenezi, Banitaan, & Zarour, 2018). A triager (personnel) analyzes each of the submitted bug reports and the developers’ profiles to assign each developer to a bug report based on their experience and skills. Manual triage is a time-consuming process; the trigger, as a human, is not able commit to memory the qualifications of each developer and the skills required in each bug report; specially with the massive number of submitted bug reports to the ITS. For example, in November 2019, Eclipse ITS recorded 500,000 issue report (Anvik, Hiew, & Murphy, 2006) and 1,600,000 issue report are submitted in Mozilla repository. Also, 800,000 issue reports are received by Mozilla in October 2012, with around 300 new changes every day (Anjali, January 2015). These numbers indicate how this problem is sophisticated with respect to human resources and financial aspects. What makes it more complicated is the tossing actions. Tossing a bug report is a process of reassigning it to another developer in case the first one failed to solve it. Around 37% of the received bug reports go in reassignment (tossing) process (Gondaliya, Peters, & Rueckert, 2018). These tossing actions not only waste financial and human resources but also it delays the fixing time. In other words, an overloaded developer can take much time to address the problem, also a less qualified developer may fail to fix the assigned bug. In both cases the bug requires longer time to be fixed. Accordingly, more human and financial recourses will be required. Therefore, tossing actions should be minimized as much as possible.
The essential point behind the triage problem is assigning the bug report to the developer who is definitely able to make the required changes. Given the above-mentioned statistics, it is clear that a triager cannot equally distribute the newly submitted bugs over the developers. In addition, there may be sever issue that have critical consequences on the whole project. Thus, incorrect assignments decisions may lead to an increase in the fixing time and cost. Also, inaccurate assignment between the developers and bug reports waist the human resources, because of the tossing actions. According to the National Institute of Standards and Technology, handling software bugs requires over $59.5 billion per year (NIST, May 2002). Additionally, in Aka company, the payment of a senior bug fixer is $129,328 per year (Glassdoor, n.d.). Because of these big numbers, triaging systems must be optimized.
This paper summarizes and compares among the previous bug triage approaches, in a period from 2006 to 2022. The main contribution is summarized in a four-fold:
- •
Summarizing the state of art into a categorization schema; showing the model, algorithms, datasets used for each paper and results concluded by each of them.
- •
Providing a comparative analysis among previously published research papers.
- •
Introducing an experimental comparison for the performance of five classifiers in developer prediction.
- •
Providing some open discussion, which leads to find a gap to work on, in the future.