more

01-debating/01-debating.tex

@@ -30,7 +30,7 @@
 \thought[bugayenko2015blog1222]{Open source must be \ul{the only} way for you to write code.}
 
 \qte
-  [Naveen Raman]
+  [\nospell{Naveen Raman}]
   {naveen-raman}
   {Among the many reasons to contribute to open source, building one's professional \ul{reputation} and signaling one's skills to potential employers are common ones.}
   {raman2020stress}
@@ -43,19 +43,19 @@
 \thought{Be fully prepared for the toxicity of open source terrain.}
 
 \qte
-  [Yulia Tsvetkov]
+  [\nospell{Yulia Tsvetkov}]
   {yulia-tsvetkov}
   {Toxic \ul{language} in open source can manifest in multiple ways, including hate speech and microaggressions found also elsewhere online (e.g., Youtube), but also through open-source-specific displays of \ul{entitlement} and \ul{urgency} related to timing expectations.}
   {raman2020stress}
 
 \qte
-  [Courtney Miller]
+  [\nospell{Courtney Miller}]
   {courtney-miller}
   {Within open source, entitled and demeaning complaints, arrogance, and insults are common forms of \ul{toxicity}.}
   {miller2022did}
 
 \qte
-  [Isabella Ferreira]
+  [\nospell{Isabella Ferreira}]
   {isabella-ferreira}
   {We conducted a qualitative analysis on 1,545 emails from the Linux Kernel Mailing List that were associated with rejected changes. We found that \ul{more than half} (67\%) of the non-technical emails included uncivil features. Particularly, frustration, name calling, and impatience are the most frequent features in uncivil emails. }
   {ferreira2021shut}
@@ -86,31 +86,31 @@
 \thought[bugayenko2020blog0729]{Beautify your profile, start with an anthropomorphic avatar.}
 
 \qte
-  [Kristine Nowak]
+  [\nospell{Kristine Nowak}]
   {kristine-nowak}
   {Avatars that were more \ul{anthropomorphic} were perceived to be more \ul{attractive} and \ul{credible}. The strongest predictor of these variables, however, was the degree of masculinity or femininity (lack of androgyny) of an avatar.}
   {nowak2005influence}
 
 \qte
