Shane's recheck talk proposal
Change-Id: I664619151616deed1dd9ad51d3fb10df963084e7
diff --git a/schedule.md b/schedule.md
index 9b80247..a7c3db6 100644
--- a/schedule.md
+++ b/schedule.md
@@ -34,6 +34,7 @@
| 10:15 | [Qualcomm's Gerrit management overview from Devops/SRE](sessions/devops-qcom.md)
| 11:00 | [Migration from Gerrit 2.13 to 3.9: Challenges and Lessons](sessions/migrating-from-2.13-to-3.9.md)
| 12:30 | Lunch & Networking
+| 14:15 | [Repeated Builds During Code Review: The Case of OpenStack](sessions/repeated-builds-during-code-review.md)
| 17:00 | End of the day
### Friday 11th October
diff --git a/sessions/repeated-builds-during-code-review.md b/sessions/repeated-builds-during-code-review.md
new file mode 100644
index 0000000..e480842
--- /dev/null
+++ b/sessions/repeated-builds-during-code-review.md
@@ -0,0 +1,24 @@
+# Repeated Builds During Code Review: The Case of OpenStack
+
+Automated builds produce a noisy signal. Due to non-deterministic (a.k.a.,
+'flaky') behaviour, they can fail when they should have passed. Nevertheless,
+it's not uncommon for software organizations to incorporate automated builds in
+the code review process. In such cases, a failure from an automated build can
+block integration of a change set. To prevent invalid failures from unfairly
+blocking integration, organizations may allow developers to request a 'recheck',
+which repeats the build without updating the change set. While practical, an
+unconstrained recheck command may waste time and resources if it is not applied
+judiciously.
+
+In this talk, I will describe our research on the use of the recheck command in
+66,932 code reviews from the OpenStack community. We quantitatively analyze (i)
+how often build failures are rechecked; (ii) the extent to which invoking
+recheck changes build failure outcomes; and (iii) how much waste is generated by
+invoking recheck. We observe that (i) 55% of code reviews invoke the recheck
+command after a failing build is reported; (ii) invoking the recheck command
+only changes the outcome of a failing build in 42% of the cases; and (iii)
+invoking the recheck command increases review waiting time by an average of
+2,200% and equates to 187.4 compute years of waste—enough compute resources to
+compete with the oldest land living animal on earth.
+
+*[Shane McIntosh, University of Waterloo](../speakers.md#smcintosh)*
diff --git a/speakers.md b/speakers.md
index 5355797..d2c136b 100644
--- a/speakers.md
+++ b/speakers.md
@@ -59,3 +59,15 @@
with different programming languages, such as Scala, Java, NodeJS and related ecosystems.
[LinkedIn](www.linkedin.com/in/fponciroli)
+
+### Shane McIntosh - University of Waterloo {#smcintosh}
+
+Shane McIntosh is the current Ross & Muriel Cheriton Faculty Fellow and an
+Associate Professor in the Cheriton School of Computer Science at the University
+of Waterloo, Canada. At U. Waterloo, Shane directs the Software Repository
+Excavation and Build Engineering Labs (a.k.a., the Software REBELs). Shane and
+his trainees investigate how peer code review can be made more effective, how
+devops pipelines can be made more efficient, and how software can be produced
+with higher quality.
+
+[LinkedIn](www.linkedin.com/in/shane-mcintosh/)
