# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 5 Experimental Results and Analysis
### Statistics Related to Processing States  
The basic IHM state parameters are the state entry and exit times of processed issues. Here, the problem of issues still being processed in the considered state needs to be considered. We can either neglect such issues or assume the exit time to be equal to the repository's final time stamp. Another possibility is attributing zero handling time to these issues. Fortunately, when dealing with repositories comprising many issues, such situations rarely appear. Some consideration is required regarding terminal states, e.g., _closed_, which should specify the completion of issue handling, so transitions to another state may not appear. However, sometimes we observed state changes from the _closed_ state. The basic state features of IHM can be extended by considering state change profiles (e.g., probabilities of transitions to subsequent states) and actor activities (e.g., exchanging comments), etc. Some of these are commented upon in subsequent subsections. Issues attributed to a selected IHM state are processed by assigned actors and, depending on the results, are transferred to a subsequent state. Tracing the time statistics of handling issues in IHM states, we can derive relevant time profiles defined by minimal, maximal, average, and Q1-Q3 quartile values. Creating these profiles, we can consider diverse restrictions, e.g., issue types (all issues, bugs, new functionalities), issue priorities, and project time ranges. As an illustration, in Table 3, we present a sample of state time profiles (Q2 and Q3 quartiles specified in days) related to all software bug issues (1896) in the Log4J2 project. It is reasonable to correlate state time profiles with the number of processed issues within these states. Sometimes, an issue is processed in the state more than once (looping), and hence we present two parameters: N\({}_{\text{S}}\)--the number of processed issues in state S; and U\({}_{\text{S}}\)--the number of unique issues (U\({}_{\text{S}}\leq\) N\({}_{\text{S}}\)). In the state R_F, looping covered (N\({}_{\text{S}}-\) U\({}_{\text{S}}\)) = 67 issues (this problem is analysed in Section 5.2.2). State specifications in the first column of the table are consistent with Jira; moreover, we introduced acronyms which are used in the subsequent text. Maximal handling times ranged from 148 up to several thousand days (typically several hundreds). For the highest-priority bug issues, the parameters Q2 and Q3 were in the ranges of 0.2-2 and 0.2-27 days (mostly below 10), respectively (maximal values ranged from a few days up to 150). It is worth noting that high values of maximal processing time may relate to postponed bugs considered as having a negligible impact (however, they may contribute to so-called bug debt). They may also have a significant impact on the increased average values, so the Q2 and Q3 parameters can be more representative. The derived statistics can cover all registered issues (as in Table 2) or only the completed ones. In practice, the latter issues provide almost the same values (sometimes with higher maximal values). Typically, higher-priority issues are handled more effectively (lower time values: Q3 for blocker issues of 1-17 days and maximal values of 1-610 days). Parameter Q3, as compared with Q2, is typically 5-10 times higher for states handling a larger number of issues (in case of lower numbers, this is not as regular). Maximal values may exceed Q3 by over 100 times.