spm-slides.tex: edits while reading Chapter 3. Technical Infrastructure [https://producingoss.com/en/message-forums.html#message-forum-choosing].

1 files changed, 53 insertions, 5 deletions

diff --git a/spm-slides.tex b/spm-slides.tex
index 6296dec..18983f2 100644
--- a/spm-slides.tex
+++ b/spm-slides.tex
@@ -484,6 +484,10 @@ Reasons;
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Use Branches to Avoid Bottlenecks}
 
+Helpful for collaborative development.
+
+Release branch, bugfix branch, experimental branch, etc.
+
 Branches are valuable because they turn a scarce resource — working room in the project's code — into an abundant one.
 
 Branches are cheap to make.
@@ -498,9 +502,13 @@ Use branches liberally.
 
 Most branches should merge their changes back into the main line and disappear, as soon as possible.
 
+When we do the merge, indicate that this is a merge in the log message.
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Pull Requests}
 
+Have you heard of {\em patches}.
+
 A \underline{pull request} is a request from a contributor to the
 project that a certain change be "pulled" (merged) into the project.
 
@@ -537,6 +545,8 @@ Use pull request to communicate ideas.
 
 Use pull request to learn the code base.
 
+Once your change is merged, your change is part of the software.
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Essential Git Commands}
 
@@ -715,6 +725,8 @@ Git and Github.
 
 https://www.mercurial-scm.org
 
+http://fossil-scm.org/
+
 https://subversion.apache.org
 
 
@@ -2003,6 +2015,11 @@ that went into the code repository, and never complained about being
 the single reviewer.
 
 
+Case study.  Millions of lines of code and hundreds or thousands of
+developers.  Each commit (relatively small in size) should reviewed by
+sub-domain experts before it is merged to the master branch.  Code
+review makes such large-scale collaboration possible.
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Technical debt}
 
@@ -2223,7 +2240,7 @@ A small, focused project - the email gateway features of the bug tracker. Issue
 A large, complex project - a dedicated discussion forum.  Your project should have a \underline{prominently-placed} description of all the available public forums.  See page 43 in the text book for an example.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Choosing the right forum management software}
+\foilhead{Choosing the Right Forum Management Software}
 
 Both email- and web-based access.
 
@@ -2254,8 +2271,25 @@ Archiving.
 
 https://mail.python.org/pipermail/python-dev/
   
-SPAM prevention.  Purpose: (1) Avoid your list/forum to be occupied by spam posts.  (2) Avoid your list/forum to be a source of email addresses for spam harvesters.  Measures: (1) Only auto-allow postings from list subscribers. Non-subscribers' posts go to a moderation queue.  (2)  Filter posts through spam-detection software. SPMX.  (3)  Moderation.  Mailing list moderation
-is strictly about keeping the list free of spam, and of wildly off-topic or otherwise inappropriate emails, nothing more. (4) Address-hiding in archives. jrandom@somedomain.com \\to jrandom\_AT\_somedomain.com \\or to jrandomNOSPAM@somedomain.com.
+SPAM prevention.  Use a spam filter.
+
+Purpose:
+
+(1) Avoid your list/forum to be occupied by spam posts.
+
+(2) Avoid your list/forum to be a source of email addresses for spam harvesters.
+
+Measures:
+
+(1) Only auto-allow postings from list subscribers. Non-subscribers' posts go to a {\bf moderation queue}.
+
+(2)  Filter posts through spam-detection software, e.g., SPMX,  Apache SpamAssassin,  SpamProbe.
+
+(3)  Moderation.  Mailing list moderation
+is strictly about keeping the list free of spam, and of wildly off-topic or otherwise inappropriate emails, nothing more.   Consider moderation burden.
+
+(4) Email address-hiding in archives.  At least obscure the real email address.
+    jrandom@somedomain.com \\to jrandom\_AT\_somedomain.com \\or to jrandomNOSPAM@somedomain.com.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{The great Reply-to debate}
@@ -2288,12 +2322,20 @@ The project's repository should be browsable on the Web.
 
 Browsability is important because it is a lightweight portal to project data.
 
-Browsability also implies canonical URLs for viewing a particular change.
+Browsability also implies canonical URLs for viewing a particular change -- no ambiguity
+during discussion.
 
 % Skipped: Singularity of Information
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\foilhead{Singularity of Information}
+
+TBD.
+
+
 % Skipped: Authorization
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Commit notifications / commit emails}
+\foilhead{Commit Notifications, Commit Emails}
 
 Every commit to the repository should generate a notification in a subscribable forum/mailing list.
 
@@ -2303,6 +2345,12 @@ Who made the change, when they made it, what files and directories changed, and
 
 Include the diff, set ``Reply-to'' to the regular development list.
 
+Let subscribers know what is going on at the code level.
+
+A sense of community.
+
+Commit email list versus Development mailing list.
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Bug Tracker}