## 4 Results
### Cox Proportional-Hazards Model  
We fit the categorical attributes that we used in the earlier analyses to a Cox Proportional-Hazards model to estimate the effect of these attributes on the resolution times of SStuBs in open source repositories. While the Kaplan-Meier curves show a statistically significant difference in resolution times based on the presence and absence of these attributes, quantifying the differences can further aid in establishing which attributes impact the resolution times the most. [PERSON] et al. applied the Cox Proportional-Hazards model to good effect and used it to quantify the impact of the number of releases, developer count, and hosting services used, on the overall health of an open-source project [35]. [PERSON] et al. used Cox models to determine the characteristics of cloned code that have the highest impact on software defects when analyzing ArgoUML and Ant systems [36]. Because the Cox Proportional-Hazards model is adept in quantifying hazard for recurrent events, it is suitable for determining the effects on SStuB resolution times in an ever-evolving software repository where multiple bugs are introduced and fixed over time. In survival analysis, a hazard ratio describes the measure of the effect of some intervention, on the outcome of an event, over time. For our project, the intervention is the attributes associated with a bug commit and the outcome is the bug resolution time. We use the ratios generated after fitting our data with the Cox PH model to explain the impact of each attribute. All confidence intervals are statistically significant. Table 1 gives the confidence interval for the ratio per attribute. Here, we are interested in how bugs introduced during work hours, on the weekends, and scale of the project, affect the overall resolution time. We also measure how the resolution times change if the developer who first introduced the bug is also the one to fix it. This scenario is represented by the \"same  
Figure 6: Kaplan–Meier estimations of the survival function for the scenario when bugs are authored and committed by the same developer. author\" attribute. As shown in Table 4, we find that bugs are fixed 1.71 times faster across all projects if they are fixed by the developers who originally introduced those bugs as well. For open-source projects, developers work on their copy of a project branch and commit their changes periodically [37]. Fixing bugs introduced by another developer's code change would require one to analyze the change description, the quality of which has been shown to affect how developers understand the code change [38]. In the 2019's Stack Overflow Developer Survey, 68.8% of responders said that they do code review for work and see value in it [39]. The result from the model builds on this confidence in the code review process and the data shows that SStuBs were found to have been fixed more than 100 days quicker, normalized by project size, when the developers were fixing their own mistakes. The \"bug into. work hours\" and \"bug intro. weekend\" attributes shown in Table 4 focus on a developer's committing patterns in these repositories. Open source software development involves a significant amount of volunteer work and it can be the case that developers make their contributions either after their work hours or over the weekend. We compare buggy commits that were introduced between 9 AM and 5 PM versus those that were not, and compare bugs introduced between Monday and Friday against those introduced on Saturday and Sunday. In our data, 12% SStuBs were submitted over the weekend and 63% of all SStuBs were introduced during work hours. The Cox PH model finds that SStuBs introduced during work hours are fixed slightly slower and those introduced over the weekend are fixed slightly faster. Even though the results are significant, the impact measured is not big enough to conclude that bugs introduced during work hours or over the weekend are more likely to remain unfixed for a longer period of time.