more

yegor256 · Mar 6, 2024 · 8626f97 · 8626f97
1 parent 3977273
commit 8626f97
Show file tree

Hide file tree

Showing 9 changed files with 89 additions and 40 deletions.
diff --git a/03-making-changes/03-making-changes.tex b/03-making-changes/03-making-changes.tex
@@ -77,15 +77,13 @@
   {denae-ford}
   {We observe that both \ul{social} and \ul{technical} aspects are being taken into consideration when deciding upon pull request acceptance. Moreover, we observe that many \ul{more} social aspects are being considered during the experiment than \ul{reported} during the post-experiment survey.}
   {ford2019beyond}
-
 \pitch{
   \begin{multicols}{2}
   \includegraphics[width=.9\linewidth]{eyes.png}
   \source{ford2019beyond}
   \par\columnbreak\par
   GitHub is increasing size of the avatar images and emphasizing a developer's ``personal brand'' by spotlighting features such as the contribution heat map. In the future, platform designers must be more mindful in balancing the power of signals that can amplify bias or harm against users, while still providing the mechanisms for users to freely evaluate the merits of potential code contributions.
-  \end{multicols}
-}
+  \end{multicols}}
 
 \thought{Be a leader and a boss of a pull request --- be the one who cares}
 

diff --git a/04-reviewing-changes/04-reviewing-changes.tex b/04-reviewing-changes/04-reviewing-changes.tex
@@ -27,49 +27,60 @@
 
 \plush{\osbpTitlePage{4}{}}
 
-
 \qte
   [Martin Fowler]
   {martin-fowler}
   {We should remember that \ul{pre-integration} review grew out of an open-source context where contributions appear impromptu from \ul{weakly connected} developers.}
   {fowler2006}
 
-\pitch{.}
-
-% when and how we reject PRs?
-%
-
-% https://dl.acm.org/doi/pdf/10.1145/1985793.1985867?casa_token=OOIj7cdZptYAAAAA:Ozr-aJk-c-l6mcU6qSGKZS1hZkZlvrUFVjeS9ta1tO07eNFiHeRYi9fVOMGolDNjnzOXB8IKE6IhKWI
-
-% Effects of personality traits on pull request acceptance
-% RN Iyer, SA Yun, M Nagappan, J Hoey - IEEE Transactions on Software Engineering, 2019
-
-% start from this:
-% https://dl.acm.org/doi/pdf/10.1145/3183519.3183525
+\thought{Not only find bugs. Also, educate the author.}
 
 \qte
-  [Michael Fagan]
-  {michael-fagan}
-  {The inspection is not intended to redesign, evaluate alternate design solutions, or to find solutions to errors; it is intended \ul{just} to find errors!}
-  {fagan1976design}
+  [Andrew Sutherland]
+  {andrew-sutherland}
+  {The meat of the code review dialog, no matter what the medium, is the articulation of design rationale... Engineers find code review dialogs useful for a variety of purposes, but for understanding design rationale more than any other.}
+  {sutherland2009can}
 
 \qte
   [Alberto Bacchelli]
   {alberto-bacchelli}
-  {Our results show that, although the top motivation driving code reviews is still finding defects, the practice and the actual outcomes are \ul{less} about finding errors than expected: Defect related comments comprise a small proportion and mainly cover small logical low-level issues.}
+  {Our results show that, although the top motivation driving code reviews is still \ul{finding defects}, the practice and the actual outcomes are \ul{less} about finding errors than expected: Defect related comments comprise a small proportion and mainly cover small logical low-level issues.}
   {bacchelli2013expectations}
 
 \qte