-  [Josh Terrell]
+  [\nospell{Josh Terrell}]
   {josh-terrell}
   {Surprisingly, our results show that women's contributions tend to be accepted \ul{more often} than men's. However, for contributors who are outsiders to a project and their gender is identifiable, men's acceptance rates are \ul{higher}.}
   {terrell2017gender}
 
 \qte
-  [Reza Nadri]
+  [\nospell{Reza Nadri}]
   {reza-nadri}
   {We have identified that submitters perceptible as Hispanic and Black have 39\% of their pull requests rejected because they are seen as unnecessary, which is 10-12 percentage points more frequent than the rest of perceptible races.}
   {nadri2021insights}
 
 \qte
-  [Nasif Imtiaz]
+  [\nospell{Nasif Imtiaz}]
   {nasif-imtiaz}
   {We found that women did not provide more information on competence and were not generally measured at a stricter standard than men. We observed that women were less likely to express \ul{politeness} and \ul{profanity} than men, and were more restrictive in expressing their \ul{sentiments} on the platform.}
   {imtiaz2019investigating}
 
 \qte
-  [Carolyn D. Egelman]
+  [\nospell{Carolyn D. Egelman}]
   {carolyn-egelman}
   {Being a \ul{new employee} is not a statistically significant predictor of any of our feelings of pushback. Compared to authors at level 1 (entry level), authors at level 3 are 28\% less likely to see conflict in their code review changes.}
   {egelman2020predicting}
@@ -126,7 +126,7 @@
 \pitch{\includegraphics[width=\linewidth]{face-to-face.png}}
 
 \qte
-  [Verena Ebert]
+  [\nospell{Verena Ebert}]
   {verena-ebert}
   {Developers use many channels. Previously, mailing lists were very common. Nowadays, other communication channels become more and more popular, for example, Slack, issue trackers, Twitter or Gitter.}
   {ebert2022communication}
@@ -138,21 +138,21 @@
 \thought{Be aware of robots!}
 
 \qte
-  [Natarajan Chidambaram]
+  [\nospell{Natarajan Chidambaram}]
   {natarajan-chidambaram}
   {Collaborative software development through GitHub repositories frequently relies on bot accounts to automate repetitive and error-prone tasks. This highlights the need to have accurate and efficient bot identification tools.}
   {chidambaram2024rabbit}
 
 \thought[bugayenko2020blog0729]{Be polite, especially when you are angry or disagree.}
 
 \qte
-  [Xuan Lu]
+  [\nospell{Xuan Lu}]
   {xuan-lu}
   {Developers who use \ul{emojis} in their posts are significantly less likely to \ul{dropout} from the online work platform.}
   {lu2022emojis}
 
 \qte
-  [Thomas Fackler]
+  [\nospell{Thomas Fackler}]
   {thomas-fackler}
   {Our results show that there is \ul{gravity} in online collaborations on GitHub. Traditional determinants of international trade such as \ul{language barriers} and \ul{country borders} matter for international code contributions.}
   {fackler2020gravity}
@@ -167,7 +167,7 @@
   {laurentsyeva2019friends}
 
 \qte
-  [Justin Middleton]
+  [\nospell{Justin Middleton}]
   {justin-middleton}
   {While we indeed find support for the idea that increases in activity correlate with a higher probability for membership, we also found the particular cases for which more activity can reduce the probability. This underscores the notion that software collaboration is much more than the code itself and that the social components of software should not be undervalued by software teams.}
   {middleton2018contributions}

02-reporting-bugs/02-reporting-bugs.tex

@@ -28,19 +28,19 @@
 \plush{\osbpTitlePage{2}{nLcnE4N3Nz4}}
 
 \qte
-  [Joel Spolsky]
+  [\nospell{Joel Spolsky}]
   {joel-spolsky}
   {Every good bug report needs exactly three things: \ul{steps} to reproduce, what you \ul{expected} to see, and what you \ul{saw} instead.}
   {spolsky2000bugs}
 
 \qte
-  [Nicolas Bettenburg]
+  [\nospell{Nicolas Bettenburg}]
   {nicolas-bettenburg}
   {Well-written bug reports are likely to get \ul{more attention} among developers than poorly written ones... Steps to reproduce and stack traces are most useful in bug reports. The most severe problems encountered by developers are errors in steps to reproduce, incomplete information, and wrong observed behavior.}
   {bettenburg2008makes}
 
 \qte
-  [Tommaso Dal Sasso]
+  [\nospell{Tommaso Dal Sasso}]
   {tommaso-dal-sasso}
   {The elements considered to be harder to provide [while reporting bugs] are the \ul{entity} (e.g., class, file) that likely contains the defect, the \ul{steps} to reproduce the failure, and a \ul{test case} showing the defect.}
   {dal2016makes}
@@ -53,7 +53,7 @@
   {hetzel1993complete}
 
 \qte
-  [Myers, Glenford J.]
+  [\nospell{Myers, Glenford J.}]
   {glenford-myers}
   {You cannot test a program to guarantee that it is error free... It is impractical, often impossible, to find \ul{all} the errors in a program.}
   {myers2012art}
@@ -73,13 +73,13 @@
 More about it by \citet{bugayenko2018blog0206}.}
 
 \qte
-  [Reis Christian]
+  [\nospell{Reis Christian}]
   {reis-christian}
   {Though it commonly has a prejorative connotation, in the Mozilla Project the term \textbf{bug} is used to refer to any field request for modification in the software, be it an \ul{actual} defect, an enhancement, or a change in functionality. (``bug-driven development'')}
   {reis2002overview}
 
 \qte
