# PEP 8014: The Commons Model **URL:** \ **Category:** Committers\ **Tags:** governance\ **Created:** [October 4, 2018, 5:45pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173 "2018-10-04T17:45:40Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 4, 2018, 5:45pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/1 "2018-10-04T17:45:40Z")
**Note that a new version of this PEP is below** , at [PEP 8014: The Commons Model](https://discuss.python.org/t/pep-8014-the-commons-model/173/29?u=jackjansen) but I want to keep this original 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 original version lose their meaning. 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 governnance 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 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](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 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: 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](http://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](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. 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](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 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: ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [October 5, 2018, 4:00am UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/2 "2018-10-05T04:00:12Z")
Just wanted to add beyond the “like” that this feels like the most feasible proposal so far (including mine). While discussing PEP 8013 with people, having a way to override the council by popular vote seemed important, so it might be worth saying something explicit about that (or if I missed it, make it more obvious 🙂 ). Even if it’s just “we voted this model in, so we can vote it out” - my approach here was to allow a specific council member to be removed by vote, but an alternative might be to have an objective mechanism to override a “please get more consensus” response… though I guess since that would take more consensus perhaps it wouldn’t help… ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [October 5, 2018, 4:01am UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/3 "2018-10-05T04:01:25Z")
> [@jackjansen](#): > > There are three open issues I was going to just edit and fix this, but you got me thinking about the Spanish Inquisition and it’s too nice an Easter egg 😂 ---
**Author:** ![willingc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/willingc/32/20_2.png) [@willingc](https://discuss.python.org/u/willingc)\ **Post date:** [October 5, 2018, 5:34am UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/4 "2018-10-05T05:34:26Z")
An interesting approach to the PEP process aspect of governance. I would recommend against anonymous emails and instead have the Council Elder just preface comments as an Elder versus an individual with a phrase like “As an elder…” In general, transparency in discussions is preferred to closed discussions. If there is a need for sensitive discussion, the Council could report out the highlights of the discussion (without names if desired) to the greater community. Trust is key to an effective Commons. Thanks for taking the time to put this together. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [October 5, 2018, 8:32am UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/5 "2018-10-05T08:32:54Z")
This is a very interesting proposal, thank you! > [@jackjansen](#): > > 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. Sounds like the French [Cour de Cassation](https://en.wikipedia.org/wiki/Court_of_Cassation_(France)) as well. > [@jackjansen](#): > > Again an example: the opinion of core developer Guido > van Rossum should probably outweigh the opinion of core developer Jack > Jansen. Does your PEP encourage the Council of Elders to give more importance to certain people’s votes? ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 5, 2018, 6:40pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/6 "2018-10-05T18:40:12Z")
> [@willingc](#): > > An interesting approach to the PEP process aspect of governance. I would recommend against anonymous emails and instead have the Council Elder just preface comments as an Elder versus an individual with a phrase like “As an elder…” Good point. And I’m not convinced about anonymity myself (as I think is clear from the wording). My reason to think about having CoE communication to the outside world being anonymous is that I would like to forestall individual Elders being held responsible for a specific decision. First and foremost, I’m afraid that, given the size of the larger community, this could cause them to receive ad-hominem attacks for decisions that are unpopular with some individuals. Second, the CoE is in essence a procedural committee only so they’re not really deciding anything, they’re only judging the level of support from the community while taking the gravity of the proposal into account. As to internal discussions of the CoE being open or not: you’re right, nothing stops the CoE members from conversing over private email and only reporting the outcome of that in the public CoE channel. As I said: I’m of two minds myself on this. Let me try and add a poll here just to see what everyone thinks, and based on that I’ll put in that solution as the preferred option in the PEP. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 5, 2018, 6:46pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/7 "2018-10-05T18:46:56Z")
> [@pitrou](#): > > Does your PEP encourage the Council of Elders to give more importance to certain people’s votes? The proposal definitely wants to keep that option open, i.e. this is at the discretion of the council. The intention is not only that the council can assign different weights to different people (the Guido versus Jack example in the PEP) but also that the council can recognise bloc voting (and therefore possibly assign a lower weight to the votes). For that latter, think of a group of core developers from a single company voting a certain way, or only people from a specific country/culture/background partaking in some vote. The intention is that the council can detect such situations (possibly after it has been pointed out to them during the tentative decision period) and can decide that the vote may be lacking in support from other companies/cultures/backgrounds/etc. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 5, 2018, 6:51pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/8 "2018-10-05T18:51:07Z")
> [@steve.dower](#): > > While discussing PEP 8013 with people, having a way to override the council by popular vote seemed important, so it might be worth saying something explicit about that (or if I missed it, make it more obvious 🙂 ). That “emergency brake” procedure was intended to handle exactly that case. Do you think it needs to be more prominently stated, or do you think it isn’t the right procedure? ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [October 5, 2018, 6:56pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/9 "2018-10-05T18:56:27Z")
Probably there should just be a designated spokesperson for the CoE. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 5, 2018, 7:04pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/10 "2018-10-05T19:04:23Z")
> [@guido](#): > > Probably there should just be a designated spokesperson for the CoE. Maybe I’m worrying too much, but I think this would _increase_ the risk of that spokesperson being held responsible for the outcome of the vote… But I’ll add this option to the poll. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 5, 2018, 7:12pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/11 "2018-10-05T19:12:04Z")
I’d like to take a poll on the anonymity of the council of elders. Based on the results I’ll change the preferred option in the PEP. > [@jackjansen](#): > > - 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. Please show your preference here: _Poll ([view on site](https://discuss.python.org/t/pep-8014-the-commons-model/173/11))_ ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [October 5, 2018, 7:20pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/12 "2018-10-05T19:20:10Z")
> [@jackjansen](#): > > Maybe I’m worrying too much, but I think this would _increase_ the risk of that spokesperson being held responsible for the outcome of the vote… Perhaps the spokesperson should not be a member of the CoE but instead a PSF spokesperson. It depends on the situation though. Sometimes a specific CoE member may indeed be responsible. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 5, 2018, 7:49pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/13 "2018-10-05T19:49:15Z")
> [@guido](#): > > Perhaps the spokesperson should not be a member of the CoE but instead a PSF spokesperson. It depends on the situation though. Sometimes a specific CoE member may indeed be responsible. That seems like a good idea. But I think I would simply judge that as “anonymous”, with a specific implementation. ---
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [October 6, 2018, 9:12pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/14 "2018-10-06T21:12:39Z")
> [@jackjansen](#): > > The intention is not only that the council can assign different weights to different people (the Guido versus Jack example in the PEP) but also that the council can recognise bloc voting (and therefore possibly assign a lower weight to the votes). 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”). > [@jackjansen](#): > > For that latter, think of a group of core developers from a single company voting a certain way, or only people from a specific country/culture/background partaking in some vote. Where does the rule end exactly? You are phrasing this so vaguely that it looks ready to be abused. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 8, 2018, 8:34pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/15 "2018-10-08T20:34:00Z")
> [@pitrou](#): > > 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”). 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. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [October 8, 2018, 10:25pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/16 "2018-10-08T22:25:15Z")
> [@jackjansen](#): > > The proposal definitely wants to keep that option open, i.e. this is at the discretion of the council. The intention is not only that the council can assign different weights to different people (the Guido versus Jack example in the PEP) but also that the council can recognise bloc voting (and therefore possibly assign a lower weight to the votes). 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. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [October 11, 2018, 9:20pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/17 "2018-10-11T21:20:31Z")
> [@vstinner](#): > > 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. 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!”. ---
**Author:** ![dstufft](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/dstufft/32/23_2.png) [@dstufft](https://discuss.python.org/u/dstufft)\ **Post date:** [October 31, 2018, 1:45am UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/18 "2018-10-31T01:45:09Z")
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. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [November 6, 2018, 11:45am UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/19 "2018-11-06T11:45:03Z")
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](https://discuss.python.org/t/comparison-of-the-7-governance-peps/392) 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](https://discuss.python.org/t/maths-on-vote-majority/348) 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](https://www.python.org/dev/peps/pep-8015/#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. ---
**Author:** ![jackjansen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jackjansen/32/30_2.png) [@jackjansen](https://discuss.python.org/u/jackjansen)\ **Post date:** [November 6, 2018, 3:23pm UTC](https://discuss.python.org/t/pep-8014-the-commons-model/173/20 "2018-11-06T15:23:24Z")
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. [Next page](https://discuss.python.org/t/pep-8014-the-commons-model/173.md?page=2)