# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 4 Exploring and Assessing Issue Handling Processes
### Issue Handling Summary  
The efficiency of handling issues can be assessed according to the distribution of issue handling times. For each issue, we derive the timestamp of its registration and resolution. The issue resolution needs to be commented upon; theoretically, it should relate to a _closed_ state. However, quite often, this state is skipped, so in the case of the last _resolved_x_ state (x denotes the resolution method) not being succeeded by the _closed_ one, we take its time stamp as the terminal handling time. Another problem relates to issues for which handling processes did not terminate in the considered repository time scope. Hence, deriving timing distributions, we obtain two numbers, namely that related only to the terminated issues (suffix A) and that considering the remaining issues as terminated at the last time stamp of the analysed repository (suffix B). Some illustrative statistics are shown in Table 1: the number of considered issues (N) and the average (AVG), maximal (MAX), and Q2 and Q3 quartiles of issue handling times. For each project, these statistics are calculated considering two cases of issue processing termination (suffix A or B). The results for the open source projects MongoDB and Log4J2 relate to all reported issue types: _Bugs_, _New Feature_, _Improvement_. In the case of the commercial project P1, _New Feature_, _User Story_, and _Task_ issue types were considered. a decreasing ratio of unresolved issues is required. This can be achieved by optimizing the number of issue handling actors and improving the efficiency of this process. The presented shape of the plots in Figure 1 was similar to many other projects; however, the rate of unresolved issues (e.g., postponed) fluctuated in the range of a few percent up to 40%, and for some projects, a low percentage was observed in the initial phase of the project and then increased or fluctuated. In the developed commercial project P1, the rate of unresolved issues fluctuated around 5%. In practice, issues have diverse impacts on project quality and usability. Hence, it is important to rapidly resolve the most critical ones. In the analysed P1 project, they constituted below 1% of the total, and absolute values reached one to five issues per year. This was simple to ensure due to the low number of high-priority issues. In the analysed open source projects Casandra, Flink, Spark and Mozilla, we observed fewer than 10, 50, 80, and 100 of unresolved issues of the two highest priorities, which constituted less than 1% of the total. Moreover, the handling times of these issues were lower than the others. On the other hand, we can observe postponing the resolution of low-level priority (e.g., cosmetic) issues. This may cause the so-called effect of bug debt [22; 38]. This leads to overlooking important problems due to the false qualification of issue priority and the combined impact of many postponed issues, which may also be triggered in correlation with code upgrades or system configuration changes. Dealing with this problem, we introduced an algorithm which detects a significant increase in such postponed issues and initiates their investigation, targeted at searching for suspicious ones to check their criticality [22]. This analysis is performed with issue description text mining based on machine learning algorithms. The output of this analysis is the set of suspicious issues needing deeper analysis. Some experiments with several projects showed that the algorithm filtered out only several percent of postponed issues as suspected, deeper analysis was restricted only to these issues, and it confirmed that 80-90% of them were critical. Resolving issues triggers the activities of diverse project contributors (e.g., testers, analyst, developers). It is able to control their workload and efficiency. This can be traced in correlation with the IHM discussed in Section 4.2.