464 lines
29 KiB
HTML
464 lines
29 KiB
HTML
|
||
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<meta name="color-scheme" content="light dark">
|
||
<title>PEP 8013 – The External Council Governance Model | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-8013/">
|
||
<link rel="stylesheet" href="../_static/style.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
|
||
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
|
||
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
|
||
<meta property="og:title" content='PEP 8013 – The External Council Governance Model | peps.python.org'>
|
||
<meta property="og:description" content="This PEP proposes a new model of Python governance based on a Council of Auditors (CoA) tasked with making final decisions for the language. It differs from PEP 8010 by specifically not proposing a central singular leader, and from PEP 8011 by disallowi...">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-8013/">
|
||
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
|
||
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
|
||
<meta property="og:image:alt" content="Python PEPs">
|
||
<meta property="og:image:width" content="200">
|
||
<meta property="og:image:height" content="200">
|
||
<meta name="description" content="This PEP proposes a new model of Python governance based on a Council of Auditors (CoA) tasked with making final decisions for the language. It differs from PEP 8010 by specifically not proposing a central singular leader, and from PEP 8011 by disallowi...">
|
||
<meta name="theme-color" content="#3776ab">
|
||
</head>
|
||
<body>
|
||
|
||
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
|
||
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Following system colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="9"></circle>
|
||
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected dark colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
|
||
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected light colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="5"></circle>
|
||
<line x1="12" y1="1" x2="12" y2="3"></line>
|
||
<line x1="12" y1="21" x2="12" y2="23"></line>
|
||
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
|
||
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
|
||
<line x1="1" y1="12" x2="3" y2="12"></line>
|
||
<line x1="21" y1="12" x2="23" y2="12"></line>
|
||
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
|
||
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
|
||
</svg>
|
||
</symbol>
|
||
</svg>
|
||
<script>
|
||
|
||
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
|
||
</script>
|
||
<section id="pep-page-section">
|
||
<header>
|
||
<h1>Python Enhancement Proposals</h1>
|
||
<ul class="breadcrumbs">
|
||
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li>
|
||
<li><a href="../pep-0000/">PEP Index</a> » </li>
|
||
<li>PEP 8013</li>
|
||
</ul>
|
||
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
|
||
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
|
||
</button>
|
||
</header>
|
||
<article>
|
||
<section id="pep-content">
|
||
<h1 class="page-title">PEP 8013 – The External Council Governance Model</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Steve Dower <steve.dower at python.org></dd>
|
||
<dt class="field-even">Status<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Formally declined and will not be accepted">Rejected</abbr></dd>
|
||
<dt class="field-odd">Type<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd>
|
||
<dt class="field-even">Topic<span class="colon">:</span></dt>
|
||
<dd class="field-even"><a class="reference external" href="../topic/governance/">Governance</a></dd>
|
||
<dt class="field-odd">Created<span class="colon">:</span></dt>
|
||
<dd class="field-odd">14-Sep-2018</dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#pep-rejection">PEP Rejection</a></li>
|
||
<li><a class="reference internal" href="#the-importance-of-the-grey-area">The Importance of the Grey Area</a></li>
|
||
<li><a class="reference internal" href="#model-overview">Model Overview</a><ul>
|
||
<li><a class="reference internal" href="#key-people-and-their-functions">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#regular-decision-process">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#controversial-decision-process">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#election-terms">Election terms</a></li>
|
||
<li><a class="reference internal" href="#election-voting-process">Election voting process</a></li>
|
||
<li><a class="reference internal" href="#no-confidence-voting-process">No-confidence voting process</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#examples-of-intended-behaviour">Examples of intended behaviour</a><ul>
|
||
<li><a class="reference internal" href="#scenario-1-the-case-of-the-vague-pep">Scenario 1 - The Case of the Vague PEP</a></li>
|
||
<li><a class="reference internal" href="#scenario-2-the-case-of-the-endless-discussion">Scenario 2 - The Case of the Endless Discussion</a></li>
|
||
<li><a class="reference internal" href="#scenario-3-the-case-of-the-unconsidered-users">Scenario 3 - The Case of the Unconsidered Users</a></li>
|
||
<li><a class="reference internal" href="#scenario-4-the-case-of-the-delegated-decision">Scenario 4 - The Case of the Delegated Decision</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<section id="abstract">
|
||
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
||
<p>This PEP proposes a new model of Python governance based on a Council
|
||
of Auditors (CoA) tasked with making final decisions for the language.
|
||
It differs from <a class="pep reference internal" href="../pep-8010/" title="PEP 8010 – The Technical Leader Governance Model">PEP 8010</a> by specifically not proposing a central
|
||
singular leader, and from <a class="pep reference internal" href="../pep-8011/" title="PEP 8011 – Python Governance Model Lead by Trio of Pythonistas">PEP 8011</a> by disallowing core committers from
|
||
being council members. It describes the size and role of the council,
|
||
how the initial group of council members will be chosen, any term
|
||
limits of the council members, and how successors will be elected.</p>
|
||
<p>It also spends significant time discussing the intended behaviour of
|
||
this model. By design, many processes are not specified here but are
|
||
left to the people involved. In order to select people who will make
|
||
the best decisions, it is important for those involved to understand
|
||
the expectations of the CoA but it is equally important to allow the
|
||
CoA the freedom to adjust process requirements for varying
|
||
circumstances. This only works when process is unspecified, but all
|
||
participants have similar expectations.</p>
|
||
<p>This PEP does <em>not</em> name the members of the CoA. Should this model be
|
||
adopted, it will be codified in <a class="pep reference internal" href="../pep-0013/" title="PEP 13 – Python Language Governance">PEP 13</a> along with the names of all
|
||
officeholders described in this PEP.</p>
|
||
</section>
|
||
<section id="pep-rejection">
|
||
<h2><a class="toc-backref" href="#pep-rejection" role="doc-backlink">PEP Rejection</a></h2>
|
||
<p><a class="pep reference internal" href="../pep-8013/" title="PEP 8013 – The External Council Governance Model">PEP 8013</a> was rejected <a class="reference external" href="https://discuss.python.org/t/python-governance-vote-december-2018-results/546/">by a core developer vote</a>
|
||
described in <a class="pep reference internal" href="../pep-8001/" title="PEP 8001 – Python Governance Voting Process">PEP 8001</a> on Monday, December 17, 2018.</p>
|
||
<p><a class="pep reference internal" href="../pep-8016/" title="PEP 8016 – The Steering Council Model">PEP 8016</a> and the governance model it describes were chosen instead.</p>
|
||
</section>
|
||
<section id="the-importance-of-the-grey-area">
|
||
<h2><a class="toc-backref" href="#the-importance-of-the-grey-area" role="doc-backlink">The Importance of the Grey Area</a></h2>
|
||
<p>In any actual decision-making process, there is going to be grey area.
|
||
This includes unexpected scenarios, and cases where there is no
|
||
“correct” answer.</p>
|
||
<p>Many process plans attempt to minimise grey area by defining processes
|
||
clearly enough that no flexibility is required.</p>
|
||
<p>This proposal deliberately goes the other way. The aim is to provide a
|
||
robust framework for choosing the best people to handle unexpected
|
||
situations, without defining how those people should handle those
|
||
situations.</p>
|
||
<p>Examples are provided of “good” responses to some situations as an
|
||
illustration. The hope is that the “best” people are the best because
|
||
they would live up to those examples. The process that is proposed has
|
||
been designed to minimise the damage that may be caused when those
|
||
people turn out not to be the best.</p>
|
||
<p>Grey area is guaranteed to exist. This proposal deliberately embraces
|
||
and works within that, rather than attempting to prevent it.</p>
|
||
</section>
|
||
<section id="model-overview">
|
||
<h2><a class="toc-backref" href="#model-overview" role="doc-backlink">Model Overview</a></h2>
|
||
<section id="key-people-and-their-functions">
|
||
<h3><a class="toc-backref" href="#key-people-and-their-functions" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>The Council of Auditors (CoA) is a council of varying size, typically
|
||
two to four people, who are elected for the duration of a Python
|
||
release. One member of the CoA is considered the President, who has
|
||
some minor points of authority over the other members.</p>
|
||
<p>The CoA has responsibility for reviewing controversial decisions in
|
||
the form of PEPs written by members of the core development team. The
|
||
CoA may choose to accept a PEP exactly as presented, or may request
|
||
clarification or changes. These changes may be of any form and for any
|
||
reason. This flexibility is intentional, and allows the process to
|
||
change over time as different members are elected to the CoA. See the
|
||
later sections of this document for examples of the kinds of requests
|
||
that are expected.</p>
|
||
<p>The CoA only pronounces on PEPs submitted to python-committers. There
|
||
is no expectation that the CoA follows or participates on any other
|
||
mailing lists. (Note that this implies that only core developers may
|
||
submit PEPs. Non-core developers may write and discuss proposals on
|
||
other mailing lists, but without a core developer willing to support
|
||
the proposal by requesting pronouncement, it cannot proceed to
|
||
acceptance. This is essentially the same as the current system, but is
|
||
made explicit here to ensure that members of the CoA are not expected
|
||
to deal with proposals that are not supported by at least one core
|
||
developer.)</p>
|
||
<p>The CoA may not delegate authority to individuals who have not been
|
||
elected by the core developer team. (One relevant case here is that
|
||
this changes the implementation of the existing BDFL-Delegate system,
|
||
though without necessarily changing the spirit of that system. See the
|
||
later sections, particularly example scenario four, for more
|
||
discussion on this point.)</p>
|
||
<p>The Release Manager (RM) is also permitted the same ability to request
|
||
changes on any PEPs that specify the release they are responsible for.
|
||
After feature freeze, the RM retains this responsibility for their
|
||
release, while the CoA rotates and begins to focus on the subsequent
|
||
release. This is no different from the current process. The process
|
||
for selection of a RM is not changed in this proposal.</p>
|
||
<p>Core developers are responsible for electing members of the CoA, and
|
||
have the ability to call a “vote of no confidence” against a member of
|
||
the CoA. The details of these votes are discussed in a later section.</p>
|
||
<p>Where discussions between core developers and members of the CoA
|
||
appear to be ongoing but unfruitful, the President may step in to
|
||
overrule either party. Where the discussion involves the President, it
|
||
should be handled using a vote of no confidence.</p>
|
||
<p>Members of the CoA may choose to resign at any point. If at least two
|
||
members of the CoA remain, they may request a new election to refill
|
||
the group. If only one member remains, the election is triggered
|
||
automatically. (The scenario when the President resigns is described
|
||
in a later section.)</p>
|
||
<p>The intended balance of power is that the core developers will elect
|
||
members of the CoA who reflect the direction and have the trust of the
|
||
development team, and also have the ability to remove members who do
|
||
not honour commitments made prior to election.</p>
|
||
</section>
|
||
<section id="regular-decision-process">
|
||
<h3><a class="toc-backref" href="#regular-decision-process" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>Regular decisions continue to be made as at present.</p>
|
||
<p>For the sake of clarity, controversial decisions require a PEP, and
|
||
any decisions requiring a PEP are considered as controversial.</p>
|
||
<p>The CoA may be asked to advise on whether a decision would be better
|
||
made using the controversial decision process, or individual members
|
||
of the CoA may volunteer such a suggestion, but the core development
|
||
team is not bound by this advice.</p>
|
||
</section>
|
||
<section id="controversial-decision-process">
|
||
<h3><a class="toc-backref" href="#controversial-decision-process" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>Controversial decisions are always written up as PEPs, following the
|
||
existing process. The approver (formerly “BDFL-Delegate”) is always
|
||
the CoA, and can no longer be delegated. Note that this does not
|
||
prevent the CoA from deciding to nominate a core developer to assess
|
||
the proposal and provide the CoA with a recommendation, which is
|
||
essentially the same as the current delegation process.</p>
|
||
<p>The CoA will pronounce on PEPs submitted to python-committers with a
|
||
request for pronouncement. Any member of the CoA, or the current RM,
|
||
may request changes to a PEP for any reason, provided they include
|
||
some indication of what additional work is required to meet their
|
||
expectations. See later sections for examples of expected reasons.</p>
|
||
<p>When all members of the CoA and the RM indicate that they have no
|
||
concerns with a PEP, it is formally accepted. When one or more members
|
||
of the CoA fail to respond in a reasonable time, the President of the
|
||
CoA may choose to interpret that as implied approval. Failure of the
|
||
President to respond should be handled using a vote of no confidence.</p>
|
||
</section>
|
||
<section id="election-terms">
|
||
<h3><a class="toc-backref" href="#election-terms" role="doc-backlink">Election terms</a></h3>
|
||
<p>Members of the CoA are elected for the duration of a release. The
|
||
members are elected prior to feature freeze for the previous release,
|
||
and hold their position until feature freeze for their release.</p>
|
||
<p>Members may seek re-election as many times as they like. There are no
|
||
term limits. It is up to the core developers to prevent re-election of
|
||
the CoA members where there is consensus that the individual should
|
||
not serve again.</p>
|
||
</section>
|
||
<section id="election-voting-process">
|
||
<h3><a class="toc-backref" href="#election-voting-process" role="doc-backlink">Election voting process</a></h3>
|
||
<p>The election process for each member of the CoA proceeds as follows:</p>
|
||
<ul class="simple">
|
||
<li>a nomination email is sent to python-committers</li>
|
||
<li>a seconding email is sent</li>
|
||
<li>the nominee is temporarily added to python-committers for the
|
||
purpose of introducing themselves and presenting their position</li>
|
||
<li>voting opens two weeks prior to the scheduled feature freeze of the
|
||
previous release</li>
|
||
<li>votes are contributed by modifying a document in a private github
|
||
repository</li>
|
||
<li>each core developer may add +1 votes for as many candidates as they
|
||
like</li>
|
||
<li>after seven days, voting closes</li>
|
||
<li>the nominee with the most votes is elected as President of the CoA</li>
|
||
<li>the next three nominees with the most votes and also at least 50%
|
||
the number of votes received by the President are elected as the
|
||
other members of the CoA</li>
|
||
<li>where ties need to be resolved, the RM may apply one extra vote for
|
||
their preferred candidates</li>
|
||
<li>accepted nominees remain on python-committers; others are removed</li>
|
||
</ul>
|
||
</section>
|
||
<section id="no-confidence-voting-process">
|
||
<h3><a class="toc-backref" href="#no-confidence-voting-process" role="doc-backlink">No-confidence voting process</a></h3>
|
||
<p>A vote of no confidence proceeds as follows:</p>
|
||
<ul class="simple">
|
||
<li>a vote of no confidence email is sent to python-committers, naming
|
||
the affected member of the CoA, justifying the nomination, and
|
||
optionally listing accepted PEPs that the nominator believes should
|
||
be reverted</li>
|
||
<li>a seconding email is sent within seven days</li>
|
||
<li>the nominated member of the CoA is allowed seven days to respond,
|
||
after which the nominator or the seconder may withdraw</li>
|
||
<li>if no nominator or seconder is available, no further action is
|
||
taken</li>
|
||
<li>voting opens immediately</li>
|
||
<li>each core developer may add a +1 vote (remove the CoA member) or
|
||
a -1 vote (keep the CoA member) by modifying a document in a
|
||
private github repository</li>
|
||
<li>after seven days, voting closes</li>
|
||
<li>if +1 votes exceed -1 votes, the CoA member is removed from
|
||
python-committers and any nominated PEPs are reverted</li>
|
||
<li>if requested by the remaining members of the CoA, or if only one
|
||
member of the CoA remains, a new election to replace the removed
|
||
member may be held following the usual process.</li>
|
||
<li>in the case of removing the President of the CoA, the candidate
|
||
who originally received the second-most votes becomes President</li>
|
||
</ul>
|
||
</section>
|
||
</section>
|
||
<section id="examples-of-intended-behaviour">
|
||
<h2><a class="toc-backref" href="#examples-of-intended-behaviour" role="doc-backlink">Examples of intended behaviour</a></h2>
|
||
<p>This section describes some examples of the kind of interactions that
|
||
we hope to see between the CoA and the core developers. None of these
|
||
are binding descriptions, but are intended to achieve some consensus
|
||
on the types of processes we expect. The CoA candidates may campaign
|
||
on the basis of whatever process they prefer, and core developers
|
||
should allocate votes on this basis.</p>
|
||
<section id="scenario-1-the-case-of-the-vague-pep">
|
||
<h3><a class="toc-backref" href="#scenario-1-the-case-of-the-vague-pep" role="doc-backlink">Scenario 1 - The Case of the Vague PEP</a></h3>
|
||
<p>Often in the past, initial proposals have lacked sufficient detail to
|
||
be implementable by anyone other than the proposer. To avoid this,
|
||
the CoA should read proposals “fresh” when submitted, and without
|
||
inferring or using any implied context. Then, when an aspect of a PEP
|
||
is not clear, the CoA can reject the proposal and request
|
||
clarifications.</p>
|
||
<p>Since the proposal is rejected, it must be modified and resubmitted in
|
||
order to be reviewed again. The CoA will determine how much guidance
|
||
to provide when rejecting the PEP, as that will affect how many times
|
||
it will likely be resubmitted (and hence affect the CoA’s own
|
||
workload). This ensures that the final PEP text stands alone with all
|
||
required information.</p>
|
||
</section>
|
||
<section id="scenario-2-the-case-of-the-endless-discussion">
|
||
<h3><a class="toc-backref" href="#scenario-2-the-case-of-the-endless-discussion" role="doc-backlink">Scenario 2 - The Case of the Endless Discussion</a></h3>
|
||
<p>From time to time, a discussion between Python contributors may seem
|
||
to be no longer providing value. For example, when a large number of
|
||
emails are repeating points that have already been dealt with, or are
|
||
actively hostile towards others, there is no point continuing the
|
||
“discussion”.</p>
|
||
<p>When such a discussion is occurring on python-committers as part of a
|
||
request for pronouncement, a member of the CoA should simply declare
|
||
the thread over by rejecting the proposal. In most known cases,
|
||
discussion of this sort indicates that not all concerns have been
|
||
sufficiently addressed in the proposal and the author may need to
|
||
enhance some sections.</p>
|
||
<p>Alternatively, and in the absence of any rejection from the other
|
||
members of the CoA, the President may declare the thread over by
|
||
accepting the proposal. Ideally this would occur after directly
|
||
confirming with the rest of the CoA and the RM that there are no
|
||
concerns among them.</p>
|
||
<p>When such a discussion is occurring on another list, members of the
|
||
CoA should be viewed as respected voices similar to other core
|
||
developers (particularly those core developers who are the named
|
||
experts for the subject area). While none have specific authority to
|
||
end a thread, preemptively stating an intent to block a proposal is a
|
||
useful way to defuse potentially useless discussions. Members of the
|
||
CoA who voluntarily follow discussions other than on python-committers
|
||
are allowed to suggest the proposer withdraw, but can only actually
|
||
approve or reject a proposal that is formally submitted for
|
||
pronouncement.</p>
|
||
</section>
|
||
<section id="scenario-3-the-case-of-the-unconsidered-users">
|
||
<h3><a class="toc-backref" href="#scenario-3-the-case-of-the-unconsidered-users" role="doc-backlink">Scenario 3 - The Case of the Unconsidered Users</a></h3>
|
||
<p>Some proposals in the past may be written up and submitted for
|
||
pronouncement without considering the impact on particular groups of
|
||
users. For example, a proposal that affects the dependencies required
|
||
to use Python on various machines may have an adverse impact on some
|
||
users, even if many are unaffected due to the dependencies being
|
||
typically available by default.</p>
|
||
<p>Where a proposal does not appear to consider all users, the CoA might
|
||
choose to use their judgement and past experience to determine that
|
||
more users are affected by the change than described in the PEP, and
|
||
request that the PEP also address these users. They should identify
|
||
the group of users clearly enough that the proposer is able to also
|
||
identify these users, and either clarify how they were addressed, or
|
||
made amendments to the PEP to explicitly address them. (Note that this
|
||
does not involve evaluating the usefulness of the feature to various
|
||
user groups, but simply whether the PEP indicates that the usefulness
|
||
of the feature has been evaluated.)</p>
|
||
<p>Where a proposal appears to have used flawed logic or incorrect data
|
||
to come to a certain conclusion, the CoA might choose to use other
|
||
sources of information (such as the prior discussion or a submission
|
||
from other core developers) to request reconsideration of certain
|
||
points. The proposer does not necessarily need to use the exact
|
||
information obtained by the CoA to update their proposal, provided
|
||
that whatever amendments they make are satisfactory to the CoA. For
|
||
example, a PEP may indicate that 30% of users would be affected, while
|
||
the CoA may argue that 70% of users are affected. A successful
|
||
amendment may include a different but more reliable percentage, or may
|
||
be rewritten to no longer depend on the number of affected users.</p>
|
||
</section>
|
||
<section id="scenario-4-the-case-of-the-delegated-decision">
|
||
<h3><a class="toc-backref" href="#scenario-4-the-case-of-the-delegated-decision" role="doc-backlink">Scenario 4 - The Case of the Delegated Decision</a></h3>
|
||
<p>Some proposals may require review and approval from a specialist in
|
||
the area. Historically, these would have been handled by appointing a
|
||
BDFL-Delegate to make the final decision on the proposal. However, in
|
||
this model, the CoA may not delegate the final decision making
|
||
process. When the CoA believes that a subject matter expert should
|
||
decide on a particular proposal, the CoA may nominate one or more
|
||
individuals (or accept their self-nomination) to a similar position to
|
||
a BDFL Delegate. The terms of these expert’s role may be set as the
|
||
CoA sees fit, though the CoA always retains the final approval.</p>
|
||
<p>As a concrete example, assume a proposal is being discussed about a
|
||
new language feature. Proponents claim that it will make the language
|
||
easier for new developers to learn. Even before an official proposal
|
||
is made, the CoA may indicate that they will not accept the proposal
|
||
unless person X approves, since person X has a long history teaching
|
||
Python and their judgement is trusted. (Note that person X need not be
|
||
a core developer.)</p>
|
||
<p>Having been given this role, person X is able to drive the discussion
|
||
and quickly focus it on viable alternatives. Eventually, person X
|
||
chooses the alternative they are most satisfied with and indicates to
|
||
the CoA that they approve. The proposal is submitted as usual, and the
|
||
CoA reviews and accepts it, factoring in person X’s opinion.</p>
|
||
</section>
|
||
</section>
|
||
<section id="copyright">
|
||
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
|
||
<p>This document has been placed in the public domain.</p>
|
||
</section>
|
||
</section>
|
||
<hr class="docutils" />
|
||
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-8013.rst">https://github.com/python/peps/blob/main/peps/pep-8013.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-8013.rst">2023-09-09 17:39:29 GMT</a></p>
|
||
|
||
</article>
|
||
<nav id="pep-sidebar">
|
||
<h2>Contents</h2>
|
||
<ul>
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#pep-rejection">PEP Rejection</a></li>
|
||
<li><a class="reference internal" href="#the-importance-of-the-grey-area">The Importance of the Grey Area</a></li>
|
||
<li><a class="reference internal" href="#model-overview">Model Overview</a><ul>
|
||
<li><a class="reference internal" href="#key-people-and-their-functions">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#regular-decision-process">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#controversial-decision-process">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#election-terms">Election terms</a></li>
|
||
<li><a class="reference internal" href="#election-voting-process">Election voting process</a></li>
|
||
<li><a class="reference internal" href="#no-confidence-voting-process">No-confidence voting process</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#examples-of-intended-behaviour">Examples of intended behaviour</a><ul>
|
||
<li><a class="reference internal" href="#scenario-1-the-case-of-the-vague-pep">Scenario 1 - The Case of the Vague PEP</a></li>
|
||
<li><a class="reference internal" href="#scenario-2-the-case-of-the-endless-discussion">Scenario 2 - The Case of the Endless Discussion</a></li>
|
||
<li><a class="reference internal" href="#scenario-3-the-case-of-the-unconsidered-users">Scenario 3 - The Case of the Unconsidered Users</a></li>
|
||
<li><a class="reference internal" href="#scenario-4-the-case-of-the-delegated-decision">Scenario 4 - The Case of the Delegated Decision</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
|
||
<br>
|
||
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-8013.rst">Page Source (GitHub)</a>
|
||
</nav>
|
||
</section>
|
||
<script src="../_static/colour_scheme.js"></script>
|
||
<script src="../_static/wrap_tables.js"></script>
|
||
<script src="../_static/sticky_banner.js"></script>
|
||
</body>
|
||
</html> |