# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 5 Experimental Results and Analysis
### Profiles of Issue Handling Paths
#### 5.2.2 Path Classification and Aggregation
In the case of the Log4j2 project, only five loops were identified for bug issues--each handled a single issue (in the brackets, we give the handling times in days):  
O, C, Reo, C, Reo, C, Reo, C (107.6); O, C, Reo, C, Reo, C (0.3); O,R_F, Reo, R_F, Reo, R_F, C (181.2); O,R_F, Reo, R_F, Reo, R_F, Reo, R_NP, Reo, R_NP, Rep, R_F, C (36.1). Deriving specified path classes, we can extract paths with searched features, comprising rare states or suspicious state transitions which require deeper studies. For example, in the commercial project P1 (period 2022), paths with _Need Info_ (3%/1%), _Reopen_ (56.9%/24.5%), and _Blocked_ (2.7%/1%) were extracted. Repetitions of these states within paths can be considered as concerning and requiring deeper investigation. Similarly, two-state paths terminated with the _Closed_ state are ambiguous. In Mongo DB, they constituted about 3% of bug issues, while in other open source projects, they constituted up to 6% of issues. Meanwhile, three-state paths, comprising _Initial state, In Progress_, and _Closed_, showed some information deficiencies (7% of bug issues). Studying these issues, we found some additional information in the included comments (e.g., invalid issue). Lacking states specifying issue resolution is not good practice (this state is not encountered in Mongo DB). Handling _New Feature_ and _Improvement_ issues showed a lower percentage of two-state paths (1%). In some projects, diverse versions of the _Resolved_ state appear, e.g., _Resolved_fix_, _Resolved_duplicate_, _Resolved_invalid_. The appearance of diverse _Resolved_ states within the same path shows some chaos in the handling process (can be treated as some type of looping), similarly to the _Reopen_ state--such situations are worth deeper investigation. We can also trace odd transition states in issue handing paths or those that confirm good practices. The path analysis algorithm developed provides the distribution of the next states for a specified state. It can only relate to direct successors or all successors until the end of the path. For example, in Mongo DB (bug issues) for the _Closed_ state, we identified nine diverse successive states; fortunately, such situations are rare (0.3% of issues). For the _In Code Review_ (69% of issues) state, we identified 12 successive states, but the dominant ones were _Needs Merge_ (18.3%), _In Progress_ (5.8%), _Open_ (5.7%), and _In Code Review_ (4.4%). For _New Feature/Improvement_ issues, these statistics were 22.8%, 8.8%, 8.2%, and 7.4%, respectively. This confirms some imperfections in the code review process; moreover, the code merging process is not clearly documented. Long paths may result in long handling times or a higher load of project actors (more people engaged in problem resolution). On the other hand, short paths may not reflect all issue processing activities. A high diversity of path structures is not consistent with typical activity sequences recommended in project development (Section 3). Some states are missing (e.g., verification, quality assurance, etc. ), while others are repeated. This results from reporting negligence, unrevealed issue dependencies, triaging shortcomings, actor fluctuations, etc. Comparisons of the derived statistics within the considered project life cycle and the different projects provide useful information for experts and project managers.