# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 2 Literature Review and Problem Statement
Often, issue descriptions are not clear, so diverse comments are added to ITS reports. Depending upon the project, diverse types of comments and communication functions can be used [26]. The automatic classification of comments was presented in [10; 22]. In issue handling, the problem of allocating issues to appropriate persons for resolution arises, referred to as the triaging problem. Some studies propose adopting machine learning and information retrieval techniques to identify suitable fixers for a given bug report. [PERSON] et al. [8] consider the textual content and metadata in the bug reports (e.g., product, component) and the tossing sequence of the bug reports. The selection of the right team for the project is an important problem [27]. The number of project actors involved in a tossing sequence impacts the issue fixing time. Developer rankings are based on developers' competence, contributions, and the achieved average fixing time. A logistic regression classifier including the simple textual and categorical attributes of the bug reports ensured high precision and recall (close to 80%) in bug triaging [28]. The categorical attributes included the product, customer, site, priority, issue reporter, configuration, and project generation. Most bug triaging approaches have focused on static tossing graphs, while [PERSON] et al. [29] considered interactions among developers. Historical data in software repositories are useful in diverse predictions [30]. Timing features of reported bugs or their frequency (defect arrival) facilitate predicting unrevealed defects or assessing software reliability. For this purpose, various probabilistic models have been proposed [11; 31]. Machine learning combined with the ensemble method was used in [31] and ensured high accuracy for 32 projects from three dataset repositories. The predictions were based on product and process metrics. Some approaches use the correlation of code complexity metrics and defect density. Software defect predictions can be performed within a project or across project scopes. Studies at the level of project versions are also possible [32], where a prediction model uses historical data derived by mining version control and issue tracking systems. The impact of feature selection and sampling techniques on the accuracy of software fault prediction model is discussed in [33]. Software reliability growth models (SRGMs) are used to predict defect appearance during software lifecycles [11]. Defect disclosure and defect resolution models are distinguished in [34]. Many studies focus on predicting which components might be defective [35]. The prediction accuracy depends upon extracting appropriate features from the software repository. Defects may result not only from incorrect code development but also from a mismatch between software behavior and requirements. Other predictions focus on specific problems, e.g., predicting questions raised by developers in an issue report [36], predicting the software component required to resolve an issue [35], and predicting bug fixing time [37]. The considered prediction models are based on coarse-grained defect handling schemes, so they neglect many real problems and do not ensure acceptable modeling accuracy. In practice, they restrict studies to bugs and do not consider a wider range of issues, e.g., their types and diverse attributes which have a significant impact on issue handling processes. Moreover, these features may change over time. Typical asymmetric Gaussian shapes of defect resolution in the project lifecycle (e.g., described in [34]) are not consistent with real project behavior and used development technologies (e.g., Scrum). Hence, a deeper and fine-grained issue handling analysis is needed. The presented literature survey showed diverse research studies focused on specific software engineering aspects considered separately. There is a gap in assessing the effectiveness of issue handling schemes covering all activities starting with the issue registration and leading to the final resolution.