@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}
}
@inbook {Rodr{\'\i}guez-P{\'e}rez2016,
	title = {BugTracking: A Tool to Assist in the Identification of Bug Reports},
	booktitle = {Open Source Systems: Integrating Communities: 12th IFIP WG 2.13 International Conference, OSS 2016, Gothenburg, Sweden, May 30 - June 2, 2016, Proceedings},
	year = {2016},
	pages = {192{\textendash}198},
	publisher = {Springer International Publishing},
	organization = {Springer International Publishing},
	chapter = {BugTracking: A Tool to Assist in the Identification of Bug Reports},
	address = {Cham},
	abstract = {Issue tracking systems are used, in most software projects, but in particular in almost all free open source software, to record many different kinds of issues: bug reports, feature requests, maintenance tickets and even design discussions. Identifying which of those issues are bug reports is not a trivial task. When researchers want to conduct studies on the bug reports, managed by a software development project, first of all they need to perform this identification.
The job for researchers here is very different from the bug triaging that researchers do. In the latter case, people with a considerate experience in the project make a decision based on the information available at that time (maybe just a short comment by some user), asking, if needed, for more details. In the former case, researchers usually have not that experience in the project, but they have at their use all the information produced, until the moment the issue was closed. This may include not only all comments and actions on the issue tracking system, but for example, discussions about a fix in the code review system, or the final fixing patch in the source code management system. Having all that information conveyed to the researchers, in an easy, flexible and quick way, accelerates and makes their decision process much more reliable. It simplifies large scale manual analysis of issues (in hundreds or thousands), helping researchers to ensure that they are really working with what they intend to work: bug reports.
This paper presents a tool designed to solve exactly the problem of providing the researchers with all the relevant information needed to decide whether an issue corresponds to a bug report or not. The tool uses information extracted automatically from the projects repositories. It offers a web-based interface which allows collaboration, traceability and transparency of the identification of bug reports. All this makes the process easier, faster, and more reliable.},
	isbn = {978-3-319-39225-7},
	doi = {10.1007/978-3-319-39225-7_16},
	url = {http://dx.doi.org/10.1007/978-3-319-39225-7_16},
	author = {Rodr{\'\i}guez-P{\'e}rez, Gema and Gonzalez-Barahona, Jes{\'u}s M. and Gregorio Robles and Dalipaj, Dorealda and Sekitoleko, Nelson},
	editor = {Kevin Crowston and Hammouda, Imed and Lundell, Bj{\"o}rn and Gregorio Robles and Gamalielsson, Jonas and Juho Lindman}
}
