# Probabilistic Model Checking GitHub Repositories for Software Project Analysis
## 4 Experimental Results
### Branch Management
#### 4.2.2 Pull Request Management  
After gaining insights into branch management, let us delve into pull request management. Pull requests are used to integrate changes made in branches into other branches, and they require code inspection and approval by reviewers before they can be merged.  
\[filter(avg,P=?[X\ \"accepted\"\ |\ \"rejected\"],\"pullRequest\") \tag{8}\]  
Query (8) is employed to calculate the average probability of immediate processing of pull requests to the next step. This helps examine the responsiveness to pull requests in each repository. The results are shown in Table 5.  
\[filter(state,P=?[X\ participant\ &\ (\"accepted\"\ |\ \"rejected\")], \tag{9}\]  
Query (9) expands upon (8) by adding a participant label to investigate the pull request processing probabilities of individual participants. Figure 6 presents a box plot showing the distribution of participants' pull request processing probabilities for each repository. This reveals that Redline exhibits a considerably fast processing rate for all the participants' pull requests. In the case of Hearth, there is relatively high variability in pull request processing among individual participants. Sherlogs shows that participants are distributed with relatively low probabilities.  
Figure 5: Results of Query 5, 6 and 7: Average cumulative number by branch location.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Repository** & **Probability** \\ \hline DeSolver & 64.05\% \\ kafkaVision & 78.34\% \\ Redline & 93.30\% \\ Sherlogs & 30.80\% \\ Hearth & 68.20\% \\ \hline \hline \end{tabular}
\end{table}
Table 5: Result of Query 8: Immediate processing rate of pull requests.  
\[filter(avg,P=?[F<=K\text{ ``}\text{accepted\" }|\text{ ``}\text{rejected\"}],\text{ ``}\text{ ``}\text{pullRequest\"}) \tag{10}\]  
Now, we look into predicting the future using \(F\) instead of the immediate next step \(X\). Query (10) calculates the pull request processing rate within \(K\) steps, using the constant \(K\). When \(K\) equals 1, it is equivalent to the immediate next step, resulting in the same outcome as (8). The results for \(K\) ranging from 1 to 35 are depicted in Figure 7. As expected, Sherlogs takes the longest to process pull requests, but by \(K=35\), it approaches a value close to 1, indicating that Sherlogs processes almost 100% of pull requests after 35 steps. An interesting observation from the graph is that each repository has different starting points and slopes. For example, Hearth initially had a lower pull request processing rate than kafkaVision up to \(K=4\), but from \(K=5\) it had a relatively higher processing rate.  
This section on pull request analysis provides insights into how promptly project administrators handle pull requests. A rapid processing rate might indicate quick action with minimal review, or it could suggest high interest in promptly reviewing and processing pull requests. Conversely, a slower processing rate might indicate less active management of pull requests, but it could also mean careful review and consideration before processing. Therefore, when interpreting the results of these queries, it is essential to consider the specific characteristics and trends of each project.  
Figure 6: Result of Query 9: Probability of processing of pull requests in the next step.  
Figure 7: Result of Query 10: Change in pull request processing probability over time steps.