iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 8016 - initial draft (#827)

This commit is contained in:
Nathaniel J. Smith 2018-11-05 10:00:50 -08:00 committed by Donald Stufft
parent 80833bd420
commit 5175b24a04
2 changed files with 357 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
pep-8000.rst
View File

@ -91,6 +91,18 @@ PEPs.
(Guido van Rossum) with a new "Python board" of 3 members which has
limited roles, mostly decide how a PEP is approved (or rejected).
* PEP 8016 - The Steering Council Model
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.
Additional governance models may be added before the final selection.

345
pep-8016.rst Normal file
View File

@ -0,0 +1,345 @@
PEP: 8016
Title: The Steering Council Model
Author: Nathaniel J. Smith, Donald Stufft
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 2018-11-01
Abstract
========
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.
Rationale
=========
The main goals of this proposal are:
* Be **boring**: 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.
* Be **simple**: 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.
* Be **comprehensive**: 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.
* Be **flexible and light-weight**: 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.
A number of details were discussed in `this Discourse thread
<https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/>`__,
which may be useful to anyone trying to understand the rationale for
various minor decisions.
Specification
=============
The steering council
--------------------
Composition
~~~~~~~~~~~
The steering council is an elected committee of 5 core team members.
Mandate
~~~~~~~
The steering council's shall work to:
* Maintain the quality and stability of the Python language and
CPython interpreter,
* Make contributing as accessible, inclusive, and sustainable as
possible,
* Formalize and maintain the relationship between the core team and
the PSF,
* Establish appropriate decision-making processes for PEPs,
* Seek consensus among contributors and the core team before acting in
a formal capacity,
* Act as a "court of final appeal" for decisions where all other
methods have failed.
Powers
~~~~~~
The council has broad authority to make decisions about the project.
For example, they can:
* Accept or reject PEPs
* Enforce the Python code of conduct
* Work with the PSF to manage any project assets
* Delegate their authority to other subcommittees or processes
However, they cannot modify this PEP, or affect the membership of the
core team, except via the mechanisms specified in this PEP.
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.
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 a strict majority of
non-abstaining council members.
Whenever possible, the council's deliberations and votes shall be held
in public.
Electing the council
~~~~~~~~~~~~~~~~~~~~
A council election consists of two phases:
* Phase 1: Candidates advertise their interest in serving. Only core
team members may be candidates.
* Phase 2: Each core team member can vote for zero to five of the
candidates. Voting is performed anonymously. Candidates are ranked
by the total number of votes they receive. In case of a tie, the
candidate who joined the core team earlier wins.
Each phase lasts one to two weeks, at the outgoing council's discretion.
For the initial election, both phases will last two weeks.
The election process is managed by a returns officer nominated by the
outgoing steering council. For the initial election, the returns
officer will be [TBD].
The council should ideally reflect the diversity of core Python
contributors, and core team members are encouraged to vote
accordingly.
Term
~~~~
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.
Vacancies
~~~~~~~~~
Council members may resign their position at any time.
Whenever there is a vacancy during the regular council term, the
council may vote to appoint any willing core team member to serve out
the rest of the term.
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.
Conflicts of interest
~~~~~~~~~~~~~~~~~~~~~
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.
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.
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.
Ejecting core team members
~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
Vote of no confidence
~~~~~~~~~~~~~~~~~~~~~
In exceptional circumstances, the core team may remove a sitting
council member, or the entire council, via a vote of no confidence.
A no-confidence vote is triggered when a core team member calls for
one publically on an appropriate project communication channel, and
another core team member seconds the proposal.
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.
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.
The core team
-------------
Role
~~~~
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.
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.
They will intervene, where necessary, in online discussions or at
official Python events on the rare occasions that a situation arises
that requires intervention.
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.
Prerogatives
------------
Core team members may participate in formal votes, typically to nominate new
team members and to elect the steering council.
Membership
----------
Python core team members demonstrate:
- a good grasp of the philosophy of the Python Project
- a solid track record of being constructive and helpful
- significant contributions to the project's goals, in any form
- willingness to dedicate some time to improving Python
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:
- Working on community management and outreach
- Providing support on the mailing lists and on IRC
- Triaging tickets
- Writing patches (code, docs, or tests)
- Reviewing patches (code, docs, or tests)
- Participating in design decisions
- Providing expertise in a particular domain (security, i18n, etc.)
- Managing the continuous integration infrastructure
- Managing the servers (website, tracker, documentation, etc.)
- Maintaining related projects (alternative interpreters, core
infrastructure like packaging, etc.)
- Creating visual designs
Core team membership acknowledges sustained and valuable efforts that
align well with the philosophy and the goals of the Python Project.
It is granted by receiving at least two-thirds positive votes in a
core team vote and no veto by the steering council.
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.
There's no time limit on core team membership. However, in order to
provide the general public with a reasonable idea of how many people
maintain Python, core team members who have stopped contributing are
encouraged to declare themselves as "emeritus members". Those who
haven't made any non-trivial contribution in two years may be asked to
move themselves to this category, and moved there if they don't
respond. Emeritus team members lose their privileges such as voting
rights and commit access.
Changing this document
----------------------
Changes to this document require at least a two-thirds majority of
votes cast in a core team vote.
TODO
====
- Maybe add compare-and-contrast with other 801x proposals?
- Ask Ian or Ernest if they're willing to be the initial returns officer.
- Lots of people contributed helpful suggestions and feedback; we
should check if they're comfortable being added as co-authors
- 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.
Acknowledgements
================
Substantial text was copied shamelessly from `The Django project's
governance document
<https://docs.djangoproject.com/en/dev/internals/organization/>`__.
Copyright
=========
Text copied from Django used under `their license
<https://github.com/django/django/blob/master/LICENSE>`__. The rest of
this document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End: