PEP 8014: The Commons Model

That seems like a good idea. But I think I would simply judge that as “anonymous”, with a specific implementation.

If the meaning of a vote is to be chosen and interpreted by the Council, it seems it makes voting futile in the end. It is more like a tyranny disguised in democracy (“vote however you want, but at the end we’ll choose how to count and interpret the results”).

Where does the rule end exactly? You are phrasing this so vaguely that it looks ready to be abused.

What I have been trying to do in 8014 is to keep the procedures workable for the Python community. The community consists mainly of well-meaning individuals. Indeed, a theoretical malevolent council could make a bit of a mess of things, but similarly in the past a BDFL that wasn’t benevolent could have done that. But, really, I cannot imagine any group of 5-10 individuals (with enough standing in the community to be selected as Elder) using their vaguely formulated and limited powers to push through a decision that goes against the majority wish.

The “emergency brake” procedure is intended to handle the (again, highly improbable to the extreme, IMO) situation that the council turns out to be malevolent.

I don’t think that it’s needed. There is already a weight assigned to each vote: one a local expert votes, I follow them if I trust them and have no opinion. People listen to experts and follow their votes.

I dislike the ability to put a weight on each vote, it seems too complex to apply and IMHO it gives too much power to the council. You can control the vote just by giving more weight to people who agree with you.

2 Likes

Again I haven’t been clear enough, apparently. I’m not advocating that the council internally discusses and uses a weighting mechanism.

The intention of the proposal is that the council looks at the PEP, looks at the voters and looks at how they voted. The council them makes an educated guess on whether they think the PEP is carried by a sufficient majority of the community. The council is made up of sensible people who - together - have a good knowledge of both Python and the Python community so their educated guess should usually be correct. But because it can’t always be correct there’s the “tentative” period, so that community members who weren’t following the discussion until the council posted their tentative decision can then stand up and say “Wait a minute! You’re forgetting about community group X! And they would probably be opposed!”.

Reading through this PEP, a few things stuck out to me.

This PEP states that “All decisions go through a PEP process”, but I suspect that’s not really what you meant. There are a wide range of decisions that are involved in the maintaining of Python all the way from merging small typos (deciding to merge a PR is after all a decision), to minor bug fixes, major bug fixes, minor features, and all the way up to large controversial changes. I suspect that you don’t expect all of these types of decisions to go through the PEP process, so perhaps this is better worded as “Controversial decisions” or “Major decisions” or something along those lines? If on the other hand you actually do mean all decisions, that should probably be way more obvious in the PEP since it is a serious divergence from the status quo.

There is a lot of ambiguity given to how a vote is actually conducted. While I understand that ambiguity is a feature not a bug of this proposal, is the intention that the CoE will select the voting mechanism that they want people to use?

There seems to be an open question on how the CoE should “speak” (the PEP says it’s not sure how this is to be handled, I see discussion earlier on in this thread about it). Is this something you expect the CoE to decide for itself? If so that should probably be explicitly mentioned in the PEP. If you expect the PEP itself to define that mechanism, then that should be defined prior to the vote occurring.

There seem to be a whole lot of open questions in this PEP regarding to council size, how members are chosen (both into the future, and the initial set), what the “emergency brake” mechanism is and how it is engage (and whether it applies to the council as a whole or individual members of said council). These are called out in the PEP as open questions, but given the current target to start voting is in 2 weeks, it’s probably getting to crunch time to get these things defined?

Largely I share the concerns the other people have, that this feels like rule by council disguised as democracy given that the CoE can declare a vote that goes against their preferences as “invalid” for fairly arbitrary criteria, though I don’t suspect there to be much you can do with that particular feedback without materially changing the idea in the PEP.

I don’t understand if you would like real anarchy or a strict council? Don’t say both, I don’t see how having council which take decision is compatible with anarchy.

In my Comparison of the 7 governance PEPs you wrote “PEP 8014 has no hierarchy.” But your PEP describes a Council of Elders which “take decisions”… but it’s really difficult for me to understand the limits of its power and which can of decisions they can take. Since you wrote “There does need to be an “emergency brake” procedure to remove the whole council”, I understand that the Council does have power. Otherwise, what’s the point of having a process to remove it?

It’s also unclear who vote. You modified my summary of PEPs to write “vote (open to anyone)” for the PEP process, but it’s not very explicit from your PEP. For a vote on a PEP, who decides if a PEP requires “majority” or “real majority”? By the way, would it be possible to have number for “majority”? For some people, majority means 50%+1, for others it means >= 2/3. Please see my Maths on vote majority thread. First I used 50%+1, but then I realized that it can be dangerous to approve a PEP when “half” of core devs dislike it. So I changed “majority” to 2/3. See maybe Annex: Summary on votes of my PEP 8015.

It’s also very unclear who can be part of the Council and how the Council is created. In my summary, I left a “?” for the election part. The duration of mandate is not described neither. “it is probably good if members serve for a fairly long time” What does “long time” mean? 1 year? 5 years? 10 years? 26 years as Guido? I don’t ask you to write an exact value in your PEP, but maybe write a range like 5-10 years.

It seems to be a deliberate choice of you to be unclear, but I dislike your PEP because of that. I’m not comfortable with it. I’m not even talking about the way decisions are taken, but the fact that I don’t know if the Council can decide that they will start to approve PEPs themselves, block the promotion of a core dev, eject some core developers, change the governance, etc. It seems like it’s not your intent, but it’s not written down.

