spm-slides.tex: improve materials on communications; correct typos

1 files changed, 100 insertions, 38 deletions

diff --git a/spm-slides.tex b/spm-slides.tex
index a81b23a..1bbf562 100644
--- a/spm-slides.tex
+++ b/spm-slides.tex
@@ -122,7 +122,7 @@ dis·ci·plined: showing a controlled form of behavior or way of working.
 You have a plan but you continuously get distracted by additional ``requests''.
 
 \begin{itemize}
-  \item A request to add ``a few small capabilities'' to the product withou changing the budget or
+  \item A request to add ``a few small capabilities'' to the product without changing the budget or
     schedule.
   \item A request to take on some personnel who are between projects and find something useful for them to do.
   \item A request to reduce the scope of design review (in order to make up some schedule).
@@ -151,7 +151,7 @@ Deep personal satisfaction from doing one's work in the open, and from appreciat
 
 \begin{itemize}
 \item Set standards for communications.
-\item Make sure useful developers don't get marginalized due to personal idiosyncracies.
+\item Make sure useful developers don't get marginalized due to personal idiosyncrasy.
 \end{itemize}
 
 
@@ -782,7 +782,7 @@ of each software source file.
 
 Mailing list address.  Keep discussions on-topic and productive.
 
-Change of development processs.  For example, you have to be more careful
+Change of development processes.  For example, you have to be more careful
 about your public image.
 
 Turnovers.  New arrivals.
@@ -791,7 +791,7 @@ Project stability depends on:
 
 \begin{itemize}
 \item Formal policies, written rules.
-\item Collective wisdow developed over time.
+\item Collective wisdom developed over time.
 \item Intangible, ever-evolving agreements.
 \end{itemize}
 
@@ -828,7 +828,7 @@ 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
+Look for bugs and areas of possible improvement.  Thing we could
 catch: memory leaks, off-by-one errors, insufficient comments,
 insufficient API documentation, security vulnerabilities, compliments
 ...
@@ -853,7 +853,7 @@ Why do we 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.
+\item The recent change is a good starter for getting familiar with the code base.  Also look at the affected callers and callees.
 \end{itemize}
 
 Result - better software quality.
@@ -1586,7 +1586,7 @@ Project Management Committees have a high degree of freedom.
 
 Communication is done using mailing lists (asynchronously).  Voice communication is extremely rare.  Why?
 
-Decision-making: ``meritocray'', ``do-ocracy'' power of those who do: the more you do the more you are allowed to do.  Use lazy consensus (silence means no objection). +1, 0 (no opinion), -1 (need to provide an alternative proposal).
+Decision-making: ``meritocracy'', ``do-ocracy'' power of those who do: the more you do the more you are allowed to do.  Use lazy consensus (silence means no objection). +1, 0 (no opinion), -1 (need to provide an alternative proposal).
 
 Philosophy
 
