@article {1920,
	title = {Process Aspects and Social Dynamics of Contemporary Code Review: Insights from Open Source Development and Industrial Practice at Microsoft},
	journal = {IEEE Transactions on Software Engineering},
	volume = {43},
	year = {2017},
	note = {" We sent the survey
to code review participants from 36 popular OSS projects
and received 287 responses"},
	month = {1/2017},
	pages = {56 - 75},
	abstract = {Many open source and commercial developers practice contemporary code review, a lightweight, informal, tool-based code
review process. To better understand this process and its benefits, we gathered information about code review practices via surveys of
open source software developers and developers from Microsoft. The results of our analysis suggest that developers spend
approximately 10-15 percent of their time in code reviews, with the amount of effort increasing with experience. Developers consider
code review important, stating that in addition to finding defects, code reviews offer other benefits, including knowledge sharing,
community building, and maintaining code quality. The quality of the code submitted for review helps reviewers form impressions about
their teammates, which can influence future collaborations. We found a large amount of similarity between the Microsoft and OSS
respondents. One interesting difference is that while OSS respondents view code review as an important method of impression
formation, Microsoft respondents found knowledge dissemination to be more important. Finally, we found little difference between
distributed and co-located Microsoft teams. Our findings identify the following key areas that warrant focused research: 1) exploring the
non-technical benefits of code reviews, 2) helping developers in articulating review comments, and 3) assisting reviewers{\textquoteright} program
comprehension during code reviews.},
	keywords = {code review, commercial projects, peer impressions, Survey},
	issn = {1939-3520},
	doi = {10.1109/TSE.2016.2576451},
	url = {https://amiangshu.com/papers/CodeReview-TSE-2016.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CodeReview-TSE-2016.pdf},
	author = {Bosu, Amiangshu and Carver, Jeffrey C. and Christian Bird and Orbeck, Jonathan and Chockley, Christopher}
}
@conference {Izquierdo-Cortazar:2017:UMT:3084226.3084247,
	title = {Using Metrics to Track Code Review Performance},
	booktitle = {Proceedings of the 21st International Conference on Evaluation and Assessment in Software Engineering},
	series = {EASE{\textquoteright}17},
	year = {2017},
	pages = {214{\textendash}223},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {During 2015, some members of the Xen Project Advisory Board became worried about the performance of their code review process. The Xen Project is a free, open source software project developing one of the most popular virtualization platforms in the industry. They use a pre-commit peer review process similar to that in the Linux kernel, based on email messages. They had observed a large increase over time in the number of messages related to code review, and were worried about how this could be a signal of problems with their code review process.

To address these concerns, we designed and conducted, with their continuous feedback, a detailed analysis focused on finding these problems, if any. During the study, we dealt with the methodological problems of Linux-like code review, and with the deeper issue of finding metrics that could uncover the problems they were worried about. For having a benchmark, we run the same analysis on a similar project, which uses very similar code review practices: the Linux Netdev (Netdev) project. As a result, we learned how in fact the Xen Project had some problems, but at the moment of the analysis those were already under control. We found as well how different the Xen and Netdev projects were behaving with respect to code review performance, despite being so similar from many points of view.

In this paper we show the results of both analyses, and propose a comprehensive methodology, fully automated, to study Linux-style code review. We discuss also the problems of getting significant metrics to track improvements or detect problems in this kind of code review.},
	keywords = {code review, data mining, Software development analytics},
	isbn = {978-1-4503-4804-1},
	doi = {10.1145/3084226.3084247},
	url = {http://doi.acm.org/10.1145/3084226.3084247},
	author = {Izquierdo-Cortazar, Daniel and Sekitoleko, Nelson and Jesus M. Gonzalez-Barahona and Kurth, Lars}
}
@proceedings {1769,
	title = {Investigating Code Review Practices in Defective Files: An Empirical Study of the Qt System},
	year = {2015},
	month = {05/2015},
	publisher = {IEEE},
	abstract = {Software code review is a well-established software
quality practice. Recently, Modern Code Review (MCR) has been
widely adopted in both open source and proprietary projects.
To evaluate the impact that characteristics of MCR practices
have on software quality, this paper comparatively studies MCR
practices in defective and clean source code files. We investigate
defective files along two perspectives: 1) files that will eventually
have defects (i.e., future-defective files) and 2) files that have
historically been defective (i.e., risky files). Through an empirical
study of 11,736 reviews of changes to 24,486 files from the Qt
open source project, we find that both future-defective files and
risky files tend to be reviewed less rigorously than their clean
counterparts. We also find that the concerns addressed during
the code reviews of both defective and clean files tend to enhance
evolvability, i.e., ease future maintenance (like documentation),
rather than focus on functional issues (like incorrect program
logic). Our findings suggest that although functionality concerns
are rarely addressed during code review, the rigor of the
reviewing process that is applied to a source code file throughout
a development cycle shares a link with its defect proneness.},
	keywords = {code review, software quality},
	url = {http://sail.cs.queensu.ca/publications/pubs/msr2015-thongtanunam.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr2015-thongtanunam.pdf},
	author = {Patanamon Thongtanunam and McIntosh, Shane and Hassan, Ahmed E. and Hajimu Iida}
}
@conference {Beller:2014:MCR:2597073.2597082,
	title = {Modern Code Reviews in Open-source Projects: Which Problems Do They Fix?},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {202{\textendash}211},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Code review is the manual assessment of source code by humans, mainly intended to identify defects and quality problems. Modern Code Review (MCR), a lightweight variant of the code inspections investigated since the 1970s, prevails today both in industry and open-source software (OSS) systems. The objective of this paper is to increase our understanding of the practical benefits that the MCR process produces on reviewed source code. To that end, we empirically explore the problems fixed through MCR in OSS systems. We manually classified over 1,400 changes taking place in reviewed code from two OSS projects into a validated categorization scheme. Surprisingly, results show that the types of changes due to the MCR process in OSS are strikingly similar to those in the industry and academic systems from literature, featuring the similar 75:25 ratio of maintainability-related to functional problems. We also reveal that 7{\textendash}35\% of review comments are discarded and that 10{\textendash}22\% of the changes are not triggered by an explicit review comment. Patterns emerged in the review data; we investigated them revealing the technical factors that influence the number of changes due to the MCR process. We found that bug-fixing tasks lead to fewer changes and tasks with more altered files and a higher code churn have more changes. Contrary to intuition, the person of the reviewer had no impact on the number of changes.
},
	keywords = {code review, defects, open source software},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597082},
	url = {http://doi.acm.org/10.1145/2597073.2597082},
	attachments = {https://flosshub.org/sites/flosshub.org/files/beller.pdf},
	author = {Beller, Moritz and Bacchelli, Alberto and Zaidman, Andy and Juergens, Elmar}
}
@proceedings {1498,
	title = {Who Does What during a Code Review? Datasets of OSS Peer Review Repositories },
	year = {2013},
	month = {05/2013},
	abstract = {We present four datasets that are focused on the general roles of OSS peer review members. With data mined from both an integrated peer review system and code source repositories, our rich datasets comprise of peer review data that was automatically recorded. Using the Android project as a case study, we describe our extraction methodology, the datasets and their application used for three separate studies. Our datasets are available online at http://sdlab.naist.jp/reviewmining/},
	keywords = {android, case study, code review, data set, peer review, roles, source code},
	author = {Kazuki Hamasaki and Raula Gaikovina Kula and Norihiro Yoshida and A. E. Camargo Cruz and Kenji Fujiwara and Hajimu Iida}
}
