# Probabilistic Model Checking GitHub Repositories for Software Project Analysis
## 4 Experimental Results
### Participant Analysis  
#### 4.3.1 Individual Participants  
In the context of GitHub, individual contributors are individuals who typically contribute to open-source projects by making various types of contributions to improve and expand the software. These contributions play a significant role in the development and maintenance of the software. Therefore, it is essential to analyze the behavior patterns of each participant over time to gain insights into their activity and contribution patterns and encourage participation. In this section, we analyze the behavioral patterns of participants over time to understand their activity levels and contribution patterns.  
\[R\{\text{``}r\_steps\text{''}\}=?[F\ participant] \tag{11}\]  
Query (11) calculates the average time steps it takes for each participant to appear in the project using the reward structure. A lower result indicates that a participant joined the project relatively quickly. Figure 8 shows the results for all participants, grouped by repository. DeSolver, kafkaVision, and Redline show minimal differences among participants, while Sherlogs and Hearth exhibit significant variation among participants. Significant differences suggest variations in the timing of participant activity within the project. For example, the distribution for Redline indicates that most participants joined at similar times. With the exception of Hearth, most repositories have lower values for p1, suggesting that early participants were more proactive than later participants.  
\[\begin{array}{c}filter(avg,R\{\text{``}r\_participant\_branch\_commit\text{''}\}\\ =?[F(participant)\&(\text{``}pullrequest\text{''})],(participant)\&(\text{``}create\text{''}))\end{array} \tag{12}\]  
Query (12) calculates the number of commits made by participants from branch creation to pull requests using the \(r\_participant\_branch\_commit\) reward structure. On average, participants make approximately 3.35 commits before creating a pull request. Figure 9 presents the results for each repository using box plots.  
In the case of Redline, participants made the fewest commits before creating pull requests. This type of query provides insights into team development processes, helps evaluate compliance with commit rules and conventions, and may reveal how frequently commits are required for feature development.  
Figure 8: Result of Query 11: Average time steps for participant appearance.  
\[P=?[F<=K\;(participant)\;\&\ ``commit\"] \tag{13}\]  
Query (13) calculates the probability of participants making a \"commit\" within \(K\) steps. Varying values of \(K\) allow us to analyze the probability of participants making commits within different timeframes. Figure 10 shows the results for \(K\) values ranging from 1 to 50, broken down by repository.  
Figure 10: Result of Query 13: Probability of making a commit over time steps.  
Figure 9: Result of Query 12: Average number of commits on branch before pull request.  
Higher probabilities early in the steps suggest a higher likelihood of participants making commits quickly. This figure enables us to speculate about when and with what probability certain participants are likely to make commits in the project. For example, in Sherlogs, p1 generally has a higher probability of making commits than p2. Another example is Redline's p1, which initially had a higher probability of making commits than p2 but saw a reversal after \(K=13\), indicating that p2 had a higher probability of making commits.