-  [Mateus Freira dos Santos]
-  {mateus-freira-dos-santos}
-  {In software projects with less than 34k lines of code, the number of developers that \ul{never contribute again} after receiving a negative comment on the first pull request is 10.97\%; this number more than doubles to 24.02\% when evaluating projects with more than 197k lines of code.}
-  {mateus-freira-dos-santos.jpg}
+  [Peter C. Rigby]
+  {peter-rigby}
+  {Contemporary review is performed regularly and quickly just before the code is committed instead of when a larger work product is complete as in inspection. Contemporary reviewers prefers discussion and fixing code over reporting defects.}
+  {rigby2013convergent}
+\pitch{
+  \begin{multicols}{2}
+  \includegraphics[width=.9\linewidth]{lines-per-pr.png}
+  \par\columnbreak\par
+  ``Both Android and AMD have a median change size of 44 lines. This median change size is larger than Apache, \ul{25 lines}, and Linux, \ul{32 lines}, but much smaller than Lucent where the number of non-comment lines changed is \ul{263 lines}. Bing, Chrome’s median change is \ul{78 lines} and includes 5 files.''
+  \source{rigby2013convergent}
+  \end{multicols}}
+\pitch{
+  \begin{multicols}{2}
+  \includegraphics[width=.9\linewidth]{days-per-pr.png}
+  \par\columnbreak\par
+  ``AMD has short review intervals, with the median review taking \ul{17.5 hours}. Bing, SQL, and Office: \ul{14.7}, \ul{19.8}, and \ul{18.9 hours} respectively. The median completion time is \ul{15.7} and \ul{20.8 hours}, for Chrome and Android, respectively.''
+  \source{rigby2013convergent}
+  \end{multicols}}
 
 \qte
