# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 3 Issue Tracking Space
Having analyzed a wide scope of ITS repositories [12], we found that depending upon the project, issue attributes and their values may differ partially or significantly. Usually, within the same project, they are stable; however, some fluctuation may appear in time, e.g., due to ITS system upgrades, project organization and development improvements, project actors' fluctuations, etc. In practice, issue reporting deficiencies may also occur, e.g., wrong or lacking attribute specifications. Details of issue reports rely on the used ITS tools (e.g., Jira, Bugzilla, Mantis, etc. ), the project manager guidelines, stakeholders' responsibilities, and competence, etc. Issues registered in ITS include software bugs, requests for new functionalities or performance improvement, development tasks (e.g., code merging), unexpected problems, etc. Issue processing depends upon their types, the accuracy of their description, priorities, and other attribute specifications. This is also influenced by the capabilities of project stakeholders engaged in resolving the considered issue. Hence, in practice, we observe diverse sequences of issue processing actions (phases) which impact handling times. Usually, they relate to details associated with the considered issue. Some issues may have greater urgency than others, due to their priorities or them blocking the processing of other issues. On the other hand, low-urgency issues can be resolved as time permits. Issue description accuracy also impacts resolution time, e.g., requests to provide additional comments and mutual interactions of actors. Our previous studies on handling software bugs in many projects [13] showed a high diversity of processing schemes (state paths) and handling times. We found the need for deeper studies on assessing issue handling processes. Hence, an appropriate framework is needed to extract useful knowledge in a systematic way. It has been enhanced with metrics adjusted to diverse investigation aspects and combined with introduced analysis algorithms. The backbone of this analysis is the introduced original issue handling model (IHM) enhanced with assessment metrics/profiles adapted to specified observation perspectives, e.g., general issue resolution effectiveness, detailed issue processing states and patterns, timing features, and project actor interactions. Additionally, it provides a graphical visualization of the issue processing flow. The IHM is integrated with the issue database which comprises characteristic data extracted from the ITS repository. Depending upon the project, the number of issue attributes is in the range of a few dozen to more than 100. However, only some of them can be useful in the analysis [12]. The ITS records individual issue features to provide project actors with information on their processing. Issue data are acquired using appropriate REST APIs of the ITS. These APIs1 usually ensure access to a limited number of issues (e.g., 1000), so they have been extended to complete the specified number of issues (or relevant observation period) and store them in a uniform structure in a separate database (MongoDB) for each project. It is important to derive required data and store them in a structured and compact format adapted to further processing. The developed original analysis algorithms refer to the introduced IHM's graphical objects and their relations. They trace sequences (paths) of issue handling steps, issue timing, and other category features stored in the database. Here, we distinguish explicit issue attribute values (e.g., issue type, priority) and derived features: the number and categories of comments, the size of the issue description, issue looping characteristics, other specified properties, etc. This approach allows us to monitor the issue handling time, check compliance with assumed workflows, and perform diverse statistical analysis.