PEP 8015: rephrase some paragraphs

pep-8015.rst

@@ -30,19 +30,20 @@ community, from Python users to the Python Steering Committee.
 Describing all groups and all roles in the same document helps to make
 the organization more consistent.
 
-The number of governance changes is minimized to get a smooth transition from
+The number of governance changes is minimized to get a smooth transition
-the old to the new organization.
+from the old BDFL organization to the new Steering Committee
+organization.
 
 One key design of the organization is to avoid decision bottlenecks.
 Discussions and decisions are distributed into Python teams where
 experts in each topic can be found. The expectation is smoother
 discussions on PEPs: fewer people with better knowledge of the topic.
 
-Previously, almost all decisions have been taken by the Benevolent
+Previously, most decisions have been taken by the Benevolent
-Dictator For Life (BDFL). The growing popularity of Python increased the
+Dictator For Life (BDFL), Guido van Rossum. The growing popularity of
-pressure on a single person. The proposed organization distributes
+Python increased the pressure on a single person. The proposed
-decisions and responsibilities to reduce the pressure and avoid wearing
+organization distributes decisions and responsibilities to reduce the
-any individual down.
+pressure and avoid wearing any individual down.
 
 To keep most of the decision power within the hands of the community,
 the Python Steering Committee has very limited roles. The idea is to reduce the risk
@@ -51,9 +52,8 @@ through just a couple individuals. The project must remain autonomous
 and open to everybody.
 
 The most sensitives PEPs are decided by democracy: a vote reserved to
-core developers, a PEP is only approved if the number of "+1" exceed the
+core developers, see the `PEP process`_ section below for the voting
-number of "-1" (see the `PEP process`_ section below for the vote
+method.
-details).
 
 
 Common Guidelines
@@ -63,8 +63,7 @@ Common Guidelines
 * Members must respect the `Python Community Code of Conduct
   <https://www.python.org/psf/codeofconduct/>`_ which ensures that
   discussions remain constructive and that everybody feels welcomed.
-* Python is and will remain an autonomous project. It cannot be owned by
+* Python is and will remain an autonomous project.
-  a company.
 * People with decisions power should reflect the diversity of its users
   and contributors.
 
@@ -73,7 +72,7 @@ Community Organization
 ======================
 
 Right now, there are different group of people involved in the Python
-project. The more involved you are, the most decisions power you get. It
+project. The more involved you are, the more decisions power you get. It
 is important that the people acceding to the deepest group are the most
 trusted ones.
 
@@ -118,14 +117,13 @@ team is self-organized and is responsible to select who can join the
 team and how.
 
 Team members can get the bug triage permission on the team bug tracker
-component. Working in a team is a nice way to learn more to maybe later
+component. The more involved in a team you are, the more decisions power
-become a core developer.
+and responsibilities you get.
 
 A team might become allowed to decide on their own PEPs, but only the
 Python Steering Committee can allow that (and it has the power to revoke
-it as well).
+it as well). Such a case is exceptional, currently a single team has
-Such a case is exceptional, currently a single team has such permission:
+such permission: the Packaging Team.
-the Packaging team.
 
 See `Annex: Examples of Python Teams`_.
 
@@ -138,17 +136,18 @@ change (anywhere in the code) and have the bug triage permission
 (on all bug tracker components).
 
 Core developers are developers who are proven to have the required skills to
-decide if a change can be approved or must be rejected. Python has a
+decide if a change can be approved or must be rejected, but also (and
+this is more important) what changes should not be made. Python has a
 long history, big constraints on backward compatibility, high quality
 standards (ex: changes require new tests). For these reasons, becoming
 a core can take several months or longer.
 
 Becoming a core developer means more responsibilities. For example, if a
-developer approves a change, they become indirectly responsible for
+developer merges a change, they become responsible for regressions and
-regressions and for the maintenance of that modified code.
+for the maintenance of that modified code.
 
