PEP 8016: more tweaks based on discussion (#838)

* PEP 8016: more tweaks based on discussion

* Removed the requirement that council members have to be core team
  members; added the requirement that non-core-team council candidates
  need to be nominated by a core team member. Rationale: Steve Dower
  is worried that we may have a shortage of core team members who are
  willing to serve on the council. I'm not worried myself, but I like
  Steve and don't want him to worry; this is an easy way to help with
  that. Requiring a core team member nomination should be harmless,
  since any candidate that can't get a nomination is certainly not
  going to win a vote, and it lets us filter out random jokers early.

* Added some language to emphasize that emeritus core team members
  will still be listed on the website and their past contributions
  will continue to be recorded.

* Changed the vote tie-breaker from "seniority as a core team member"
  to "mutual agreement or random chance". Victor pointed out that
  seniority is not always known or unique, and anyway this doesn't
  make much sense if we're allowing non-core-team member candidates.
  The goal was always just to have some unambiguous resolution that
  doesn't require voting again, and this seems like a simpler and more
  reliable option.

* Clarified that in the never-going-to-happen edge case where a core
  team member misbehaves so badly that the project has to kick them
  out AND that core team member is on the council, then they're also
  removed from the council.

* Added link to the second discussion thread.

* Made a few small wording tweaks and fixed some ReST formatting.

* PEP 8016: fix the definition of "Python committer" to match reality

* Rephrase the emeritus text again, to hopefully be even more clear

* One more wording tweak

* s/emeritus/inactive/, and remove the [TBD]

pep-8016.rst

@@ -49,8 +49,10 @@ The main goals of this proposal are:
 
 A number of details were discussed in `this Discourse thread
 <https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/>`__,
-which may be useful to anyone trying to understand the rationale for
-various minor decisions.
+and then `this thread has further discussion
+<https://discuss.python.org/t/pep-8016-the-steering-council-model/394>`__. These
+may be useful to anyone trying to understand the rationale for various
+minor decisions.
 
 
 Specification
@@ -62,13 +64,13 @@ The steering council
 Composition
 ~~~~~~~~~~~
 
-The steering council is an elected committee of 5 core team members.
+The steering council is a 5-person committee.
 
 
 Mandate
 ~~~~~~~
 
-The steering council's shall work to:
+The steering council shall work to:
 
 * Maintain the quality and stability of the Python language and
   CPython interpreter,
@@ -90,9 +92,10 @@ The council has broad authority to make decisions about the project.
 For example, they can:
 
 * Accept or reject PEPs
-* Enforce the Python code of conduct
+* Enforce or update the project's code of conduct
 * Work with the PSF to manage any project assets
-* Delegate their authority to other subcommittees or processes
+* Delegate parts of their authority to other subcommittees or
+  processes
 
 However, they cannot modify this PEP, or affect the membership of the
 core team, except via the mechanisms specified in this PEP.
@@ -118,23 +121,25 @@ Electing the council
 
 A council election consists of two phases:
 
-* Phase 1: Candidates advertise their interest in serving. Only core
-  team members may be candidates.
+* Phase 1: Candidates advertise their interest in serving. Candidates
+  must be nominated by a core team member. Self-nominations are
+  allowed.
 
 * Phase 2: Each core team member can vote for zero to five of the
   candidates. Voting is performed anonymously. Candidates are ranked
-  by the total number of votes they receive. In case of a tie, the
-  candidate who joined the core team earlier wins.
+  by the total number of votes they receive. If a tie occurs, it may
+  be resolved by mutual agreement among the candidates, or else the
+  winner will be chosen at random.
 
 Each phase lasts one to two weeks, at the outgoing council's discretion.
 For the initial election, both phases will last two weeks.
 
 The election process is managed by a returns officer nominated by the
 outgoing steering council. For the initial election, the returns
-officer will be [TBD].
+officer will be nominated by the PSF Executive Director.
 
-The council should ideally reflect the diversity of core Python
-contributors, and core team members are encouraged to vote
+The council should ideally reflect the diversity of Python
+contributors and users, and core team members are encouraged to vote
 accordingly.
 
 
@@ -152,8 +157,8 @@ Vacancies
 Council members may resign their position at any time.
 
 Whenever there is a vacancy during the regular council term, the
-council may vote to appoint any willing core team member to serve out
-the rest of the term.
+council may vote to appoint a replacement to serve out the rest of the
+term.
 
 If a council member drops out of touch and cannot be contacted for a
 month or longer, then the rest of the council may vote to replace
@@ -193,6 +198,9 @@ required for such a vote to succeed. In addition, this is the one
 power of the steering council which cannot be delegated, and this
 power cannot be used while a vote of no confidence is in process.
 
+If the ejected core team member is also on the steering council, then
+they are removed from the steering council as well.
+
 
 Vote of no confidence
 ~~~~~~~~~~~~~~~~~~~~~
@@ -242,14 +250,14 @@ repositories, the bug tracker, the mailing lists, IRC channels, etc.
 
 
 Prerogatives
-------------
+~~~~~~~~~~~~
 
 Core team members may participate in formal votes, typically to nominate new
 team members and to elect the steering council.
 
 
 Membership
-----------
+~~~~~~~~~~
 
 Python core team members demonstrate:
 
@@ -288,17 +296,21 @@ to the core team's vote when they're ready.
 There's no time limit on core team membership. However, in order to
 provide the general public with a reasonable idea of how many people
 maintain Python, core team members who have stopped contributing are
-encouraged to declare themselves as "emeritus members". Those who
-haven't made any non-trivial contribution in two years may be asked to
-move themselves to this category, and moved there if they don't
-respond. Emeritus team members lose their privileges such as voting
-rights and commit access. If an emeritus team member later resumes
-contributing, they may rejoin the core team on request, without the
-need for a vote.
+encouraged to declare themselves as "inactive". Those who haven't made
+any non-trivial contribution in two years may be asked to move
+themselves to this category, and moved there if they don't respond. To
+record and honor their contributions, inactive team members will
+continue to be listed alongside active core team members; and, if they
+later resume contributing, they can switch back to active status at
+will. While someone is in inactive status, though, they lose their
+active privileges like voting or nominating for the steering council,
+and commit access.
 
-The initial core team will consist of everyone who has commit access
-in the Python organization on Github, and the initial emeritus members
-will consist of everyone who has been a committer in the past.
+The initial active core team members will consist of everyone
+currently listed in the `"Python core" team on Github
+<https://github.com/orgs/python/teams/python-core/members>`__, and the
+initial inactive members will consist of everyone else who has been a
+committer in the past.
 
 
 Changing this document
@@ -311,10 +323,6 @@ votes cast in a core team vote.
 TODO
 ====
 
-- Maybe add compare-and-contrast with other 801x proposals?
-
-- Ask Ian or Ernest if they're willing to be the initial returns officer.
-
 - Lots of people contributed helpful suggestions and feedback; we
   should check if they're comfortable being added as co-authors