As collaborative coding environments make it easier to contribute to software projects, the number of developers involved in these projects keeps increasing. Consequently, making it more difficult for code reviewers to deal with harmful contributions. Collaborative environments like GitHub provide a rich source of data on developers' contribution, which can be used to extract information on technical (e.g., developers' experience) and social (e.g., interactions among developers) factors related to developers. Recent studies analyzed the influence of these factors on different activities of the software development. However, there is still little knowledge on the relation between these factors and the introduction of bugs. We present a broader study on relating five technical, two social factors and the introduction of bugs. The results indicate that both technical and social factors present statistically significant relations with the introduction of bugs. Particularly, the developers' habits of not following technical contribution norms are associated with an increase on commit bugginess. Unexpectedly, the presence of tests in commits presents a relation with the increase of commit bugginess. Finally, the developer's experience presents a contradictory relation with the introduction of bugs. But, the analysis of both code complexity and developer's experience may explain this contradiction.
Rahman & Devanbu analyzed four open-source projects and found that high levels of ownership are associated with a lower bug introduction rate. Moreover, the authors found that specialized experience is consistently associated with buggy code, while general experience is not. Similar findings on the ownership factor were presented in the work of Bird @cite_21 . Thongtanunam @cite_7 show that there is a relationship between ownership and code review. In addition, the proportion of reviewers without expertise shares a strong relation with commit bugginess. Tufano @cite_28 presented an empirical study on developer-related factors. Their results show that commit coherence, developer experience, and past interfering changes are associated with commit bugginess.
@cite_28 @cite_21 @cite_7
2145574830 2374812233
Ownership is a key aspect of large-scale software development. We examine the relationship between different ownership measures and software failures in two large software projects: Windows Vista and Windows 7. We find that in all cases, measures of ownership such as the number of low-expertise developers, and the proportion of ownership for the top owner have a relationship with both pre-release faults and post-release failures. We also empirically identify reasons that low-expertise developers make changes to components and show that the removal of low-expertise contributions dramatically decreases the performance of contribution based defect prediction. Finally we provide recommendations for source code change policies and utilization of resources such as code inspections based on our results. Code ownership establishes a chain of responsibility for modules in large software systems. Although prior work uncovers a link between code ownership heuristics and software quality, these heuristics rely solely on the authorship of code changes. In addition to authoring code changes, developers also make important contributions to a module by reviewing code changes. Indeed, recent work shows that reviewers are highly active in modern code review processes, often suggesting alternative solutions or providing updates to the code changes. In this paper, we complement traditional code ownership heuristics using code review activity. Through a case study of six releases of the large Qt and OpenStack systems, we find that: (1) 67 --86 of developers did not author any code changes for a module, but still actively contributed by reviewing 21 --39 of the code changes, (2) code ownership heuristics that are aware of reviewing activity share a relationship with software quality, and (3) the proportion of reviewers without expertise shares a strong, increasing relationship with the likelihood of having post-release defects. Our results suggest that reviewing activity captures an important aspect of code ownership, and should be included in approximations of it in future studies.