-Core developers are also expected to be exemplary when it comes to the
+Core developers are expected to be exemplary when it comes to the Code
-Code of Conduct. They are encouraged to mentor contributors.
+of Conduct. They are encouraged to mentor contributors.
 
 Promote a contributor as core developer
 ---------------------------------------
@@ -167,9 +166,10 @@ votes approve ("+1") the promotion. Only "+1" and "-1" votes are
 accounted; other votes (ex: null, "-0", "+0.5") are ignored.
 
 If the candidate is promoted, usually they get a mentor for 1 month to
-help them to handle new responsibilities. If the candidate is not
+help them to handle new responsibilities.
-promoted, a new vote can be organized later, when the candidate gets the
+
-missing skills, for example 6 months later.
+If the candidate is not promoted, a new vote can be organized later,
+when the candidate gets the missing skills, for example 6 months later.
 
 
 Python Steering Committee
@@ -180,9 +180,9 @@ developers since it has the most decision power. The roles of this group
 are strictly limited to ensure that Python keeps its autonomy and
 remains open.
 
-Steering Committee members are elected for 3 years, a third of it is refreshed every
+Steering Committee members are elected for 3 years, a member is replaced
-year. This way, a member will stay for one full Python release but the
+every year. This way, a member will stay for one full Python release and
-committee composition will be updated frequently.
+the committee composition will be updated frequently.
 
 Python Steering Committee Roles
 -------------------------------
@@ -199,10 +199,12 @@ options:
 
 * The committee elects a PEP delegate (previously known as "BDFL-delegate"):
   a core developer who will take the final decision for the specific
-  PEP. The Python team of the PEP or the committee select the PEP delegate.
+  PEP. The committee select the PEP delegate who can be proposed by the
-* If the committee decides that the PEP is too risky (like language
+  Python team where the PEP is discussed.
-  changes), a vote is organized (see `PEP process`_ for the
+* The committee can organize a vote on on the PEP, see `PEP process`_
-  vote organization). The committee decides when the vote is organized.
+  for the vote organization. The committee decides when the vote is
+  organized. A vote is preferred for changes affecting all Python users,
+  like language changes.
 
 The committee keeps the "vision" and consistency of Python. It also makes
 sure that important features reach completion. Their ability to pick PEP
@@ -213,7 +215,8 @@ Election of Python Steering Committee Members
 
 The Python Steering Committee is composed of 3 members. They are elected
 for three year terms, and each year a member is replaced. A committee
-member can be a candidate for the seat they are leaving.
+member can be a candidate for the seat they are leaving (with a total
+limit of 2 mandates, see below).
 
 Committee members must be Python core developers. It is important that
 the members of the committee reflect the diversity of Python' users and
@@ -245,10 +248,9 @@ is responsible to seleect the elected member.
 If a committee member steps down, a new vote is organized to replace them.
 If the situation of a committee member changes in a way that no longer
 satisfies the committee constraint (eg: they move to the same company as
-another committee member), they have to resign. If the employer is
+another committee member), they have to resign. If the employer of a
 member is acquired by the employer of another member, the member with
-the mandate ending the first has to resign once the acquisition
+the mandate ending earlier has to resign once the acquisition completes.
-completes.
 
 Election Creating the Python Steering Committee Members
 -------------------------------------------------------
@@ -291,9 +293,9 @@ Special Case: Steering Committee Members And PEPs
 
 A committee member cannot be a PEP delegate.
 
-A committee member can offer a PEP, but cannot decide how their own PEP
+A committee member can prpose a PEP, but cannot decide how their own PEP
-is approved. In this case, the two other board members are responsible
+is approved. In this case, the two other board members decide how this
-to decide how the PEP is approved.
+PEP is approved.
 
 When the committee decides that a PEP must be voted, committee members
 can vote as they are also core developers, but they don't have more
@@ -334,6 +336,8 @@ Special Case: Ban a core developer
 As any other member of the Python community, the PSF Code of Conduct
 Workgroup can ban a core developer for a limited amount of time. In this
 case, the core developer immediately loses their core developer status.