-  [Andrew Sutherland]
-  {andrew-sutherland}
-  {The meat of the code review dialog, no matter what the medium, is the articulation of design rationale... Engineers find code review dialogs useful for a variety of purposes, but for understanding design rationale more than any other.}
-  {sutherland2009can}
+  [Caitlin Sadowski]
+  {caitlin-sadowski}
+  {As developers build experience working at Google, the average number of comments on their changes decreases... Developers at Google who have started within the past year typically have more than twice as many comments per change.}
+  {sadowski2018modern}
+\pitch{\includegraphics[width=.95\linewidth]{tenure.png}}
+
+\thought[bugayenko2015blog0209]{Raise issues, don't resolve them!}
+
+\qte
+  [Michael Fagan]
+  {michael-fagan}
+  {The inspection is not intended to redesign, evaluate alternate design solutions, or to find solutions to errors; it is intended \ul{just} to find errors!}
+  {fagan1976design}
 
 \qte
   [Frank A. Ackerman]
@@ -78,18 +89,35 @@
   {ackerman1989software}
 
 \qte
-  [Caitlin Sadowski]
-  {caitlin-sadowski}
-  {As developers build experience working at Google, the average number of comments on their changes decreases... Developers at Google who have started within the past year typically have more than twice as many comments per change.}
-  {sadowski2018modern}
-\pitch{\includegraphics[width=.95\linewidth]{tenure.png}}
+  [Brendan Cleary]
+  {brendan-cleary}
+  {`Raise issues, don't resolve them.' --- this mentality limits a group's ability to \ul{collectively} solve problems and \ul{mentor} developers.}
+  {rigby2012contemporary}
+
+\qte
+  [Mateus Freira dos Santos]
+  {mateus-freira-dos-santos}
+  {In software projects with less than 34k lines of code, the number of developers that \ul{never contribute again} after receiving a negative comment on the first pull request is 10.97\%; this number more than doubles to 24.02\% when evaluating projects with more than 197k lines of code.}
+  {freira2018analyzing}
+
+\thought[bugayenko2019blog1203]{Don't run the code in the branch}
+
+\thought[bugayenko2015blog0622]{Reject it, if it's too big}
 
 \qte
   {eric-raymond}
   {Good programmers know what to write. Great ones know what to rewrite (and reuse).}
   {raymond1999cathedral}
 
-\thought[bugayenko2019blog1203]{Don't run the code in the branch}
+\qte
+  [Frederic Painchaud]
+  {frederic-painchaud}
+  {To facilitate early and frequent \ul{feedback}, OSS projects tend to review smaller changes than proprietary projects, ranging from 11 to 32 lines in the median case. The small size lets reviewers \ul{focus} on the entire change, and the incrementality reduces reviewers’ preparation time and lets them maintain an overall picture of how the change fits into the system.}
+  {rigby2012contemporary}
+
+\thought[bugayenko2015blog0622]{Reject it, if it lowers code coverage}
+
+\thought[bugayenko2015blog0622]{Reject it, if it doesn't reproduce a bug}
 
 \thought{Rely on the CI status, but not too much}
 
@@ -99,12 +127,12 @@
   {Our findings also suggest that the adoption of GitHub Actions leads to more rejections of pull requests (PRs), more communication in accepted PRs and less communication in rejected PRs, fewer commits in accepted PRs and more commits in rejected PRs, and more time to accept a PR.}
   {wessel2023github}
 
-\thought[bugayenko2015blog0209]{Make not compromises}
-
-\thought[bugayenko2015blog0209]{Have no fear}
+% https://dl.acm.org/doi/pdf/10.1145/1985793.1985867?casa_token=OOIj7cdZptYAAAAA:Ozr-aJk-c-l6mcU6qSGKZS1hZkZlvrUFVjeS9ta1tO07eNFiHeRYi9fVOMGolDNjnzOXB8IKE6IhKWI
 
-\thought[bugayenko2015blog0622]{Reject it, if it doesn't reproduce a bug}
+% Effects of personality traits on pull request acceptance
+% RN Iyer, SA Yun, M Nagappan, J Hoey - IEEE Transactions on Software Engineering, 2019
 
-\thought[bugayenko2015blog0622]{Reject it, if it lowers code coverage}
+% start from this:
+% https://dl.acm.org/doi/pdf/10.1145/3183519.3183525
 
 \end{document}
diff --git a/04-reviewing-changes/days-per-pr.png b/04-reviewing-changes/days-per-pr.png
diff --git a/04-reviewing-changes/lines-per-pr.png b/04-reviewing-changes/lines-per-pr.png
diff --git a/faces/brendan-cleary.jpg b/faces/brendan-cleary.jpg
diff --git a/faces/frederic-painchaud.jpg b/faces/frederic-painchaud.jpg
diff --git a/faces/peter-rigby.jpg b/faces/peter-rigby.jpg
diff --git a/main.bib b/main.bib
@@ -535,3 +535,23 @@ @inproceedings{chidambaram2024rabbit
   organization={ACM, Lisbon, Portugal},
   doi={10.1145/3643991.3644877}
 }
+
+
+@inproceedings{rigby2013convergent,
+  title={{Convergent Contemporary Software Peer Review Practices}},
+  author={Rigby, Peter C. and Bird, Christian},
+  booktitle={{Proceedings of the 9th Joint Meeting on Foundations of Software Engineering}},
+  pages={202--212},
+  year={2013}
+}
+
+@article{rigby2012contemporary,
+  title={{Contemporary Peer Review in Action: Lessons from Open Source Development}},
+  author={Rigby, Peter and Cleary, Brendan and Painchaud, Frederic and Storey, Margaret-Anne and German, Daniel},
+  journal={{IEEE Software}},
+  volume={29},
+  number={6},
+  pages={56--61},
+  year={2012},
+  publisher={IEEE}
+}
diff --git a/osbp.sty b/osbp.sty
@@ -35,6 +35,9 @@
 \RequirePackage{booktabs}
 \RequirePackage{graphicx}
 
+\usepackage{silence}
+  \WarningFilter{bibentry}{You have used \nobibliography*}
+
 \newcommand\osbpTitlePage[2]{\begin{pptMiddle}%
   \pptTitle{\thetitle}{}\par
   {\scshape Yegor Bugayenko}\par