Revisiting code ownership and its relationship with software quality in the scope of modern code review

Thongtanunam, Patanamon; McIntosh, Shane; Hassan, Ahmed E.; Iida, Hajimu

doi:10.1145/2884781.2884852

Cited by 103 publications

(63 citation statements)

References 52 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Commit Ownership and RxJava. The results of the RQ3 show that the F3 metrics have a tendency to riskdecreasing effects on commit bugginess, as previously discussed in [8], [11], [13]. However, the CO metric presents a risk-increasing effect only in the RxJava project, reaching an increase in the odds of a commit being buggy by a factor of 2.11.…”

Section: Discussionsupporting

confidence: 67%

“…Only those metrics may be not sufficient to characterize the experience factor. For example, the developers' experience may increase as they participate in the code review process of a project [13], [18]. Therefore, we also use data about the code review process to characterize the developers' experience.…”

Section: A Technical and Social Factorsmentioning

confidence: 99%

“…3) Ownership Level of Developer's Commits (F3): Prior work [8], [11], [13] have studied the relation between code ownership, i.e., how much a developer is responsible for a source code, and commit bugginess. Such studies focus only on the ownership of a particular source code entity, e.g., files, at the instant that a commit is pushed.…”

Section: A Technical and Social Factorsmentioning

confidence: 99%

“…Those studies [5]- [8], [12], [13], [16] evaluated the relation between the factors discussed above and commit bugginess in a very limited way by considering only proprietary projects [5], [8], projects that do not adopt modern code review practices [12], [16] or a reduced number of factors as well as characteristics to represent them [6], [8], [13]. Our study differs from prior work by providing a more extensive and complete study on the relation between technical, social factors and the introduction of bugs.…”

Section: Related Workmentioning

confidence: 99%

See 3 more Smart Citations

On Relating Technical, Social Factors, and the Introduction of Bugs

Falcão

Barbosa

Fonseca

et al. 2020

2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)

View full text Add to dashboard Cite

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

show abstract

Section: Discussionsupporting

confidence: 67%

Section: A Technical and Social Factorsmentioning

confidence: 99%

Section: A Technical and Social Factorsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

On Relating Technical, Social Factors, and the Introduction of Bugs

Falcão

Barbosa

Fonseca

et al. 2020

2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)

View full text Add to dashboard Cite

show abstract

“…Reviewer Reviewing Experience measures how many prior patches that an invited reviewer had reviewed. To measure the reviewing experience, we first measure reviewing experience for each module that is impacted by the studied patch using a calculation of (Thongtanunam et al, 2016b), where r(D, M ) is the number of prior patches made to module M which the invited reviewer D had reviewed. R(k) is the total number of reviewers who reviewed patch k. C(M ) is the total number of prior patches that were made to M .…”

Section: Reviewer Experience Dimensionmentioning

confidence: 99%

The impact of human factors on the participation decision of reviewers in modern code review

et al. 2018

Self Cite

View full text Add to dashboard Cite

Modern Code Review (MCR) plays a key role in software quality practices. In MCR process, a new patch (i.e., a set of code changes) is encouraged to be examined by reviewers in order to identify weaknesses in source code prior to an integration into main software repositories. To mitigate the risk of having future defects, prior work suggests that MCR should be performed with sufficient review participation. Indeed, recent work shows that a low number of participated reviewers is associated with poor software quality. However, there is a likely case that a new patch still suffers from poor review participation even though reviewers were invited. Hence, in this paper, we set out to investigate the factors that are associated with the participation decision of an invited reviewer. Through a case study of 230,090 patches spread across the Android, LibreOffice, OpenStack and Qt systems, we find that (1) 16%-66% of patches have at least one invited reviewer who did not respond to the review invitation; (2) human factors play an important role in predicting whether or not an invited reviewer will participate in a review; (3) a review participation rate of an invited reviewers and code authoring experience of an invited reviewer are highly associated with the participation decision of an invited reviewer. These results can help practitioners better understand about how human factors associate with the participation decision of reviewers and serve as guidelines for inviting reviewers, leading to a better inviting decision and a better reviewer participation.

show abstract