-  [Kim Herzig]
+  [\nospell{Kim Herzig}]
   {kim-herzig}
   {In a manual examination of more than 7,000 issue reports from five open-source projects, we found 33.8\% of all bug reports to be \ul{misclassified} threatening bug prediction models, confusing \ul{bugs} and \ul{features}: On average, 39\% of files marked as defective actually never had a bug.}
   {herzig2013s}
@@ -89,7 +89,7 @@
 \thought{Report strictly one problem per ticket}
 
 \qte
-  [John Anvik]
+  [\nospell{John Anvik}]
   {john-anvik}
   {People play different roles as they interact with reports in a bug repository. The person who submits the report is the \ul{reporter} or the \ul{submitter} of the report. The \ul{triager} is the person who decides if the report is meaningful and who assigns responsibility of the report to a developer. The one that resolves the report is the \ul{resolver}. A person that contributes a fix for a bug is called a \ul{contributor}.}
   {anvik2006should}

03-making-changes/03-making-changes.tex

@@ -28,37 +28,37 @@
 \plush{\osbpTitlePage{3}{}}
 
 \qte
-  [Bram Adams]
+  [\nospell{\nospell{Bram Adams}}]
   {bram-adams}
   {We found that \ul{33\%} of the patches makes it into a Linux release, and that most of them need \ul{3 to 6 months} for this.}
   {jiang2013will}
 
 \thought[bugayenko2020blog0729]{Make small pull requests}
 
 \qte
-  [Amiangshu Bosu]
+  [\nospell{Amiangshu Bosu}]
   {amiangshu-bosu}
   {We found that the \ul{more files} that are in a change, the \ul{lower} the proportion of \ul{comments} in the code review that will be of value to the author of the change.}
   {bosu2015characteristics}
 
 \qte