1 Like

I promise I will clarify exactly these issues in the update to the PEP (because they were indeed much less clear in the writing than they are in my head). But to answer some of the issues you mention here: it is an anarchy, with the council only overseeing the voting process on individual decisions (I’m tempted to clarify this by adding a subtitle Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony to the PEP title:-).

The council is expected to use “common sense” and “knowledge of Python and the community” to judge whether the measurable outcome of a vote (how many people voted, who are they, how did they vote) reflects the will of the community. This so we don’t need exact numbers and procedures and voting systems and all that.

And I initially left the emergency brake, initial selection and renewal processes vague, because I felt they were not important. I still think they’re not important, but I do now think it is important to formalize them. I’ll do so.

1 Like

Note that a new version of this PEP is below, at PEP 8014: The Commons Model but I want to keep this intermediate version here because (linking to the new version as opposed to replacing the old one by the new one) because otherwise all the replies to this version lose their meaning.

Here is a new version of this PEP. I have added various procedures (on selecting the initial Council, on how a council can be voted out, on limitations of the freedom of the council).

PEP: 8014
Title: The Commons Governance Model
Author: Jack Jansen
Status: Active
Type: Informational
Content-Type: text/x-rst
Created: 2018-09-16

Abstract

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 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
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,
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.

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 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

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 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).

There is also the issue that one-person-one-vote is not the best model for
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
model presented here leaves deciding on such issues to the (hopefully
sensible) council of elders.

Decision Process

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
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, 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 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
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

It is also somewhat like the election commission that many countries have
(under different names) in that it oversees elections.

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 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
    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 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. 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 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. 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”.

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 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.

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.

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. So: we should realise
that it is unlikely that a PEP like PEP 572 will pass if this model is in
place.

Copyright

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:

Let me try to understand that.

The council is free to decide that only 20% of votes who likes a PEP is enough to approve the PEP. I exaggerate, I’m thinking aloud to try to understand the scope of it’s role. Am I right?

Obviously, the council should not do that, to not risk to be destroyed by a non confidence vote. I guess that the council should require at least 50% majority if not more to make sure that the opposition against the council is not to strong :slight_smile: Recently, I heard that some people asking if the governance could undo the PEP 572 approval. I understand that approving the PEP 572 when most people are against it would be a bad move for the council.

It’s unclear to me if the council can reject a PEP. It seems like the only two choices are Approve or Deferred.

Ok, but I still don’t understand how the council is supposed to be created initially?

And just for my clarity, the Council can be anyone? Not just core developers? (I think this is a really good idea, btw, if true.)

Theoretically: yes. But the real question is: why would they ever do that (unless there was a very good reason for it)? The Elders aren’t random individuals picked up off the street or elected by throwing large wads of cash at uninformed voting masses… They are respected individuals from our community…

Very good point, we could end up with loads of deferred PEPs if the authors were unwilling to retract them. I will add a timeout mechanism.

That is explained in the last paragraph of that section. Does it need more emphasis (or should it be moved up)?

Correct. I will clarify.

1 Like

Oh, I missed it:

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.

In short, there is a vote open to everyone. Who organizes the code? The PSF? Using which voting method? Who decide the initial number of members for this council?

I understand that when there is a council, the council decides conditions for the new council: how to vote, number of members, etc. But the creation of the council seems poorly defined. Moreover, we move back to the creation of the council point if there is a vote of no confidence against the whole council and the whole council is evicted. How is the new council created?

The PSF. But for no other reason really that the PSF has the infrastructure to organize votes.

Ideally I would like something like acclamation for the initial council (and I consider the situation after a vote of no confidence to be identical to the initial situation, btw). By acclamation here I mean: a small group of people stand up, and the whole community expresses widespread trust in them. This is fairly easy to organise in a physical meeting, but not so for easy our community which is widespread in space and time. The initial selection method sketched here tries to do so anyway.

But: I’m open to other ideas, so feel free to suggest something…

And here is the third version of 8014.

PEP: 8014
Title: The Commons Governance Model
Author: Jack Jansen
Status: Active
Type: Informational
Content-Type: text/x-rst
Created: 2018-09-16

Abstract

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 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
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,
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.

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 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

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 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).

There is also the issue that one-person-one-vote is not the best model for
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
model presented here leaves deciding on such issues to the (hopefully
sensible) council of elders.

Decision Process

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
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, 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 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
gather more support and resubmit the vote at a later date. Alternatively the
author can retract the proposal. The period for gathering more support is
time-limited, a month seems a reasonable time, if no vote has been resubmitted
after that period the proposal is rejected.

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

It is also somewhat like the election commission that many countries have
(under different names) in that it oversees elections.

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 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
    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 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. 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 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
. Council members may be core developers but this is not a requirement.

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. 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”.

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 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.

If there is no functioning council (the current initial 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.

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. So: we should realise
that it is unlikely that a PEP like PEP 572 will pass if this model is in
place.

Copyright

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:

You can also modify your first message, or even convert it to a wiki. Discourse still keeps the history of each modified message.

Hmm. I didn’t do that, because it would make the thread unreadable (the replies that had been posted to a previous version might become meaningless). This is exactly why I don’t really like Discourse and such: by modifying content (other that fixing spelling errors and such) you ruin the conversation…

When I posted multiple versions of a PEP on python-dev, I started a new thread for each version. But here, I’m trying new things :slight_smile:

1 Like