Version 2 updates (#831)

* Version 2 updates

pep-8010.rst

@@ -1,5 +1,5 @@
 PEP: 8010
-Title: The BDFL Governance Model
+Title: The Technical Leader Governance Model
 Author: Barry Warsaw <barry@python.org>
 Status: Active
 Type: Informational
@@ -10,8 +10,8 @@ Created: 2018-08-24
 Abstract
 ========
 
-This PEP proposes a continuation of the singular project leader model,
-euphemistically called the `Benevolent Dictator For Life
+This PEP proposes a continuation of the singular technical project
+leader model, euphemistically called the `Benevolent Dictator For Life
 <https://en.wikipedia.org/wiki/Benevolent_dictator_for_life>`_ (BDFL)
 model of Python governance, to be henceforth called in this PEP the
 Gracious Umpire Influencing Decisions Officer (GUIDO).  This change in
@@ -23,7 +23,7 @@ well-being of either the language or the GUIDO themselves.
 
 This PEP describes:
 
-* The rationale for maintaining the singular leader model
+* The rationale for maintaining the singular technical leader model
 * The process for how the GUIDO will be selected, elected, retained,
   recalled, and succeeded;
 * The roles of the GUIDO in the Python language evolution process;
@@ -36,7 +36,7 @@ This PEP describes:
 
 This PEP does *not* name a new BDFL.  Should this model be adopted, it will be
 codified in PEP 13 along with the names of all officeholders described in this
-PEP, as voted on per the guidelines in PEP 8001.
+PEP.
 
 
 Open discussion points
@@ -47,15 +47,17 @@ governance discussion process, such as the exact size of the CoP, term
 lengths of service, and voting procedures.  These will be codified by
 the time the PEP is ready to be voted on.
 
+The voting procedures and events described in this PEP will default to
+the voting method specified in PEP 8001, although as that PEP is still
+in discussion at the time of this writing, this is subject to change.
+
 It is allowed, and perhaps even expected, that as experience is gained
 with this model, these parameters may be tweaked as future GUIDOs are
-named, in order to provide for a smoother governing process.  The
-process for tweaking these parameters will generally be the same
-voting process as described in PEP 8001.
+named, in order to provide for a smoother governing process.
 
 
-Why a singular leader?
-======================
+Why a singular technical leader?
+================================
 
 Why this model rather than any other?  It comes down to "vision".
 `Design by committee`_ has many known downsides, leading to a language
@@ -65,15 +67,15 @@ designed by committee".  Can a language that is designed by committee
 "hang together"?  Does it feel like a coherent, self-consistent
 language where the rules make sense and are easily remembered?
 
-A singular leader can promote that vision more than a committee can,
-whether that committee is small (e.g. 3 or 5 persons) or spans the
-entire Python community.  Every participant will have their own vision
-of what "Python" is, and this can lead to indecision or illogical
-choices when those individual visions are in conflict.  Should CPython
-be 3x faster or should we preserve the C API?  That's a very difficult
-question to get consensus on, since neither choice is right or wrong.
-But worse than making the wrong decision might be accepting the status
-quo because no consensus could be found.
+A singular technical leader can promote that vision more than a
+committee can, whether that committee is small (e.g. 3 or 5 persons)
+or spans the entire Python community.  Every participant will have
+their own vision of what "Python" is, and this can lead to indecision
+or illogical choices when those individual visions are in conflict.
+Should CPython be 3x faster or should we preserve the C API?  That's a
+very difficult question to get consensus on, since neither choice is
+right or wrong.  But worse than making the wrong decision might be
+accepting the status quo because no consensus could be found.
 
 
 Flexibility
@@ -163,6 +165,10 @@ the remainder of the original GUIDO's term, at which time a new
 election is conducted.  The GUIDO stepping down may continue to serve
 until their replacement is selected.
 
+During the transition period, the CoP (see below) may carry out the
+GUIDO's duties, however they may also prefer to leave substantive
+decisions (such as technical PEP approvals) to the incoming GUIDO.
+
 
 Choosing a GUIDO
 ================
@@ -234,7 +240,7 @@ both cases, voting is done by the same procedure as in PEP 8001, and
 all core developers may participate in no confidence votes.
 
 The first vote is whether to recall the current GUIDO or not.  Should
-a simple majority of Python developers vote "no confidence", the GUIDO
+a super majority of Python developers vote "no confidence", the GUIDO
 is recalled.  A second vote is then conducted to select the new GUIDO,
 in accordance with the procedures for initial section of this office
 holder.  During the time in which there is no GUIDO, major decisions
@@ -263,7 +269,8 @@ However, in the case of the GUIDO authoring a PEP, an impartial PEP
 Delegate should be selected, and given the authority to accept or
 reject the PEP.  The GUIDO should recuse themselves from the decision
 making process.  In the case of controversial PEPs where a clear
-consensus does not arrive, ultimate authority rests with the CoP.
+consensus does not arrive, ultimate authority on PEPs authored by the
+GUIDO rests with the CoP.
 
 The PEP propose is further enhanced such that a core developer must
 always be chose as the PEP Shepherd.  This person ensure that proper
@@ -273,6 +280,19 @@ PEPs must have some level of sponsorship from at least one core
 developer.
 
 
+Version History
+===============
+
+Version 2
+
+ - Renamed to "The Technical Leader Governance Model"
+ - "singular leader" -> "singular technical leader"
+ - The adoption of PEP 8001 voting procedures is tentative until that
+   PEP is approved
+ - Describe what happens if the GUIDO steps down
+ - Recall votes require a super majority of core devs to succeed
+
+
 Copyright
 =========