PEP 8014: initial version of Commons Governance Model (#794)
* Placeholder for pep-80xx Commons Governance Model * Placeholder for pep-80xx Commons Governance Model * Use 8014 * Introduction, and got started on CoE * Wrote on the decision process and started on council membership * Got quite a bit further. CoE operations still TBD. * Expanded operation section, and reflowed some parts. * Finished discussion section. * Added initial version of pep-8014 to pep-8000
This commit is contained in:
Jack Jansen
Łukasz Langa
parent
fedbed6f20
commit
af81e9febb
|
|
@ -77,6 +77,15 @@ PEPs.
|
|||
appropriate for the upcoming release. This PEP does *not* name members of
|
||||
such a council. For that, see PEP 13.
|
||||
|
||||
* PEP 8014 - The Commons Governance Model
|
||||
|
||||
This PEP describes a new model of Python governance based on a council of
|
||||
elders who are responsible for ensuring a PEP is supported by a sufficient
|
||||
majority of the Python community before being accepted. Unlike some of the
|
||||
other governance PEPs it explicitly does *not* specify who has voting
|
||||
rights and what a majority vote consists of. In stead this is determined
|
||||
by the council of elders on a case by case basis.
|
||||
|
||||
Additional governance models may be added before the final selection.
|
||||
|
||||
|
||||
|
|
|
|||
270
pep-8014.rst
270
pep-8014.rst
|
|
@ -6,12 +6,6 @@ Type: Informational
|
|||
Content-Type: text/x-rst
|
||||
Created: 2018-09-16
|
||||
|
||||
|
||||
.. note:: This is just a placeholder until the actual governance PEPs are
|
||||
written. It is possible that the title, content, model proposed,
|
||||
and authorship will change once the PEP is actually written.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
|
|
@ -20,14 +14,266 @@ 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 rationale for the model is that everything that is cast in concrete will
|
||||
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
|
||||
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
|
||||
council bases its decision not only on the ratio of yes and no votes but
|
||||
also on the total number of votes, on the gravity of the proposal being
|
||||
voted on and possibly the individual voters and how they voted. Thereby this
|
||||
council becomes responsible for ensuring that each individual decision is
|
||||
carried by a sufficient majority.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
The Commons Governance Model tries to ensure that all decisions are endorsed
|
||||
by, or at least is acceptable to, a sufficient majority of the Python
|
||||
community.
|
||||
|
||||
Unfortunately the previous paragraph has two terms that are very hard to
|
||||
quantify in the general case: *sufficient majority* and *Python community*.
|
||||
This is because both terms in reality depend on the *specific* case that is
|
||||
being decided. To give an example of this difficulty: for a PEP that
|
||||
proposes a backward-compatible change to some API a simple majority of the
|
||||
core developers that were interested in voting on the PEP in the first place
|
||||
is probably sufficient. But for a change that has more farreaching
|
||||
consequences such as a Python3 to Python4 transition a real majority may be
|
||||
wanted, and a demonstration that at least there seems to be sufficient
|
||||
support in the user base. And for a change that transcends the
|
||||
Python-the-language, such as decisions on abolishing non-inclusive language,
|
||||
it becomes very vague.
|
||||
|
||||
The Commons Governance Model attempts to sidestep this issue by *not*
|
||||
defining what the terms *sufficient majority* and *Python community* mean in
|
||||
the general case, by proposing a body that will decide so in *specific*
|
||||
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.
|
||||
|
||||
The model addresses only the roles traditionally held by the BDFL in the
|
||||
decision process, not other roles.
|
||||
|
||||
The term Commons_ in the model name is loosely based on its historic use as
|
||||
a shared resource to be used by all and cared for by all. The picture you
|
||||
should have in mind with this model is a sizeable group of peasants
|
||||
discussing some plan for the future on the village green on a warm summer
|
||||
evening, after which the vote is taken and the village elders pronounce
|
||||
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.
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
The rationale for the model is that a model that casts everything in concrete will
|
||||
have unintended negative side effects. For example, a governance model that
|
||||
assigns voting rights to, say, Python committers may cause individuals not
|
||||
assigns voting rights to Python committers may cause an individual not
|
||||
to be accepted as a committer because there are already a lot of committers
|
||||
from the company the new candidate works for. As another example, setting
|
||||
a fixed percentage for PEP acceptance may lead to party-formation amongst
|
||||
the voters and individual PEPs no longer be being judged on individual merit
|
||||
but along party lines (if you support my PEP I will support yours).
|
||||
from the company the new candidate works for.
|
||||
|
||||
As another example, setting a fixed percentage for PEP acceptance may lead
|
||||
to party-formation amongst the voters and individual PEPs no longer be being
|
||||
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
|
||||
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
|
||||
model presented here leaves deciding on such issues to the (hopefully
|
||||
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
|
||||
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
|
||||
something like that.
|
||||
|
||||
The PEP author is responsible for organizing a vote on the PEP. This vote is
|
||||
public, i.e. the voters are identified and the results are known to all.
|
||||
Voting may be simple +1/0/-1, but might also be extended with +2/-2 with a
|
||||
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
|
||||
(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.
|
||||
|
||||
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
|
||||
gather more support and resubmit the vote at a later date. Alternatively the
|
||||
author can retract the proposal.
|
||||
|
||||
If the tentative decision is that the results *do* demonstrate enough support
|
||||
a fairly short waiting period starts (in the order of weeks). During this
|
||||
period anyone can appeal to the Council of Elders, but *only* on the grounds
|
||||
that the vote does not reflect a sufficient majority of the community.
|
||||
After the waiting period the council pronounces a final decision. The PEP
|
||||
is either accepted or, if the council is swayed by an appeal, goes back to
|
||||
the state where more support has to be demonstrated.
|
||||
|
||||
|
||||
Council of Elders
|
||||
=================
|
||||
|
||||
The intention of the Councel of Elders is that they, together, are capable
|
||||
of judging whether the will of the Python community is upheld in a specific
|
||||
vote.
|
||||
|
||||
The Council of Elders is *not* a replacement of the BDFL by a group of
|
||||
people with the same power as the BDFL: it will not provide guidance on the
|
||||
direction of Python, it only attempts to ensure the outcome of a vote
|
||||
represents the will of the community.
|
||||
|
||||
The Council of Elders is *not* like the US Supreme Court, which has actual
|
||||
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
|
||||
`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
|
||||
|
||||
Council operation
|
||||
-----------------
|
||||
|
||||
The council members are volunteers, and most likely have other roles within
|
||||
the Python community as well (not to mention a life outside Python). This
|
||||
means that the workload on the members should be kept to a minimum. It also
|
||||
means that it should be clear when an individual council members speak as
|
||||
council member and when they speak as themselves. And we should care about
|
||||
the emotional load: council members should not be held accountable for
|
||||
decisions by random flamers on the Python mailing list.
|
||||
|
||||
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 community has a chance to point out these mistakes.
|
||||
|
||||
Practically speaking this means that the tentative decision can be taken by
|
||||
a subset of the council, depending on the community to correct them.
|
||||
Getting seven hard-working professionals together every two weeks, even by
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
.. _Ex Cathedra: https://en.wikipedia.org/wiki/Papal_infallibility
|
||||
|
||||
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.
|
||||
The members should be knowledgeable about Python and the
|
||||
Python community, and willing to be impartial *while operating as part of
|
||||
the council*.
|
||||
|
||||
Everyone in the community should feel represented by the council so it would
|
||||
be good if the council is diverse:
|
||||
|
||||
- scientists and technologists,
|
||||
- progressives and conservatives (with respect to the Python language),
|
||||
- people with different cultural backgrounds, genders, age,
|
||||
- etc
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
The 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
|
||||
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
|
||||
=========
|
||||
|
|
|
|||
Loading…
Reference in New Issue