CINXE.COM

<!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 8016 – The Steering Council Model | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-8016/"> <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 8016 – The Steering Council Model | peps.python.org'> <meta property="og:description" content="This PEP proposes a model of Python governance based around a steering council. The council has broad authority, which they seek to exercise as rarely as possible; instead, they use this power to establish standard processes, like those proposed in the ..."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-8016/"> <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 model of Python governance based around a steering council. The council has broad authority, which they seek to exercise as rarely as possible; instead, they use this power to establish standard processes, like those proposed in the ..."> <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 8016</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 8016 – The Steering Council Model</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author<span class="colon">:</span></dt> <dd class="field-odd">Nathaniel J. Smith, Donald Stufft</dd> <dt class="field-even">Status<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Normative proposal accepted for implementation">Accepted</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">01-Nov-2018</dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#note">Note</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#pep-acceptance">PEP Acceptance</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#the-steering-council">The steering council</a><ul> <li><a class="reference internal" href="#composition">Composition</a></li> <li><a class="reference internal" href="#mandate">Mandate</a></li> <li><a class="reference internal" href="#powers">Powers</a></li> <li><a class="reference internal" href="#electing-the-council">Electing the council</a></li> <li><a class="reference internal" href="#term">Term</a></li> <li><a class="reference internal" href="#vacancies">Vacancies</a></li> <li><a class="reference internal" href="#conflicts-of-interest">Conflicts of interest</a></li> <li><a class="reference internal" href="#ejecting-core-team-members">Ejecting core team members</a></li> <li><a class="reference internal" href="#vote-of-no-confidence">Vote of no confidence</a></li> </ul> </li> <li><a class="reference internal" href="#the-core-team">The core team</a><ul> <li><a class="reference internal" href="#role">Role</a></li> <li><a class="reference internal" href="#prerogatives">Prerogatives</a></li> <li><a class="reference internal" href="#membership">Membership</a></li> </ul> </li> <li><a class="reference internal" href="#changing-this-document">Changing this document</a></li> </ul> </li> <li><a class="reference internal" href="#todo">TODO</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <section id="note"> <h2><a class="toc-backref" href="#note" role="doc-backlink">Note</a></h2> <p>This PEP is retained for historical purposes, but the official governance document is now <a class="pep reference internal" href="../pep-0013/" title="PEP 13 – Python Language Governance">PEP 13</a>.</p> </section> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> <p>This PEP proposes a model of Python governance based around a steering council. The council has broad authority, which they seek to exercise as rarely as possible; instead, they use this power to establish standard processes, like those proposed in the other 801x-series PEPs. This follows the general philosophy that it’s better to split up large changes into a series of small changes that can be reviewed independently: instead of trying to do everything in one PEP, we focus on providing a minimal-but-solid foundation for further governance decisions.</p> </section> <section id="pep-acceptance"> <h2><a class="toc-backref" href="#pep-acceptance" role="doc-backlink">PEP Acceptance</a></h2> <p><a class="pep reference internal" href="../pep-8016/" title="PEP 8016 – The Steering Council Model">PEP 8016</a> was accepted <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> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> <p>The main goals of this proposal are:</p> <ul class="simple"> <li>Be <strong>boring</strong>: We’re not experts in governance, and we don’t think Python is a good place to experiment with new and untried governance models. So this proposal sticks to mature, well-known, previously tested processes as much as possible. The high-level approach of a mostly-hands-off council is arguably the most common across large successful F/OSS projects, and low-level details are derived directly from Django’s governance.</li> <li>Be <strong>simple</strong>: We’ve attempted to pare things down to the minimum needed to make this workable: the council, the core team (who elect the council), and the process for changing the document. The goal is Minimum Viable Governance.</li> <li>Be <strong>comprehensive</strong>: But for the things we need to define, we’ve tried to make sure to cover all the bases, because we don’t want to go through this kind of crisis again. Having a clear and unambiguous set of rules also helps minimize confusion and resentment.</li> <li>Be <strong>flexible and light-weight</strong>: We know that it will take time and experimentation to find the best processes for working together. By keeping this document as minimal as possible, we keep maximal flexibility for adjusting things later, while minimizing the need for heavy-weight and anxiety-provoking processes like whole-project votes.</li> </ul> <p>A number of details were discussed in <a class="reference external" href="https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/">this Discourse thread</a>, and then <a class="reference external" href="https://discuss.python.org/t/pep-8016-the-steering-council-model/394">this thread has further discussion</a>. These may be useful to anyone trying to understand the rationale for various minor decisions.</p> </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <section id="the-steering-council"> <h3><a class="toc-backref" href="#the-steering-council" role="doc-backlink">The steering council</a></h3> <section id="composition"> <h4><a class="toc-backref" href="#composition" role="doc-backlink">Composition</a></h4> <p>The steering council is a 5-person committee.</p> </section> <section id="mandate"> <h4><a class="toc-backref" href="#mandate" role="doc-backlink">Mandate</a></h4> <p>The steering council shall work to:</p> <ul class="simple"> <li>Maintain the quality and stability of the Python language and CPython interpreter,</li> <li>Make contributing as accessible, inclusive, and sustainable as possible,</li> <li>Formalize and maintain the relationship between the core team and the PSF,</li> <li>Establish appropriate decision-making processes for PEPs,</li> <li>Seek consensus among contributors and the core team before acting in a formal capacity,</li> <li>Act as a “court of final appeal” for decisions where all other methods have failed.</li> </ul> </section> <section id="powers"> <h4><a class="toc-backref" href="#powers" role="doc-backlink">Powers</a></h4> <p>The council has broad authority to make decisions about the project. For example, they can:</p> <ul class="simple"> <li>Accept or reject PEPs</li> <li>Enforce or update the project’s code of conduct</li> <li>Work with the PSF to manage any project assets</li> <li>Delegate parts of their authority to other subcommittees or processes</li> </ul> <p>However, they cannot modify this PEP, or affect the membership of the core team, except via the mechanisms specified in this PEP.</p> <p>The council should look for ways to use these powers as little as possible. Instead of voting, it’s better to seek consensus. Instead of ruling on individual PEPs, it’s better to define a standard process for PEP decision making (for example, by accepting one of the other 801x series of PEPs). It’s better to establish a Code of Conduct committee than to rule on individual cases. And so on.</p> <p>To use its powers, the council votes. Every council member must either vote or explicitly abstain. Members with conflicts of interest on a particular vote must abstain. Passing requires support from a majority of non-abstaining council members.</p> <p>Whenever possible, the council’s deliberations and votes shall be held in public.</p> </section> <section id="electing-the-council"> <h4><a class="toc-backref" href="#electing-the-council" role="doc-backlink">Electing the council</a></h4> <p>A council election consists of two phases:</p> <ul class="simple"> <li>Phase 1: Candidates advertise their interest in serving. Candidates must be nominated by a core team member. Self-nominations are allowed.</li> <li>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. If a tie occurs, it may be resolved by mutual agreement among the candidates, or else the winner will be chosen at random.</li> </ul> <p>Each phase lasts one to two weeks, at the outgoing council’s discretion. For the initial election, both phases will last two weeks.</p> <p>The election process is managed by a returns officer nominated by the outgoing steering council. For the initial election, the returns officer will be nominated by the PSF Executive Director.</p> <p>The council should ideally reflect the diversity of Python contributors and users, and core team members are encouraged to vote accordingly.</p> </section> <section id="term"> <h4><a class="toc-backref" href="#term" role="doc-backlink">Term</a></h4> <p>A new council is elected after each feature release. Each council’s term runs from when their election results are finalized until the next council’s term starts. There are no term limits.</p> </section> <section id="vacancies"> <h4><a class="toc-backref" href="#vacancies" role="doc-backlink">Vacancies</a></h4> <p>Council members may resign their position at any time.</p> <p>Whenever there is a vacancy during the regular council term, the council may vote to appoint a replacement to serve out the rest of the term.</p> <p>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 them.</p> </section> <section id="conflicts-of-interest"> <h4><a class="toc-backref" href="#conflicts-of-interest" role="doc-backlink">Conflicts of interest</a></h4> <p>While we trust council members to act in the best interests of Python rather than themselves or their employers, the mere appearance of any one company dominating Python development could itself be harmful and erode trust. In order to avoid any appearance of conflict of interest, at most 2 members of the council can work for any single employer.</p> <p>In a council election, if 3 of the top 5 vote-getters work for the same employer, then whichever of them ranked lowest is disqualified and the 6th-ranking candidate moves up into 5th place; this is repeated until a valid council is formed.</p> <p>During a council term, if changing circumstances cause this rule to be broken (for instance, due to a council member changing employment), then one or more council members must resign to remedy the issue, and the resulting vacancies can then be filled as normal.</p> </section> <section id="ejecting-core-team-members"> <h4><a class="toc-backref" href="#ejecting-core-team-members" role="doc-backlink">Ejecting core team members</a></h4> <p>In exceptional circumstances, it may be necessary to remove someone from the core team against their will. (For example: egregious and ongoing code of conduct violations.) This can be accomplished by a steering council vote, but unlike other steering council votes, this requires at least a two-thirds majority. With 5 members voting, this means that a 3:2 vote is insufficient; 4:1 in favor is the minimum 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.</p> <p>If the ejected core team member is also on the steering council, then they are removed from the steering council as well.</p> </section> <section id="vote-of-no-confidence"> <h4><a class="toc-backref" href="#vote-of-no-confidence" role="doc-backlink">Vote of no confidence</a></h4> <p>In exceptional circumstances, the core team may remove a sitting council member, or the entire council, via a vote of no confidence.</p> <p>A no-confidence vote is triggered when a core team member calls for one publicly on an appropriate project communication channel, and another core team member seconds the proposal.</p> <p>The vote lasts for two weeks. Core team members vote for or against. If at least two thirds of voters express a lack of confidence, then the vote succeeds.</p> <p>There are two forms of no-confidence votes: those targeting a single member, and those targeting the council as a whole. The initial call for a no-confidence vote must specify which type is intended. If a single-member vote succeeds, then that member is removed from the council and the resulting vacancy can be handled in the usual way. If a whole-council vote succeeds, the council is dissolved and a new council election is triggered immediately.</p> </section> </section> <section id="the-core-team"> <h3><a class="toc-backref" href="#the-core-team" role="doc-backlink">The core team</a></h3> <section id="role"> <h4><a class="toc-backref" href="#role" role="doc-backlink">Role</a></h4> <p>The core team is the group of trusted volunteers who manage Python. They assume many roles required to achieve the project’s goals, especially those that require a high level of trust. They make the decisions that shape the future of the project.</p> <p>Core team members are expected to act as role models for the community and custodians of the project, on behalf of the community and all those who rely on Python.</p> <p>They will intervene, where necessary, in online discussions or at official Python events on the rare occasions that a situation arises that requires intervention.</p> <p>They have authority over the Python Project infrastructure, including the Python Project website itself, the Python GitHub organization and repositories, the bug tracker, the mailing lists, IRC channels, etc.</p> </section> <section id="prerogatives"> <h4><a class="toc-backref" href="#prerogatives" role="doc-backlink">Prerogatives</a></h4> <p>Core team members may participate in formal votes, typically to nominate new team members and to elect the steering council.</p> </section> <section id="membership"> <h4><a class="toc-backref" href="#membership" role="doc-backlink">Membership</a></h4> <p>Python core team members demonstrate:</p> <ul class="simple"> <li>a good grasp of the philosophy of the Python Project</li> <li>a solid track record of being constructive and helpful</li> <li>significant contributions to the project’s goals, in any form</li> <li>willingness to dedicate some time to improving Python</li> </ul> <p>As the project matures, contributions go beyond code. Here’s an incomplete list of areas where contributions may be considered for joining the core team, in no particular order:</p> <ul class="simple"> <li>Working on community management and outreach</li> <li>Providing support on the mailing lists and on IRC</li> <li>Triaging tickets</li> <li>Writing patches (code, docs, or tests)</li> <li>Reviewing patches (code, docs, or tests)</li> <li>Participating in design decisions</li> <li>Providing expertise in a particular domain (security, i18n, etc.)</li> <li>Managing the continuous integration infrastructure</li> <li>Managing the servers (website, tracker, documentation, etc.)</li> <li>Maintaining related projects (alternative interpreters, core infrastructure like packaging, etc.)</li> <li>Creating visual designs</li> </ul> <p>Core team membership acknowledges sustained and valuable efforts that align well with the philosophy and the goals of the Python project.</p> <p>It is granted by receiving at least two-thirds positive votes in a core team vote and no veto by the steering council.</p> <p>Core team members are always looking for promising contributors, teaching them how the project is managed, and submitting their names to the core team’s vote when they’re ready.</p> <p>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 “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.</p> <p>The initial active core team members will consist of everyone currently listed in the <a class="reference external" href="https://github.com/orgs/python/teams/python-core/members">“Python core” team on GitHub</a>, and the initial inactive members will consist of everyone else who has been a committer in the past.</p> </section> </section> <section id="changing-this-document"> <h3><a class="toc-backref" href="#changing-this-document" role="doc-backlink">Changing this document</a></h3> <p>Changes to this document require at least a two-thirds majority of votes cast in a core team vote.</p> </section> </section> <section id="todo"> <h2><a class="toc-backref" href="#todo" role="doc-backlink">TODO</a></h2> <ul class="simple"> <li>Lots of people contributed helpful suggestions and feedback; we should check if they’re comfortable being added as co-authors</li> <li>It looks like Aymeric Augustin wrote the whole Django doc, so presumably holds copyright; maybe we should ask him if he’s willing to release it into the public domain so our copyright statement below can be simpler.</li> </ul> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> <p>Substantial text was copied shamelessly from <a class="reference external" href="https://docs.djangoproject.com/en/dev/internals/organization/">The Django project’s governance document</a>.</p> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> <p>Text copied from Django used under <a class="reference external" href="https://github.com/django/django/blob/main/LICENSE">their license</a>. The rest of 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-8016.rst">https://github.com/python/peps/blob/main/peps/pep-8016.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-8016.rst">2025-02-01 08:55:40 GMT</a></p> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#note">Note</a></li> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#pep-acceptance">PEP Acceptance</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#the-steering-council">The steering council</a><ul> <li><a class="reference internal" href="#composition">Composition</a></li> <li><a class="reference internal" href="#mandate">Mandate</a></li> <li><a class="reference internal" href="#powers">Powers</a></li> <li><a class="reference internal" href="#electing-the-council">Electing the council</a></li> <li><a class="reference internal" href="#term">Term</a></li> <li><a class="reference internal" href="#vacancies">Vacancies</a></li> <li><a class="reference internal" href="#conflicts-of-interest">Conflicts of interest</a></li> <li><a class="reference internal" href="#ejecting-core-team-members">Ejecting core team members</a></li> <li><a class="reference internal" href="#vote-of-no-confidence">Vote of no confidence</a></li> </ul> </li> <li><a class="reference internal" href="#the-core-team">The core team</a><ul> <li><a class="reference internal" href="#role">Role</a></li> <li><a class="reference internal" href="#prerogatives">Prerogatives</a></li> <li><a class="reference internal" href="#membership">Membership</a></li> </ul> </li> <li><a class="reference internal" href="#changing-this-document">Changing this document</a></li> </ul> </li> <li><a class="reference internal" href="#todo">TODO</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</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-8016.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>