From 04861b27bca40f6dc8a7702b6880aabb1b61cc08 Mon Sep 17 00:00:00 2001
From: Hui Lan <lanhui@zjnu.edu.cn>
Date: Sun, 26 Apr 2020 12:22:46 +0800
Subject: spm-slides.tex: add stuff from Chapter 4 of Karl Fogel. Producing
 Open Source Software: How to Run a Successful Free Software Project. Second
 Edition. https://producingoss.com/

---
 spm-slides.tex | 71 ++++++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 57 insertions(+), 14 deletions(-)

(limited to 'spm-slides.tex')

diff --git a/spm-slides.tex b/spm-slides.tex
index 88432ac..a18ba3b 100644
--- a/spm-slides.tex
+++ b/spm-slides.tex
@@ -2493,37 +2493,61 @@ Presence on mainstream social media platform.
 
 How does it work?
 
-What keeps the free software project running, on a day-to-day basis?
+Who makes the decisions?
 
 How conflicts are resolved?
 
-Who makes the decisions?
+What keeps the free software project running, on a day-to-day basis?
+
+Easy answers: meritocracy,  cooperation, running code.
 
 Success is \underline{not} only about technical success.
 
-Operational health: ongoing ability to incorporate new code contributions and new developers, and to be responsive to incoming bug reports.
+Operational Health: ongoing ability to incorporate new code contributions and new developers, and to be responsive to incoming bug reports.
 
 Survivability: ability to exist independently of any individual participant or sponsor.
 
-Governance structure and established procedures well followed by participants.
+Bus Factor.
+% Readings on bus factor
+% - https://blog.sandglaz.com/increasing-bus-factor-in-project-management/
+% - https://pm.stackexchange.com/questions/10434/how-can-a-project-manager-mitigate-the-risks-associated-with-a-low-bus-factor
+
+Institutional permanence achieved by:
+
+\begin{itemize}
+\item Formal governance structure and established procedures well followed by participants.
+\item Atmosphere of fairness.
+\end{itemize}
 
 %meritocracy???
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Fork and forkability}
+\foilhead{Fork and Forkability}
 
 Take a copy of the source code and use it to start a competing project, known as a \underline{fork}.
 
-Result: no true dictators in free software projects.
+Consequence: no true dictators in free software projects.
 
 Bad decisions would eventually bring about a revolt and a fork.
 
-%by fiat, anointed the BD,  leadership by a charismatic individual
+Hard fork.
+
+Possibility of forks.
+
+Actual forks.
+
+%By fiat, anointed the BD,  leadership by a charismatic individual
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Benevolent dictators}
+\foilhead{Benevolent Dictators}
+
+The person who makes the final decisions.
 
-One person makes the \underline{final} decisions.
+Personality and Experience.
+
+{\em Reluctance to make decisions}: in most cases, defer to domain experts or area maintainers.
+
+Let other people discuss.
 
 BD - community-approved arbitrator. For example, the founder of a project.
 
@@ -2536,17 +2560,31 @@ Traits of a good BD.  (1) Self-restraint.  No BD's personal opinions or conclusi
 If the project has an obvious, good candidate BD, then that's the way to go.  Otherwise, use democracy.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Consensus-based democracy}
+\foilhead{Consensus-based Democracy}
 
 Group-based governance is more ``evolutionary stable''.
 
 If a group of N people were to give one person with special power, it would mean that N-1 people were each agreeing
 to decrease their individual influence.  People usually don't want to do that.
 
-Discussion and voting (head count).  Identify key issues.  Do approval voting (each voter can vote for as many of the choices on the ballot).   Consensus simply means an agreement that everyone is willing to live with.  Software: https://vote.heliosvoting.org/. Guidelines: https://www.apache.org/foundation/voting.html
+Discussion and voting (head count).
+
+Identify key issues.
+
+{\em Honest Broker} who summarizes arguments in a complex discussion.
+
+Approval voting (each voter can vote for as many of the choices on the ballot).
+
+{\bf Arrow's Impossibility Theorem} - no voting system is perfect.
+
+Consensus simply means an agreement that everyone is willing to live with.
+
+Software: https://vote.heliosvoting.org/. Guidelines: https://www.apache.org/foundation/voting.html
 
 Compromise or vote?  Voting ends creative thinking to solve a problem.
 
+Use voting as a last resort.
+
 We should prevent a premature vote. ``I don't think we are ready for a vote yet''.  Show hands.  Offer a new solution, or a new viewpoint.
 
 Voters do not have to be coders (committers).  People who did valuable contributions to the project can be voters, e.g., people who provide legal help, or organize events, or manage the bug tracker, or write documentation.
@@ -2565,21 +2603,26 @@ Make sure there is a write-in option (a better option not mentioned in the poll
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \foilhead{Vetos}
 
+Veto - a strong objection.
+
 A veto (-1) can halt a hasty or ill-considered change, at least long enough for everyone to discuss it more.
 
+Veto abuse.
+
 Any veto should be accompanied by a thorough explanation.
 
 A veto can be overridden if there is a clear majority for moving on.
 
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Consensus approval versus majority approval}
+\foilhead{Consensus Approval versus Majority Approval}
 
 Consensus approval: at least three binding +1 votes and no vetos.
 
 Majority approval: at least three binding +1 votes and more +1 votes than -1 votes.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\foilhead{Writing it all down}
+\foilhead{Writing It All Down}
 
 At some point, the number of conventions and agreements floating around in your project may become
 so great that you need to record it somewhere, linking to mailing list discussions.
@@ -2590,7 +2633,7 @@ Base the document on the questions that newcomers ask most often, and on the com
 
 Make it clear that the rules can be reconsidered.
 
-Project guidelines:
+Good Project Guidelines (from accumulated experience of a lot of open source projects)
 
 https://wiki.documentfoundation.org/Development
 
-- 
cgit v1.2.1