-  [Caitlin Sadowski]
+  [\nospell{Caitlin Sadowski}]
   {caitlin-sadowski}
   {A correlation between \ul{change size} and \ul{review quality} is acknowledged by Google and developers are strongly encouraged to make small, incremental changes (with the exception of large deletions and automated refactoring).}
   {sadowski2018modern}
 
 \thought[bugayenko2020blog0729]{Don't group your changes}
 
 \qte
-  [Carolyn D. Egelman]
+  [\nospell{Carolyn D. Egelman}]
   {carolyn-egelman}
   {Google categorizes CRs into specific sizes, these sizes are indicated as part of the code review tool and in the notification to the reviewer of the code change... The general advice is to \ul{split} change requests for \ul{easier} and \ul{quicker} reviews when possible.}
   {egelman2020predicting}
 
 \thought{Insist on code reviews and merges... politely}
 
 \qte
-  [Marco Ortu]
+  [\nospell{Marco Ortu}]
   {marco-ortu}
   {Our results show that \ul{valence} (expressed in comments received and posted by a reporter) and \ul{joy} expressed in the comments written by a reporter are linked to a \ul{higher likelihood} of issues to be merged. On the contrary, sadness, anger, and arousal expressed in the comments written by a reporter, and anger, arousal, and dominance expressed in the comments received by a reporter, are linked to a lower likelihood of a pull request to be merged.}
   {ortu2020you}
@@ -67,13 +67,13 @@
 Valence, also known as hedonic tone, is a characteristic of emotions that determines their emotional affect (intrinsic appeal or repulsion). Positive valence corresponds to the "goodness" or attractiveness of an object, event, or situation, making it appealing or desirable. Conversely, negative valence relates to ``badness'' or averseness, rendering something unappealing or undesirable. --- \href{https://en.wikipedia.org/wiki/Valence_(psychology)}{Wikipedia}}
 
 \qte
-  [Rahul Iyer]
+  [\nospell{Rahul Iyer}]
   {rahul-iyer}
   {The larger the difference in \ul{personality traits} between the requester and the closer, the more \ul{positive effect} it has on pull request acceptance.}
   {iyer2019effects}
 
 \qte
-  [Denae Ford]
+  [\nospell{Denae Ford}]
   {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}
@@ -88,7 +88,7 @@
 \thought{Be a leader and a boss of a pull request --- be the one who cares}
 
 \qte
-  [Jason Tsay]
+  [\nospell{Jason Tsay}]
   {jason-tsay}
   {We found that the level of a submitter's prior interaction on a project changed how \ul{politely} developers discussed the contribution and the nature of proposed alternative solutions.}
   {tsay2014let}
@@ -109,13 +109,13 @@
 \thought{Be prepared for criticism about your style, not functionality}
 
 \qte
-  [Jacek Czerwonka]
+  [\nospell{Jacek Czerwonka}]
   {jacek-czerwonka}
   {Only about 15\% of comments provided by reviewers indicate a possible defect, much less a blocking defect. Rather, it is feedback related to the long-term code \ul{maintainability} that comprises a much larger portion of comments provided by reviewers; at least 50\% of all.}
   {czerwonka2015code}
 
 \qte
-  [Valentina Lenarduzzi]
+  [\nospell{Valentina Lenarduzzi}]
   {valentina-lenarduzzi}
   {Unexpectedly, quality \ul{flaws} measured by PMD turned out not to affect the acceptance of a pull request at all. As suggested by other works, other factors such as the \ul{reputation} of the maintainer and the \ul{importance} of the delivered feature might be more important than other qualities in terms of pull request acceptance.}
   {lenarduzzi2021does}

04-reviewing-changes/04-reviewing-changes.tex

@@ -28,27 +28,27 @@
 \plush{\osbpTitlePage{4}{}}
 
 \qte
-  [Martin Fowler]
+  [\nospell{\nospell{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}
 
 \thought{Not only find bugs. Also, educate the author.}
 
 \qte
-  [Andrew Sutherland]
+  [\nospell{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]
+  [\nospell{Alberto Bacchelli}]
   {alberto-bacchelli}
   {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
-  [Peter C. Rigby]
+  [\nospell{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}
@@ -68,7 +68,7 @@
   \end{multicols}}
 
 \qte
-  [Caitlin Sadowski]
+  [\nospell{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}
@@ -77,25 +77,25 @@
 \thought[bugayenko2015blog0209]{Raise issues, don't resolve them!}
 
 \qte
-  [Michael Fagan]
+  [\nospell{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]
+  [\nospell{Frank A. Ackerman}]
   {frank-ackerman}
   {Regardless of the application or the language, you can expect inspections to find from seven to 20 major \ul{defects} per thousand noncomment lines of source code and to find major defects at a \ul{cost} of one to five staff-hours.}
   {ackerman1989software}
 
 \qte
-  [Brendan Cleary]
+  [\nospell{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]
+  [\nospell{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}
@@ -110,7 +110,7 @@
   {raymond1999cathedral}
 
 \qte
-  [Frederic Painchaud]
+  [\nospell{\nospell{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}
@@ -122,7 +122,7 @@
 \thought{Rely on the CI status, but not too much}
 
 \qte
-  [Mairieli Wessel]
+  [\nospell{\nospell{Mairieli Wessel}}]
   {mairieli-wessel}
   {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}

aspell.en.pws

@@ -2,6 +2,7 @@ personal_ws-1.1 en 741 utf-8
 Yegor
 yegor
 Bugayenko
+bugayenko
 osbp
 ESEC
 PMBA
@@ -46,4 +47,32 @@ qulice
 jpeek
 objectionary
 cqfn
-codebases
+codebases
+dialogs
+sutherland
+andrew
+fowler
+alberto
+bacchelli
+rigby
+Lucent
+Bing
+wessel
+github
+raymond
+eric
+brendan
+cleary
+mateus
+freira
+santos
+ackerman
+sadowski
+caitlin
+noncomment
+painchaud
+frederic
+incrementality
+mairieli
+michael
+fagan

osbp.sty

@@ -61,6 +61,9 @@
   }
 }
 \newcommand\source[1]{\par{\scriptsize Source: \bibentry{#1}\par}}
+
+\newcommand\nospell[1]{#1}
+
 \newcounter{thght}
 \newcommand\thought[2][]{
   \addtocounter{thght}{1}