@@ -1617,18 +1617,38 @@ Requirements: a working codebase, the intention to assign sufficient intellectua
 \url{http://apache.org/foundation/how-it-works.html#management}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Project Management Committees (PMCs)}
+\foilhead{Project Management Committees at the Apache Software Foundation}
 
-https://www.apache.org/foundation/governance/pmcs.html
+The Chair is appointed by the Board.
 
+Daniel Gruno.  Apache HTTP Server.
 
-The Chair is appointed by the Board.
+Mladen Turk.  Apache Tomcat.
+
+Paul Angus.  Apache CloudStack.
+
+Matei Zaharia.  Apache Spark.
+
+Josh Thompson.  Apache VCL (Virtual Computing Lab).
+
+Vinod Kumar Vavilapalli.  Apache Hadoop.
+
+Peter Kovacs.  Apache OpenOffice.
+
+
+\url{http://www.apache.org/foundation/}
+
+Hadoop PMC: \url{http://hadoop.apache.org/who.html}
 
-Manage their projects independently.  Lead the project.  Set
-per-project policies.  Vote on product releases.  Elect new PMC
-members.
 
-Oversee the project. Main role is not code and not coding.
+
+
+Manage their projects independently.  Quite
+autonomous.  Lead and oversee the project.  Set per-project
+policies.  Vote on product releases.  Elect new
+PMC members.
+
+Main role is not code and not coding.
 
 ``Ensure balanced and wide scale peer review and collaboration.''
 
@@ -1642,6 +1662,18 @@ Communications.  (1) private@list for discussing sensitive topics (e.g., personn
 
 All project business is conducted on normal public mailing lists.
 
+\url{https://www.apache.org/foundation/governance/pmcs.html}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\foilhead{Mailing lists}
+
+``The benefit of using mailing lists over private
+communication is that it is a shared resource
+where others can also learn from common mistakes
+and as a community we all grow together.''
+
+\url{http://hadoop.apache.org/who.html}
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Review-Then-Commit or Commit-Then-Review}
 
@@ -1655,25 +1687,31 @@ CTR: make changes at will with the possibility of being retroactively vetoed.
 
 Many things to do in a project:
 
-Recruit users and developers
+\begin{itemize}
+\item Recruit users and developers.
 
-Encourage new contributors to become more deeply involved
+\item Encourage new contributors to become more deeply involved.
 
-Allow free-flowing discussion while still reaching necessary decisions
+\item Allow free-flowing discussion while still reaching necessary decisions.
 
-Maintain a body of knowledge and convention that guides newcomers and experts alike
+\item Maintain a body of knowledge and convention that guides newcomers and experts alike.
 
-Produce working software
+  Hadoop web site - Development - How to contribute
 
 
-Most important skill: \underline{writing clearly}.
+\item Produce working software.
+\end{itemize}
+
+The most important skill: \underline{writing clearly}.
 
-What matters more? Programming skills or communication skills.
+Programming skills or communication skills.  What matters more? 
 
 Is there any correlation between these two sets of skills?
 
 Without good communication skills, how do you convince others to support you?  How do you coordinate people to accomplish a complex task.
 
+\underline{Keep your readers' background in mind}
+
 How much knowledge can you assume on the part of the reader when you post an answer in a mailing list?
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1693,7 +1731,7 @@ Is your writing disorganised, illogical?
 
 \underline{Email}.  Use plain text (not html).  {\em Top-post} or quote the relevant portion of the original text first, followed by your response.  Stay under 80 columns wide for quoted code or error messages.  Write a informative, succinct subject line.
 
-\underline{Content}.  Content is the king.  Make things easy for your readers. Consider the {\em reader-to-writer ratio}. Don't exaggerate (it can hurt your credibility).
+\underline{Content}.  Content is the King.  Make things easy for your readers. Consider the {\em reader-to-writer ratio}. Don't exaggerate (it can hurt your credibility).
 
 {\tiny
 \begin{verbatim}
@@ -1709,9 +1747,9 @@ J. Random's proposal avoids those problems because it...
 \end{verbatim}
 }
 
-{\em Reread and edit}.
+{\bf Reread and edit}.  What you read in articles, newspapers, and books have undergone {\em many} revisions.
 
-\underline{Tone}. Terse.   Terseness dose not mean coldness.  Others' feelings matter: unhappy people write worse software.  So we should be careful in choosing words.
+\underline{Tone}. Be terse.   Terseness dose not mean coldness.  Others' feelings matter: unhappy people write worse software.  So we should be careful in choosing words.
 
 {\small
 \begin{verbatim}
@@ -1745,6 +1783,8 @@ Straight questions.  ``Is your computer plugged in?''
 
 Failure to provide \underline{quality} criticism can be a kind of insult.
 
+
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Face}
 
@@ -1752,15 +1792,23 @@ Use a consistent {\em screen name} everywhere: email address, IRC, repository co
 
 That name is your online ``face''.
 
+{\small
 \begin{verbatim}
 From: "Karl Fogel" <kfogel@whateverdomain.com>
 \end{verbatim}
+}
+
+
+Henk Penning (\texttt{henkp}) and Vadim Gritsenko (\texttt{vgritsenko})
+
 
 The real name is {\em real}.
 
+{\small
 \begin{verbatim}
 From: "Wonder Hacker" <wonderhacker@whateverdomain.com>
 \end{verbatim}
+}
 
 A fantastical online identity never impresses readers.   Maybe you're simply insecure.
 
@@ -1775,6 +1823,8 @@ Use brief signature blocks, or none.  A counter example: page 122 in the textboo
 
 \underline{You have to respond to everything.}
 
+{\em Silence is also communication.  If you don't know how to answer, answer using silence.  - Hui}
+
 A response should have a definite purpose.  Think twice before you post (1) what do I want to accomplish? (2) will it not get accomplished unless I say something?
 
 Respond when you see (1) flaws in a proposal (2) miscommunications.
@@ -1785,24 +1835,36 @@ Respond when you see (1) flaws in a proposal (2) miscommunications.
 
 {\small
 \begin{verbatim}
-This discussion is going nowhere. Can we please drop this topic until someone has a
-patch to implement one of these proposals? There's no reason to keep going around
-and around saying the same things. Code speaks louder than words, folks.
 
+ This discussion is going nowhere. Can we please
+ drop this topic until someone has a patch to
+ implement one of these proposals? There's no
+ reason to keep going around and around saying the
+ same things. Code speaks louder than words,
+ folks.
+
+
+ Several proposals have been floated in this
+ thread, but none have had all the details fleshed
+ out, at least not enough for an up-or-down
+ vote. Yet we're also not saying anything new now;
+ we're just reiterating what has been said
+ before. So the best thing at this point would
+ probably be for further posts to contain either a
+ complete specification for the proposed behavior,
+ or a patch. Then at least we'd have a definite
+ action to take (i.e., get consensus on the
+ specification, or apply and test the patch).
 
-Several proposals have been floated in this thread, but none have had all the details
-fleshed out, at least not enough for an up-or-down vote. Yet we're also not saying any-
-thing new now; we're just reiterating what has been said before. So the best thing at
-this point would probably be for further posts to contain either a complete specifica-
-tion for the proposed behavior, or a patch. Then at least we'd have a definite action to
-take (i.e., get consensus on the specification, or apply and test the patch).
 \end{verbatim}
 }
 
-\underline{The smaller the topic, the longer the debate}
+\underline{The smaller the topic, the longer the debate.}
 
 {\bf Bikeshed effect}: the amount of discussion is inversely proportional to the complexity of the topic.
 
+{\em Parkinson’s Law of Triviality}
+
 {\em Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions.}
 
 An atomic plant: so vast, so expensive, and so complicated that people cannot grasp.
@@ -1810,11 +1872,11 @@ An atomic plant: so vast, so expensive, and so complicated that people cannot gr
 A bikeshed: everyone knows about it.  No matter how reasonable you are with your proposal, somebody will seize the chance to show
 that he is doing his job, that he is paying attention, that he is here.
 
-\underline{Holy wars}.   Find some way to express sympathy and understanding for the points the other side is making.
-
 \underline{The ``Noisy Minority'' effect}.  The best way to counteract this effect is to point it out very clearly and provide supporting evidence showing how small the actual number of dissenters is, compared to those in agreement.
 
-\underline{Bash competing open source products}. Refrain from giving negative {\em opinions} about competing open source software. One reason: developer overlap.
+\underline{Holy wars}.   Find some way to express sympathy and understanding for the points the other side is making.
+
+\underline{Bash competing open source products}. Refrain from giving negative {\em opinions} about competing open source software. One reason: developers overlap.
 
 \underline{Difficult people}.  E.g., a filibuster (obstructionist) who keeps claiming that the matter under discussion is not ready for resolution, and offers more and more possible solutions. Purpose behind: to make everyone else take him seriously.  How to handle? Better just to tolerate it for a while.  Remember: although the other person may be the one behaving destructively, you will be the one who appears destructive if you make a public charge that you can't back up.  If you take action on him, collect examples/evidence first.
 
@@ -1947,7 +2009,7 @@ Just a progress update: we're planning to release version 2.0 of Scanley in mid-
 You can always check http://www.scanley.org/status.html for updates. 
 The major new feature will be regular-expression searches.
 
-Other new features include: ... There will also be various bugfixes, including: ...
+Other new features include: ... There will also be various bug fixes, including: ...
 
 \end{verbatim}
 }