mirror of https://github.com/python/peps
404 lines
25 KiB
HTML
404 lines
25 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 8010 – The Technical Leader Governance Model | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-8010/">
|
||
<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 8010 – The Technical Leader Governance Model | peps.python.org'>
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-8010/">
|
||
<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="Python Enhancement Proposals (PEPs)">
|
||
<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 8010</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 8010 – The Technical Leader Governance Model</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Barry Warsaw <barry 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">24-Aug-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="#open-discussion-points">Open discussion points</a></li>
|
||
<li><a class="reference internal" href="#why-a-singular-technical-leader">Why a singular technical leader?</a></li>
|
||
<li><a class="reference internal" href="#flexibility">Flexibility</a></li>
|
||
<li><a class="reference internal" href="#the-role-of-the-guido">The role of the GUIDO</a></li>
|
||
<li><a class="reference internal" href="#authority-comes-from-the-community">Authority comes from the community</a></li>
|
||
<li><a class="reference internal" href="#length-of-service-and-term-limits">Length of service and term limits</a></li>
|
||
<li><a class="reference internal" href="#choosing-a-guido">Choosing a GUIDO</a></li>
|
||
<li><a class="reference internal" href="#the-council-of-pythonistas-cop">The Council of Pythonistas (CoP)</a></li>
|
||
<li><a class="reference internal" href="#no-confidence-votes">No confidence votes</a></li>
|
||
<li><a class="reference internal" href="#day-to-day-operations">Day-to-day operations</a></li>
|
||
<li><a class="reference internal" href="#pep-considerations">PEP considerations</a></li>
|
||
<li><a class="reference internal" href="#version-history">Version History</a></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 continuation of the singular technical project
|
||
leader model, euphemistically called the <a class="reference external" href="https://en.wikipedia.org/wiki/Benevolent_dictator_for_life">Benevolent Dictator For Life</a> (BDFL)
|
||
model of Python governance, to be henceforth called in this PEP the
|
||
Gracious Umpire Influencing Decisions Officer (GUIDO). This change in
|
||
name reflects both the expanded view of the GUIDO as final arbiter for
|
||
the Python language decision making process in consultation with the
|
||
wider development community, and the recognition that “for life” while
|
||
perhaps aspirational, is not necessarily in the best interest of the
|
||
well-being of either the language or the GUIDO themselves.</p>
|
||
<p>This PEP describes:</p>
|
||
<ul class="simple">
|
||
<li>The rationale for maintaining the singular technical leader model</li>
|
||
<li>The process for how the GUIDO will be selected, elected, retained,
|
||
recalled, and succeeded;</li>
|
||
<li>The roles of the GUIDO in the Python language evolution process;</li>
|
||
<li>The term length of service;</li>
|
||
<li>The relationship of the GUIDO with a Council of Pythonistas (CoP)
|
||
that advise the GUIDO on technical matters;</li>
|
||
<li>The size, election, and roles of the CoP;</li>
|
||
<li>The decision delegation process;</li>
|
||
<li>Any changes to the PEP process to fit the new governance model;</li>
|
||
</ul>
|
||
<p>This PEP does <em>not</em> name a new BDFL. 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-8010/" title="PEP 8010 – The Technical Leader Governance Model">PEP 8010</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="open-discussion-points">
|
||
<h2><a class="toc-backref" href="#open-discussion-points" role="doc-backlink">Open discussion points</a></h2>
|
||
<p>Various tweaks to the parameters of this PEP are allowed during the
|
||
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.</p>
|
||
<p>The voting procedures and events described in this PEP will default to
|
||
the voting method specified in <a class="pep reference internal" href="../pep-8001/" title="PEP 8001 – Python Governance Voting Process">PEP 8001</a>, although as that PEP is still
|
||
in discussion at the time of this writing, this is subject to change.</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="why-a-singular-technical-leader">
|
||
<h2><a class="toc-backref" href="#why-a-singular-technical-leader" role="doc-backlink">Why a singular technical leader?</a></h2>
|
||
<p>Why this model rather than any other? It comes down to “vision”.
|
||
<a class="reference external" href="https://en.wikipedia.org/wiki/Design_by_committee">Design by committee</a> has many known downsides, leading to a language
|
||
that accretes new features based on the varied interests of the
|
||
contributors at the time. A famous aphorism is “a camel is a horse
|
||
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?</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="flexibility">
|
||
<h2><a class="toc-backref" href="#flexibility" role="doc-backlink">Flexibility</a></h2>
|
||
<p>Degrees of flexibility are given to both the GUIDO and CoP by way of
|
||
underspecification. This PEP describes how conflicts will be
|
||
resolved, but expects all participants, including core developers,
|
||
community members, and office holders, to always have the best
|
||
interest of Python and its users at heart. The PEP assumes that
|
||
mutual respect and the best intentions will always lead to consensus,
|
||
and that the Code of Conduct governs all interactions and discussions.</p>
|
||
</section>
|
||
<section id="the-role-of-the-guido">
|
||
<h2><a class="toc-backref" href="#the-role-of-the-guido" role="doc-backlink">The role of the GUIDO</a></h2>
|
||
<p>One of the most important roles of the GUIDO is to provide an
|
||
overarching, broad, coherent vision for the evolution of the Python
|
||
language, spanning multiple releases. This is especially important
|
||
when decision have lasting impact and competing benefits. For
|
||
example, if backward incompatible changes to the C API leads to a 2x
|
||
improvement in Python performance, different community members will
|
||
likely advocate convincingly on both sides of the debate, and a clear
|
||
consensus may not emerge. Either choice is equally valid. In
|
||
consultation with the CoP, it will be the GUIDO’s vision that guides
|
||
the ultimate decision.</p>
|
||
<p>The GUIDO is the ultimate authority for decisions on PEPs and other
|
||
issues, including whether any particular change is PEP-worthy. As is
|
||
the case today, many –in fact perhaps most– decisions are handled by
|
||
discussion and resolution on the issue tracker, merge requests, and
|
||
discussion forums, usually with input or lead by experts in the
|
||
particular field. Where this operating procedure works perfectly
|
||
well, it can continue unchanged. This also helps reduce the workload
|
||
on the CoP and GUIDO, leaving only the most important decisions and
|
||
broadest view of the landscape to the central authority.</p>
|
||
<p>Similarly, should a particular change be deemed to require a PEP, but
|
||
the GUIDO, in consultation with the CoP, identifies experts that have
|
||
the full confidence to make the final decision, the GUIDO can name a
|
||
Delegate for the PEP. While the GUIDO remains the ultimate authority,
|
||
it is expected that the GUIDO will not undermine, and in fact will
|
||
support the authority of the Delegate as the final arbiter of the PEP.</p>
|
||
<p>The GUIDO has full authority to shut down unproductive discussions,
|
||
ideas, and proposals, when it is clear that the proposal runs counter
|
||
to the long-term vision for Python. This is done with compassion for
|
||
the advocates of the change, but with the health and well-being of all
|
||
community members in mind. A toxic discussion on a dead-end proposal
|
||
does no one any good, and they can be terminated by fiat.</p>
|
||
<p>To sum up: the GUIDO has the authority to make a final pronouncement
|
||
on any topic, technical or non-technical, except for changing to the
|
||
governance PEP itself.</p>
|
||
</section>
|
||
<section id="authority-comes-from-the-community">
|
||
<h2><a class="toc-backref" href="#authority-comes-from-the-community" role="doc-backlink">Authority comes from the community</a></h2>
|
||
<p>The GUIDO’s authority ultimately resides with the community. A rogue
|
||
GUIDO that loses the confidence of the majority of the community can
|
||
be recalled and a new vote conducted. This is an exceedingly rare and
|
||
unlikely event. This is a sufficient stopgap for the worst-case
|
||
scenario, so it should not be undertaken lightly. The GUIDO should
|
||
not fear being deposed because of one decision, even if that decision
|
||
isn’t favored by the majority of Python developers. Recall should be
|
||
reserved for actions severely detrimental to the Python language or
|
||
community.</p>
|
||
<p>The Council of Pythonistas (see below) has the responsibility to
|
||
initiate a vote of no-confidence.</p>
|
||
</section>
|
||
<section id="length-of-service-and-term-limits">
|
||
<h2><a class="toc-backref" href="#length-of-service-and-term-limits" role="doc-backlink">Length of service and term limits</a></h2>
|
||
<p>The GUIDO shall serve for three Python releases, approximately 4.5
|
||
years given the current release cadence. If Python’s release cadence
|
||
changes, the length of GUIDO’s term should change to 4.5 years rounded
|
||
to whole releases. How the rounding is done is left to the potential
|
||
release cadence PEP. After this time, a new election is held
|
||
according to the procedures outlined below. There are no term limits,
|
||
so the GUIDO may run for re-election for as long as they like.</p>
|
||
<p>We expect GUIDOs to serve out their entire term of office, but of
|
||
course, Life Happens. Should the GUIDO need to step down before their
|
||
term ends, the vacancy will be filled by the process outlined below as
|
||
per choosing a new GUIDO. However, the new GUIDO will only serve for
|
||
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.</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="choosing-a-guido">
|
||
<h2><a class="toc-backref" href="#choosing-a-guido" role="doc-backlink">Choosing a GUIDO</a></h2>
|
||
<p>The selection process is triggered whenever a vacancy exists for a new
|
||
GUIDO, or when the GUIDO is up for re-election in the normal course of
|
||
events. When the selection process is triggered, either by the GUIDO
|
||
stepping down, or two months before the end of the GUIDO’s regular
|
||
term, a new election process begins.</p>
|
||
<p>For three weeks prior to the vote, nominations are open. Candidates
|
||
must be chosen from the current list of core Python developers.
|
||
Non-core developers are ineligible to serve as the GUIDO. Candidates
|
||
may self-nominate, but all nominations must be seconded. Nominations
|
||
and seconds are conducted as merge requests on a private repository.</p>
|
||
<p>Once they accept their nomination, nominees may post short position
|
||
statements using the same private repository, and may also post them
|
||
to the committers discussion forum. Maybe we’ll even have debates!
|
||
This phase of the election runs for two weeks.</p>
|
||
<p>Core developers then have three weeks to vote, using the process
|
||
described in <a class="pep reference internal" href="../pep-8001/" title="PEP 8001 – Python Governance Voting Process">PEP 8001</a>.</p>
|
||
</section>
|
||
<section id="the-council-of-pythonistas-cop">
|
||
<h2><a class="toc-backref" href="#the-council-of-pythonistas-cop" role="doc-backlink">The Council of Pythonistas (CoP)</a></h2>
|
||
<p>Assisting the GUIDO is a small team of elected Python experts. They
|
||
serve on a team of technical committee members. They provide insight
|
||
and offer discussion of the choices before the GUIDO. Consultation
|
||
can be triggered from either side. For example, if the GUIDO is still
|
||
undecided about any particular choice, discussions with the CoP can
|
||
help clarify the remaining issues, identify the right questions to
|
||
ask, and provide insight into the impact on other users of Python that
|
||
the GUIDO may not be as familiar with. The CoP are the GUIDO’s
|
||
trusted advisers, and a close working relationship is expected.</p>
|
||
<p>The CoP shall consist of 3 members, elected from among the core
|
||
developers. Their term runs for 3 years and members may run for
|
||
re-election as many times as they want. To ensure continuity, CoP
|
||
members are elected on a rotating basis; every year, one CoP member is
|
||
up for re-election.</p>
|
||
<p>In order to bootstrap the stagger for the initial election, the CoP
|
||
member with the most votes shall serve for 3 years, the second most
|
||
popular vote getter shall serve for 2 years, and CoP member with the
|
||
least number of votes shall serve initially for 1 year.</p>
|
||
<p>All ties in voting will be broken with a procedure to be determined in
|
||
<a class="pep reference internal" href="../pep-8001/" title="PEP 8001 – Python Governance Voting Process">PEP 8001</a>.</p>
|
||
<p>The nomination and voting process is similar as with the GUIDO. There
|
||
is a three-week nomination period, where self-nominations are allowed
|
||
and must be seconded, followed by a period of time for posting
|
||
position statements, followed by a vote.</p>
|
||
<p>By unanimous decision, the CoP may begin a no-confidence vote on the
|
||
GUIDO, triggering the procedure in that section.</p>
|
||
</section>
|
||
<section id="no-confidence-votes">
|
||
<h2><a class="toc-backref" href="#no-confidence-votes" role="doc-backlink">No confidence votes</a></h2>
|
||
<p>As mentioned above, the CoP may, by unanimous decision, initiate a
|
||
vote of no-confidence in the GUIDO. This process should not be
|
||
undertaken lightly, but once begun, it triggers up to two votes. In
|
||
both cases, voting is done by the same procedure as in <a class="pep reference internal" href="../pep-8001/" title="PEP 8001 – Python Governance Voting Process">PEP 8001</a>, and
|
||
all core developers may participate in no confidence votes.</p>
|
||
<p>The first vote is whether to recall the current GUIDO or not. Should
|
||
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
|
||
are put on hold, but normal Python operations may of course continue.</p>
|
||
</section>
|
||
<section id="day-to-day-operations">
|
||
<h2><a class="toc-backref" href="#day-to-day-operations" role="doc-backlink">Day-to-day operations</a></h2>
|
||
<p>The GUIDO is not needed for all – or even most – decisions. Python
|
||
developers already have plenty of opportunity for delegation,
|
||
responsibility, and self-direction. The issue tracker and pull
|
||
requests serve exactly the same function as they did before this
|
||
governance model was chosen. Most discussions of bug fixes and minor
|
||
improvements can just happen on these forums, as they always have.</p>
|
||
</section>
|
||
<section id="pep-considerations">
|
||
<h2><a class="toc-backref" href="#pep-considerations" role="doc-backlink">PEP considerations</a></h2>
|
||
<p>The GUIDO, members of the CoP, and anyone else in the Python community
|
||
may propose a PEP. Treatment of the prospective PEP is handled the
|
||
same regardless of the author of the PEP.</p>
|
||
<p>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 on PEPs authored by the
|
||
GUIDO rests with the CoP.</p>
|
||
<p>The PEP propose is further enhanced such that a core developer must
|
||
always be chose as the PEP Shepherd. This person ensure that proper
|
||
procedure is maintained. The Shepherd must be chosen from among the
|
||
core developers. This means that while anyone can author a PEP, all
|
||
PEPs must have some level of sponsorship from at least one core
|
||
developer.</p>
|
||
</section>
|
||
<section id="version-history">
|
||
<h2><a class="toc-backref" href="#version-history" role="doc-backlink">Version History</a></h2>
|
||
<p>Version 2</p>
|
||
<blockquote>
|
||
<div><ul class="simple">
|
||
<li>Renamed to “The Technical Leader Governance Model”</li>
|
||
<li>“singular leader” -> “singular technical leader”</li>
|
||
<li>The adoption of <a class="pep reference internal" href="../pep-8001/" title="PEP 8001 – Python Governance Voting Process">PEP 8001</a> voting procedures is tentative until that
|
||
PEP is approved</li>
|
||
<li>Describe what happens if the GUIDO steps down</li>
|
||
<li>Recall votes require a super majority of core devs to succeed</li>
|
||
</ul>
|
||
</div></blockquote>
|
||
</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-8010.rst">https://github.com/python/peps/blob/main/peps/pep-8010.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-8010.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="#open-discussion-points">Open discussion points</a></li>
|
||
<li><a class="reference internal" href="#why-a-singular-technical-leader">Why a singular technical leader?</a></li>
|
||
<li><a class="reference internal" href="#flexibility">Flexibility</a></li>
|
||
<li><a class="reference internal" href="#the-role-of-the-guido">The role of the GUIDO</a></li>
|
||
<li><a class="reference internal" href="#authority-comes-from-the-community">Authority comes from the community</a></li>
|
||
<li><a class="reference internal" href="#length-of-service-and-term-limits">Length of service and term limits</a></li>
|
||
<li><a class="reference internal" href="#choosing-a-guido">Choosing a GUIDO</a></li>
|
||
<li><a class="reference internal" href="#the-council-of-pythonistas-cop">The Council of Pythonistas (CoP)</a></li>
|
||
<li><a class="reference internal" href="#no-confidence-votes">No confidence votes</a></li>
|
||
<li><a class="reference internal" href="#day-to-day-operations">Day-to-day operations</a></li>
|
||
<li><a class="reference internal" href="#pep-considerations">PEP considerations</a></li>
|
||
<li><a class="reference internal" href="#version-history">Version History</a></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-8010.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> |