+Core developers are expected to be exemplary when it comes to the Code
+of Conduct.
 
 In general, a ban is only the last resort action when all other options
 have been exhausted.
@@ -362,7 +366,7 @@ and is the one taking the final decision (accept, reject or defer the
 PEP). They can also help to guide the discussion.
 
 If no decision is taken, the authors can propose again the PEP later
-(ex: one year later), if possible with new data to motive the change. A
+(ex: one year later), if possible with new data to motivate the change. A
 PEP Delegate can also choose to mark a PEP as "Deferred" to not reject
 the PEP and encourage to reopen the discussion later.
 
@@ -382,18 +386,21 @@ the 1 week notice, but must not be modified during the vote. Such vote
 happens on
 the mailing list where the PEP has been discussed. The committee decides
 when the vote is organized. The PEP must have been discussed for a
-reasonable amount of time before it is put to vote. A PEP is only
+reasonable amount of time before it is put to vote.
-approved if two thirds (``>= 2/3``) of votes approve ("+1") the PEP.
+
-Only "+1" and "-1" votes are accounted; other votes (ex: null, "-0",
+A PEP is only approved if two thirds (``>= 2/3``) of votes approve
-"+0.5") are ignored.
+("+1") the PEP.  Only "+1" and "-1" votes are accounted; other votes
+(ex: null, "-0", "+0.5") are ignored.
+
+A PEP can only be approved or rejected by a vote, not be deferred.
 
 
 Lack of Decision
 ================
 
-If a discussion fails to reach a consensus, if the Python Steering Committee fail to choose
+If a discussion fails to reach a consensus, if the Python Steering
-a PEP delegate for a PEP, or if a PEP delegate fails to take a decision,
+Committee fail to choose a PEP delegate, or if a PEP delegate fails to
-the obvious risk is that Python fails to evolve.
+take a decision, the obvious risk is that Python fails to evolve.
 
 That's fine. Sometimes, doing nothing is the wisest choice.
 
@@ -405,16 +412,18 @@ The first version of this PEP has been written after Guido van Rossum
 decided to resign from his role of BDFL in July 2018. Before this PEP,
 the roles of Python community members have never been formalized. It is
 difficult to design a perfect organization at the first attempt. This
-PEP can be updated in the future to adjust the organization.
+PEP can be updated in the future to adjust the organization, specify how
+to handle corner cases and fix mistakes.
 
 Any change to this PEP must be validated by a vote. The vote is
 announced 3 weeks in advance, is reserved to core developers, happens in
 public on the python-committers mailing list, and is open for 1 week.
 The proposed PEP change can still be updated during the 3 weeks notice,
-but must not be modified during the vote. The change is only approved if
+but must not be modified during the vote.
-four fiths (``>= 4/5``) of votes approve ("+1") the change. Only "+1"
+
-and "-1" votes are accounted; other votes (ex: null, "-0", "+0.5") are
+The change is only approved if four fifths (``>= 4/5``) of votes approve
-ignored.
+("+1") the change. Only "+1" and "-1" votes are accounted; other votes
+(ex: null, "-0", "+0.5") are ignored.
 
 
 Annex: Summary on votes
@@ -425,8 +434,8 @@ Vote                    Notice   Open    Ballot   Method
 ======================  =======  ======  =======  =================================
 Promote contributor     none     1 week  public   ``>= 2/3`` majority
 PEP                     1 week   1 week  public   ``>= 2/3`` majority
-Steering Committee      3 weeks  1 week  private  Condorcet (Schulze/Beatpath/CSSD)
 Change this PEP         3 weeks  1 week  public   ``>= 4/5`` majority
+Steering Committee      3 weeks  1 week  private  Condorcet (Schulze/Beatpath/CSSD)
 ======================  =======  ======  =======  =================================
 
 All these votes are reserved to core developers.