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

PEP8014: Added procedures for initial CoE selection, vote of no confidence. Added clarifications. Made some choices on implementation. Added 50%+1 rule. (#835)

This commit is contained in:
Jack Jansen 2018-11-09 01:41:17 +01:00 committed by GitHub
parent 5961fce600
commit 939c89d87f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 91 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

155
pep-8014.rst
View File

@ -9,13 +9,14 @@ Created: 2018-09-16
Abstract
========
This PEP proposes a governnance model with as few procedures, defined terms and
This PEP proposes a governance model with as few procedures, defined terms and
percentages as possible. It may also be called *The Anarchist Governance Model*
but uses *Commons* for now because of possible negative connotations of the
term *Anarchist* to some audiences.
The basic idea is that all decisions are voted on by a subset of the
community. A subset, because although the whole community is in principle
The basic idea is that all decisions are in principle voted on by the whole
community, but in practice voted on by a only subset of the
community. A subset, because although the whole community is
entitled to vote in practice it will always be only a small subset that vote
on a specific decision. The vote is overseen by an impartial council that
judges whether the decision has passed or not. The intention is that this
@ -52,9 +53,9 @@ cases.
The model proposes creating a *Council of Elders* that oversees the decision
process, determining whether a specific proposal has enough support on a
case by case basis. There will be a vote on every individual PEP (or
PEP-like decision), and the Council of Elders will declare whether the
outcome of the vote is sufficient to carry the decision.
case by case basis. There will be a vote on every individual PEP,
and the Council of Elders will declare whether the
outcome of the vote is sufficient to carry the decision *in this specific case*.
The model addresses only the roles traditionally held by the BDFL in the
decision process, not other roles.
@ -68,8 +69,9 @@ the outcome. Then the banquet begins.
.. _Commons: https://en.wikipedia.org/wiki/Commons
The Commons Governance Model shares some principles with some of the other
proposed models, and I can imagine it being merged with those.
The Commons Governance Model is different from most of the other governance
proposals (with the possible exception of 8012), because it explicitly places
supreme power with the whole community.
Rationale
=========
@ -86,7 +88,8 @@ judged on individual merit but along party lines (if you support my PEP I
will support yours).
There is also the issue that one-person-one-vote is not the best model for
something like Python. Again an example: the opinion of core developer Guido
something like Python. Again an example: in case of a split vote (or a vote
sufficiently close to being split) the opinion of core developer Guido
van Rossum should probably outweigh the opinion of core developer Jack
Jansen. Trying to formalize this in a voting model is going to lead to a
very complex model, that is going to be wrong on boundary cases anyway. The
@ -96,9 +99,7 @@ sensible) council of elders.
Decision Process
================
All decisions go through a PEP process (if it turns out that this pollutes
the PEP namespace too much we create another namespace, such as Python
Decision Proposal, with a very similar structure). Each PEP has someone
All important decisions go through a PEP process. Each PEP has someone
responsible for it, called the *author* here, but that does not have to be a
single person, and it does not have to be the person that actually wrote the
text. So for author you could also read *champion* or *shepherd* or
@ -111,15 +112,19 @@ very terse explanation why the voter feels very strong about the issue. Such
an annotation would serve as an explanation to the Council of Elders. Voters
are annotated with their community status (core developer, etc).
The vote is clearly separated from the discussion, either by using a
special mailing list or special subject, or a different technical method
The vote is clearly separated from the discussion, by using a well-defined Discourse
category or tag, a special mailing list or a similar technical method
(such as a website vote.python.org where people have to log in so their
community status can be automatically added, and their identity can be somewhat
confirmed).
The PEP author presents the PEP and the vote results to the Council of Elders.
The council ponders the PEP content and its implications and the vote results.
They pronounce a tentative decision and this decision is published.
The council ponders two things:
- the PEP gravity and its implications,
- the measureable vote results (how many people voted, which individuals voted, what they voted).
They pronounce a tentative decision on whether the vote passed and this decision is published.
If the decision is that the vote results do not demonstrate enough support
from the community for the decision the burden is on the author to try and
@ -152,13 +157,18 @@ decision power, the council only oversees the voting process to ensure that
the community is represented in the vote. And the Council of Elders is most
definitely not like the Spanish Inquisition, because fear, surprise and
ruthless efficiency are things we can do without (but there is some merit in
using the cute scarlet regalia). The council is somewhat like the dutch
using the cute scarlet regalia).
The council is somewhat like the dutch
`Hoge Raad`_ (which is unfortunately often translated as Supreme Court in
English) in that they judge the process and the procedures followed and can
only send cases back for a renewed judgement.
.. _Hoge Raad: https://en.wikipedia.org/wiki/Supreme_Court_of_the_Netherlands
It is also somewhat like the *election commission* that many countries have
(under different names) in that it oversees elections.
Council operation
-----------------
@ -174,8 +184,8 @@ The proposal attempts to minimize the workload through two methods:
- Most of the actual work is to be done by the PEP author and the community,
the Council of Elders does not organize the vote and tally the results.
- The idea behind the first tentative decision is that this allows the Council
of elders to make mistakes (by misjudging how far-reaching a PEP is) because
- The idea behind the first tentative decision is mistakes by the Council
of elders (misjudging how far-reaching a PEP is, most likely) are not fatal, because
the community has a chance to point out these mistakes.
Practically speaking this means that the tentative decision can be taken by
@ -184,28 +194,44 @@ The proposal attempts to minimize the workload through two methods:
email, may be a bit much to ask.
Clarifying when an individual Elder speaks on behalf of the Council is
probably best done by using a special email address, or some other
means that unequivocally flags this fact. There is an analogy with the Pope
probably best done by using a special email address, or some Discourse topic
into which only Elders can post. There is an analogy here with the Pope
speaking `Ex Cathedra`_ or just as himself (in which case he is not
infallible). The elders are most likely respected members of the community
and it would be a bad idea if they feel they cannot voice their personal opinion on
a PEP because they are on the council.
Discussion of community members *with* the Council of Elders, i.e. when appealing a
decision, should be done in a different forum (Discourse topic, mailing list).
The decisions of the Council of Elders should be seen as decisions of the
council as a whole, not as decisions of the individual members. I am unsure
whether it is a good idea to have the whole council use a single email address
to ensure anonymity, because it is unclear whether this works in the first place
and it may take things too far. I am also unsure whether the discussions within
the council are private or open. I lean towards having individual email
addresses and keeping the discussions private, but I do not really know why.
council as a whole, not as decisions of the individual members. In a first implementation
Elders should post under their own name (with the fact that they speak as a
council member conferred by the topic they post to, or possibly a special badge).
If it turns out that Elders become individual targets for ad-hominem attacks
we should revisit this and come up with some method of anonimity.
.. _Ex Cathedra: https://en.wikipedia.org/wiki/Papal_infallibility
Limitation of freedom
---------------------
If a specific vote has a true majority (for or against) of core team members
(more than 50% + 1 of all core team members) that outcome passes. If a specific
vote has a true majority (for or against) of PSF voting members
(more than 50% + 1) that outcome passes. And, for completeness, if both of the
previous statements are true but with opposite outcomes the core team members
win.
The main reason for having this limitation is that it allows decisions to be
made (albeit with effort) if there is no functioning Council of Elders at
any particular moment.
Council composition
-------------------
The council should not be too big nor too small, probably somewhere between
5 and 10 members. There is probably no reason to fix this number.
5 and 10 members. There is no reason to fix this number.
The members should be knowledgeable about Python and the
Python community, and willing to be impartial *while operating as part of
the council*.
@ -221,60 +247,61 @@ be good if the council is diverse:
But: this should hold for the council as a whole. Individual council members
should not be seen as representing a specific interest group.
Council membership
------------------
Because the powers of the council are purely procedural it is probably good
if members serve for a fairly long time, and there are no things like yearly
re-elections with fixed terms and all that.
if members serve for a fairly long time. However, it would still be good if
the council was reinstated regularly. Therefore the suggestion is to have the council
operate under the PSF umbrella and be subject of a yearly vote of confidence. This
vote is for the council as a whole: people who vote against the council should be
aware that they are basically saying "Python is better off without a Council of Elders
than with you lot".
Appointing members to the council could be done through voting, for example
under the PSF umbrella or by the core developer community (similar to how
core developers are ordained currently). But it may be that co-optation works
just as well and is a lot simpler. Council members should be free to retire at
any time. There may need to be a procedure whereby one council member can
be removed through a unanimous vote of the remaining members but this is
probably overkill.
The council normally co-opts new Elders, probably because an individual is seen
to have knowledge about a specific part of the Python community (or language) in which
the council is lacking. Everyone is free to suggest new Elders to the council
(including themselves) but the council is free to ignore the suggestion.
Council members should be free to retire at any time. An individual council
member can be retired by a unanimous vote by the rest of the council.
There does need to be an "emergency brake" procedure to remove the whole
council but as it is intended to never be invoked it can be heavy-handed
(for example a true majority vote from all PSF members or all core
developers).
There is an emergency brake procedure to get rid of a non-functioning council.
A single Elder or a group of 10 core developers or PSF voting members can ask for
an immedeate reinstating vote of the council as a whole (presumably with the
intention that the council lose their mandate). If this vote has been requested by an
Elder that individual immedeately lose their council position, independent of
the outcome of the vote. If the vote has been requested by community members and
the council is reinstated this procedure cannot be invoked again for a year.
Selection of the initial council is to be determined. We could ask the old
BDFL to suggest some names. Or again we could have some initial names
circulate amongst the core developers or the PSF and vote on those.
If there is no functioning council (the current situation, or after the
council have lost their mandate after a vote of no confidence) an initial
council must be selected. Through the normal communication channels (discourse,
mailing lists) members can be suggested by anyone (including themselves). After
discussion amongst the nominees and in the whole community a group of at least
three individuals should emerge that ask for an initial vote to instate them
as Council of Elders. The intention of this procedure is that by the time such
a group of individuals emerges and asks for a vote of confidence they expect an
overwhelming mandate.
Discussion
----------
==========
This PEP does not handle other roles of the BDFL, only the voting process.
Most importantly, the direction of Python in the long term is not expected
to be handled by the Council of Elders. This falls to the community as a whole
(or to individual members of the community, most likely). There is also
the role of figurehead or spokesperson to represent Python and the Python
community to the outside world. Again, this is not a role that should be
handled by the Council of Elders, in my opionion, but by some other
person or body.
(or to individual members of the community, most likely).
The proposal most likely favors conservatism over progression. Or, at least, the
There is also the role of figurehead or spokesperson to represent Python and
the Python community to the outside world. Again, this is *not* a role that
should be handled by the Council of Elders, in my opionion, but by some
other person or body.
Note that this proposal most likely favors conservatism over progression. Or, at least, the
danger of it leading to stagnation is bigger than the danger of it leading
to reckless blazing ahead into unknown territories. But: we should realise
to reckless blazing ahead into unknown territories. So: we should realise
that it is unlikely that a PEP like PEP 572 will pass if this model is in
place.
There are three open issues that need to be resolved before this PEP
is in a state where it is implementable:
- Openness of the decision process within the council, and whether the
council speaks as a collective only (which would require a closed decision
process) or not is still an open issue.
- The selection procedure for the initial Council of Elders needs to be defined.
- The procedure through which the Council of Elders is renewed and extended
needs to be defined.
- The technical details of the voting process need to be worked out.
Copyright
=========