# Graph-Driven Exploration of Issue Handling Schemes in Software Projects
## 4 Exploring and Assessing Issue Handling Processes
### Issue Handling Model (IHM)
Having generated IHMs for many open source and commercial projects, we found that the graph complexity was relatively low: in most cases, the graph size was in the range of 25-48, \(indeg(V)\) was 1-3, \(outdeg(V)\) was 1-6, and graph density was 0.15-0.43. For one complex commercial project C [13] (telephone billing system), we obtained a graph comprising 26 states and 280 edges (graph density, 0.43). These values significantly reduce if we reject edges related to a low number of issues (restriction R). The IHM graph of the Mongo DB project (open source) covering issues with major priority (7488) comprises 17 nodes and 66 edges (d(G) = 0.24, indeg(V) = 0-11, outdeg(V) = 0-9)), and in case of issues with a higher priority blocker (54), it is reduced to 9 nodes and 25 edges (d(G) = 0.35, indeg(V) = 0-7, outdeg(V) = 1-5). As a consequence, algorithms tracing issue handling (e.g., finding all possible paths and loops) are simpler than classical ones. Issues can be processed sequentially according to IHM states (nodes). The state S\({}_{j}\) payload can be measured as the issue inflow \(IF(S_{j})\), i.e., the number of all issues entering state S\({}_{j}\):  
\[IF\big{(}S_{j}\big{)}=\sum_{i\in I}\left(n_{ij}\right)+dp\big{(}S_{j}\big{)} \tag{4}\]  
where \(n_{ij}\) is the number of issues passing the edge \(e_{ij}\) from state S\({}_{i}\) to S\({}_{j}\), I = {i: < S\({}_{i}\), S\({}_{j}>\)? E}, and dp(S\({}_{j}\)) is the direct payload, i.e., the number of issues introduced directly to state S\({}_{j}\) by reporters. In practice, this appears in the initial IHM state, while for other states, it is observed very rarely (Section 5.3). Issue inflow can also be conditioned by specified issue restriction R, as in IHM specification (2). The significance of states in issue handling can be characterized by the state load (s\(l\)), state weight (\(sw\)) and state redundancy (\(sr\)) profiles defined as follows:  
\[sl(S_{i})=IF\big{(}S_{j}\big{)}/N \tag{5}\] \[sw(S_{i})=\sum_{p\in P}n\big{(}S_{i},\ P_{j}\big{)}\ /|P|\] \[sr(S_{i})=\left[IF(S_{i})-UI(S_{i})\right]/IF(S_{i})\]  
where P\({}_{j}\) denotes the issue handling path from the set of all possible paths P, defined as the sequence of states involved in processing issues (Section 5.2); \(\left|\left.P\right|\right.\) is the cardinality of set P; \(n\big{(}S_{i},\ P_{j}\big{)}\) denotes the number of state S\({}_{i}\) appearances in path P\({}_{j}\); and \(UI(S_{i})\) is the number of unique issues handled in state S\({}_{i}\). These profiles can be adapted to issue restrictions R of the IHM graph. The \(sw\) profile reflects the impact of state S\({}_{i}\) activity in all paths, while \(sl\) shows the ratio of issues handled in state S\({}_{i}\). The profile \(sr\) identifies issue looping (\(sr(S_{i})>0\)--issue processing returned to state \(S_{i}\)). We can also use profile vectors (over states) or aggregated state profiles defined as  
\[ASx=\sum_{S_{i}\in S}sx(S_{i}) \tag{6}\]  
where \(x\) specifies profile type (5), with \(l,w\) and \(r\) corresponding to state load, weight and redundancy, respectively. Deeper analysis combines detailed issue parameters from the ITS repository with IHM features using the developed algorithms described in Section 4.3.