diff options
| -rw-r--r-- | spm-slides.tex | 48 |
1 files changed, 41 insertions, 7 deletions
diff --git a/spm-slides.tex b/spm-slides.tex index 66d2e31..0ec3a9b 100644 --- a/spm-slides.tex +++ b/spm-slides.tex @@ -797,7 +797,7 @@ Project stability depends on: Healthy turnover won't damage social norms because we have regular {\em transmission effort}. -Children's songs survive for centuries. {\em Greensleeves} (the 16th-century folk tune). +Children's songs survive for centuries. {\em What child is this (1865)? Greensleeves} (the 16th-century folk tune). {\em Classic of Poetry} (China's Book of Songs from 1046–771 BC). @@ -821,14 +821,48 @@ or private, from someone that they behaved inappropriately. \url{https://www.contributor-covenant.org/version/1/4/code-of-conduct} -{\bf Code review}. IMPORTANT. Peer review in the open source world. -Result - software quality. People do their best work when they know -that others will take the time to evaluate it. +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Code review} + +Do commit review, code review regularly. + +Look at other people's code {\em changes} as they arrive. + +Look for bugs and areas of posssible improvement. Thing we could +catch: memory leaks, off-by-one errors, insufficient comments, +insufficient API documentation, security vulnerabilities, compliments +... + -One could contribute as much to the project by reviewing others' -changes as by writing new code. +{\bf Important} to have more eyeballs. + +This is {\em peer review} in the open source world. + +Why focus on reviewing recent changes? + +\begin{itemize} +\item It works better socially. Timely feedback for fresh changes. A great way to interact with people. Confirm that what they do {\em matters} (is seen and understood). People do their best work when they know that others will take the +time to evaluate it. +\item The recent change is a good starter for getting familiar with the codebase. Also look at the affected callers and callees. +\end{itemize} + +Result - better software quality. + +The review should be public, so that other people can see it and know that a review has happened, and is expected. + +Commit notifications are useful. + +A valuable way to spend time. One could contribute as much to the +project by reviewing others' changes as by writing new code. + +Case study. Greg Stein reviewed every line of every single commit +that went into the code repository, and never complained about being +the single reviewer. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\foilhead{Technical debt} -Memory leaks, off-by-one errors, insufficient comments, security vulnerabilities, compliments ... +tbd %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \foilhead{Be open from day one} |