# PEP 8012: The Community Model **URL:** \ **Category:** Committers\ **Tags:** governance\ **Created:** [October 3, 2018, 1:13am UTC](https://discuss.python.org/t/pep-8012-the-community-model/156 "2018-10-03T01:13:58Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 3, 2018, 1:13am UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/1 "2018-10-03T01:13:59Z")
PEP: 8012 Title: The Community Governance Model Author: Łukasz Langa [lukasz@python.org](mailto:lukasz@python.org) Status: Active Type: Informational Content-Type: text/x-rst Created: 2018-10-03 # Abstract This PEP proposes a new model of Python governance based on consensus and voting by the Python community. This model relies on workgroups to carry out the governance of the Python language. This governance model works without the role of a centralized singular leader or a governing council. It describes how, when, and why votes are conducted for decisions affecting the Python language. It also describes the criteria for voting eligibility. Should this model be adopted, it will be codified in PEP 13. This model can be affectionately called “The Least Worst Governance Model” by its property that while far from ideal, it’s still the most robust one compared to the others. Since avoiding issues inherent to the other models is a paramount feature of the Community Governance Model, we start the discussion a bit unusually: by rejecting the other models. # Rejected Models ## Let’s have another BDFL This seems like a very attractive idea because it’s a model we know. One Dictator to rule us all. #### Challenge: There is no other Guido There is no other single person with the unique skillset of Guido van Rossum. Such a person would need to have the technical, communication, and organizational experience to lead the project successfully. Specifically, the person would need to: - set and articulate a cohesive long-term vision for the project; - possess deep technical understanding of the runtime, the standard library, and the wider third-party library context; - negotiate and resolve contentious issues in ways acceptable to all parties involved; - have free time and possess the energy to sustain continuous involvement over periods of years. #### Risk: Malevolent Dictator For Life What if we got somebody who is not as well suited for the position as our first Dictator? There are possible scenarios in which this could lead to severe consequences. The Dictator could gather insufficient trust due to missing technical depth, a “close” election, inconsistent vision, poor ability to deal with conflict or burnout, and so on. Given a controversial decision decided by the Dictator in a specific way, a Dictator with insufficient trust may cause a split within the project. The Dictator setup invites lobbying concentrated on a single person. Unless that person is immune to leverage due to wealth, health, and a stable life situation, this poses risk of malicious actors steering the project from behind the curtain. Finally, the Dictator coming from a particular part of the community may put more weight on the needs and interests of that particular part of the user base, alienating others. #### Observation: We don’t actually need a Dictator The irony of the Dictator model is that it requires an election. Better yet, we need an election to even decide on which governance model to use. If we are already able solve two problems of this gravity via the community process, why not keep using it for all subsequent decisions? #### Risk: The warm and fuzzy feeling of a vague proposal One last thing worth mentioning is that when a BDFL model is suggested, it’s easy to bypass the criticism above by not mentioning _who_ the BDFL should be. That way the hopeful reader can project their best expectations and wants onto the abstract BDFL, making the idea appear more attractive. This is a mistake. Without naming the BDFL in the model proposal we are not talking about a concrete model. We can avoid asking and answering the hard questions. We can imagine our best-case scenario, a candidate we’d like to serve the role. Omitting a name for the BDFL also puts the Community Model at an unfair disadvantage. We already know the good, the bad, and the ugly of our core developer group. It’s no platonic ideal, no perfect sphere with no friction. In fact, we expect there to be a fair amount of friction and imperfections. Thus, to fairly assess the BDFL model proposal, dear reader, you should imagine the worst possible person within our team as that BDFL. A concrete human being. Imagine it’s me. **Conclusion** While this has been our history, without Guido, this model does not serve the best interests of the language into the future. ## Let’s have a Council This group of people roughly shares the responsibilities of a Dictator. The group can also be called a Triumvirate, a Quorum, Elders, Steering Committee, and so on. #### Risk: Dilution and confusion This model favors a small group, between three to five people. That way it shares most of the criticism with the Dictator model, amplified. Having not one but, say, three people in position of power dilutes responsibility while still providing high risk of lobbying, insufficient trust, or alienating parts of the community. #### Risk: Internal Conflict Additionally, having multiple people share the responsibility of governance creates ample opportunity for internal conflict, inconsistent long-term vision of the project, and multiplies the required continuous time involvement by its members (it’s no Quorum if they can’t “reach quorum” due to other time commitments). Just like with a frictionless spherical BDFL, reject ideas of Councils without considering how would it work for you if that Council consisted of three people you find inadequate for the role. Imagine if I had two friends. Most importantly, just like with a Dictator, we don’t need a Council. By the time we had one, we would have already had two successful elections. Why not keep voting? **Conclusion** This model has similar risks like a Dictator, only worse. # Motivation Now that we rejected the basics of other governance models, let’s talk why we even need a governance model on top of a loosely defined group of committers. **Stability and Reliability** We want to prevent single committers from making wide-reaching changes that impact the future of the language or its usability. Coherent vision and backwards compatibility are important in any programming language, but they are doubly important for Python which is very dynamic (e.g. has very complex backwards compatibility implications). **Diverse Uses of Python** Moreover, Python is used by a diverse group of users, from school children through scientists to corporations with multi-million line codebases. We want to include all our varied audiences. **Vitality** We want to avoid stagnation. Python is a mature project but it needs to keep evolving to stay relevant, both the runtime and the programming language. To do that, people interested in improving a particular part of the project should be able to do so without needless friction. But for substantial changes, we want some discourse and reflection to ensure the changes are wise. # Rationale **Inclusive** The Community Model is the most inclusive model. No single person or a small group of people is in a distiguished position of power over others. Contributors and any workgroups in this model are self-selecting. **Pragmatic** This model ensures no user group is put at a disadvantage due to the interests of a single person or a small group of people. **Proven** This model works. There is a number of large open-source projects run this way (two of which, Rust and Django, are described in PEP 8002). ECMAScript and C++ are similarly developed. # Specification ## Key people and their functions #### The core team The Python project is developed by a team of core developers. While membership is determined by presence in the “Python core” team in the “python” organization on GitHub, contribution takes many forms: - committing changes to the repository; - reviewing pull requests by others; - triaging bug reports on the issue tracker; - discussing topics on official Python communication channels. Some contributors are may be considered dormant, in other words they did not contribute to the last two releases of CPython. Any dormant contributor can at any time resume contribution. #### Experts The Python Developer’s Guide lists a number of interest areas along with names of core developers who are recognized as experts in the given area. An expert or a sub-team of experts has the following responsibilities: - responding to issues on the bug tracker triaged to the given interest area on a timely basis; - reviewing pull requests identified as belonging to the given interest area on a timely basis; - overviewing cohesive design in the evolution of the given interest area. A core developer can assign and unassign themselves at will to a given interest area. Existing experts listed for the given interest area must be made aware of this change and have to unanimously agree to it. If a given interest area lists multiple experts, they form a sub-team within the core team. They are responsible for the given interest area together. A core developer should avoid membership as an expert in too many interest areas at the same time. This document deliberately doesn’t specify a maximum number, it simply signals that overexertion leads to burnout and is a risk to the project’s ability to function without a given contributor. #### Moderators There is a group of people, some of which are not core developers, responsible for ensuring that discussions on official communication channels adhere to the Code of Conduct. They take action in view of violations. ## Regular decision process Primary work happens through bug tracker issues and pull requests. Core developers should avoind pushing their changes directly to the cpython repository, instead relying on pull requests. Approving a pull request by a core developer allows it to be merged without further process. Notifying relevant experts about a bug tracker issue or a pull request is important. Reviews from experts in the given interest area are strongly preferred, especially on pull request approvals. Failure to do so might end up with the change being reverted by the relevant expert. Experts are not required to listen to the firehose of GitHub and bug tracker activity at all times. Notifying an expert explicitly during triage or bug/pull request creation may be necessary to get their attention. ## Controversial decision process Substantial changes in a given interest area require a PEP. This includes: - Any semantic or syntactic change to the language. - Backwards-incompatible changes to the standard library or the C API. - Additions to the standard library, including substantial new functionality within an existing library. - Removing language, standard library, or C API features. Failure to get a substantial change through the PEP process might result with the change being reverted. Changes that are bug fixes can be exempt from the PEP requirement. Use your best judgement. #### PEP, Enhanced The PEP process is augmented with the following changes and clarifications over information already present in PEP 1: - PEPs are not merged until the final decision is made on them; they are open pull requests on GitHub until that moment; - a submitted PEP needs to identify the area of interest and relevant experts as the body that makes the final decision on it; - if the PEP author is one of the experts of the relevant area of interest, they must name another person from outside of that interest area to contribute to the final decision in their place; - the PEP author is responsible for gathering and integrating feedback on the PEP using the official communication channels, with the goal of building consensus; - all community members must be enabled to give feedback; - at some point, one of the named experts posts a “summary comment” that lays out the current state of discussion, especially major points of disagreement and tradeoffs; at the same time the expert proposes a “motion for final comment period” ( **FCP** ), along with a proposed disposition to either: - to enter the FCP, the PEP must be signed off by all experts of the relevant area of interest; - the FCP lasts for fourteen calendar days to allow stakeholders to file any final objections before a decision is reached. #### Very controversial PEPs If a core contributor feels strongly against a particular PEP, during its FCP they may raise a motion to reject it by vote. Voting details are described below in “Voting Mechanics”. This should be a last resort and thus a rare occurrence. It splits the core team and is a stressful event for all involved. However, the experts filing for a FCP for a PEP should have a good sense whether a motion to reject it by vote is likely. In such a case, care should be taken to avoid prematurely filing for a FCP. There is no recourse for the opposite situation, i.e. when the experts want to reject a PEP but others would like it accepted. This ensures that the relevant experts have the last say on what goes in. If you really want that change, find a way to convince them. Moderators on official communication channels enforce the Code of Conduct first and foremost, to ensure healthy interaction between all interested parties. Enforcement can result in a given participant being excluded from further discussion and thus the decision process. #### Revisiting deferred and rejected PEPs If a PEP is deferred or rejected, the relevant experts should be contacted first before another attempt at the same idea is made. If the experts agree there is substantial evidence to justify revisiting the idea, a pull request editing the deferred or rejected PEP can be opened. Failure to get proper expert buy-in beforehand will likely result in immediate rejection of a pull request on a deferred or rejected PEP. ## Other Voting Situations #### Nominating a new core developer A champion nominates a person to become a new core developer by posting on official communication channels. A vote is opened. If any existing core developer does not feel comfortable with the nominee receiving the commit bit, they should preferably address this concern in the nomination thread. If there is no satisfactory resolution, they can cast a negative vote. In practice, nominating a person for a core developer should often meet with surprise by others that this person is not a core developer yet. In other words, it should be done when the candidate is already known and trusted well enough by others. We should avoid nominations based on _potential_. #### Votes of no confidence - Removing a core developer from the core team; - Disbanding the experts team for a given area of interest. Those describe a situation where a core developer is forcefully removed from the core team or an experts team is forcefully disbanded. Hopefully those will never have to be exercised but they are explicitly mentioned to demonstrate how a dysfunctional area of interest can be healed. If a core developer is removed by vote from the core team, they lose the ability to interact with the project. It’s up to the Moderators’ discretion to remove their ability to post on the bug tracker and GitHub or just moderate their future behavior on a case-by-case basis. If the experts team for an area of interest is disbanded, other core developers can step up to fill the void at will. Members of the disbanded experts team cannot self-nominate to return. ## Voting Mechanics All votes described in this document are +1/-1/0 (“Yea”/“Nay”/“Present”) recorded votes. There are no other vote values, in particular values out of range or fractions (like +0.5) are invalid. Votes take fourteen calendar days. The starting date is taken looking at the timezone of the person who filed for the motion to vote. The end date is fourteen days later Anywhere-On-Earth. Dormant core developers as defined in “Key people and their functions” above are not counted towards the totals if they abstain. However, they can vote if they choose to do so and that way they count as active. Voting is a form of contribution. Voting is done by a commit to a private repository in the “python” organization on GitHub. The repository is archived and publicized after the voting period is over. The repository’s name should start with “vote-”. Changes to one’s vote during the voting period is allowed. Peeking at other developers’ cast votes during the time of the vote is possible. Every situation requires a different vote percentage: - PEP rejection by vote requires over 1/3rd of the non-dormant core developer population to explicitly vote to reject. Note that if more than 1/3rd of core developers decide against a PEP, this means there exists no super-majority of core developers who are in favor of the change. This strongly suggests the change should not be made in the shape described by the PEP. - New core developer nomination requires there to be no votes cast against it. - Votes of no confidence require a super-majority of at least 2/3rds of the non-dormant core developer population to explicitly vote in favor of the motion. # Omissions This document deliberately omits listing possible areas of interest within the project. It also does not address election and management of Moderators which are done by the Python Software Foundation and its Code of Conduct Working Group which can be contacted by mailing [conduct-wg@python.org](mailto:conduct-wg@python.org). # Acknowledgements Thank you to the authors of PEP 8002 which was a helpful resource in shaping this document. Thank you to Alex Crichton and the Rust team for a governance model that was a major inspiration for this document. # 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:** ![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 3, 2018, 5:48pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/2 "2018-10-03T17:48:23Z")
> [@ambv](#): > > Without naming the BDFL in the model proposal we are not talking about > a concrete model. We can avoid asking and answering the hard questions. > We can imagine our best-case scenario, a candidate we’d like to serve > the role. Agreed with this. > [@ambv](#): > > This group of people roughly sharing the responsibilities of a Dictator > can also be called a Triumvirate, a Quorum, Elders, Steering Committee, > and so on. I don’t know how the Council PEP(s) will look like, but it’s not necessarily how you say. A Council may not have the full responsibilities and powers of a Dictator. For example, if you look at the Astropy Coordination Committee (cutely named CoCo) in [PEP 8002](https://www.python.org/dev/peps/pep-8002/#astropy), it’s clearly more of a supervision and tie-breaking body over a mostly democratic community. **Experts** I think the part about experts is a bit weak, as it doesn’t address two common problems: 1. Some experts may be dormant; how does unanimity function then? 2. Some listed topics may not have any experts currently (or any non-dormant experts). Should said topics stagnate? How would a new expert be admitted in that situation? **PEPs** > PEPs are not merged until the final decision is made on them; they are open pull requests on GitHub until that moment; This is more of a technical detail, but when writing the PEP, I like the idea of having a fully rendered form somewhere under [PEP 0 – Index of Python Enhancement Proposals (PEPs) | peps.python.org](https://www.python.org/dev/peps/), which I can re-read myself or ask third-party members to review (rather than have them read Github’s formatted output in my PR). Also it helps ensure that PEP numbers don’t conflict 😉 > if the PEP author is one of the experts of the relevant area of > interest, they must name another person from outside of that interest > area to contribute to the final decision in their place; So this seems like the PEP-delegate process, only that the PEP author always decides? It would rather have an informal consensus-based decision where the PEP author (but it may be another core developer) proposes the name of a delegate on a communication channel (python-dev? or Discourse if we switch…) and after X days, that person is heralded PEP-delegate if no other core developer objected. > - to enter the FCP, the PEP must be signed off by all experts of the > relevant area of interest; Again, there is a problem if one of them is dormant. ---
**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 3, 2018, 6:35pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/3 "2018-10-03T18:35:53Z")
Thanks @ambv. The community will need a spokesperson for various communications tasks (interviews, etc.). Will this be something that would be voted upon? I could see there being a fair number of press requests after a governance model is accepted, and I’m wondering who will field those questions so we are not sending mixed messages to the greater Python community. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 3, 2018, 11:08pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/4 "2018-10-03T23:08:31Z")
@pitrou, you raise excellent points around experts. I will think some more about the question of vacancy and dormancy and give some suggestions as soon as I think I have something that is both fair and workable. Also feel free to share your thoughts on the matter. > [@willingc](#): > > The community will need a spokesperson for various communications tasks (interviews, etc.). Will this be something that would be voted upon? Agreed! This is a prominent role and the interviews might set some tone, consciously or not, around some design aspects, philosophy, and so on. Therefore, I am inclined to think that the President of the Python Software Foundation or somebody equally prominentshould be a spokesperson. Of course, in this particular situation I think the President happens to be our ex-Dictator which could potentially be unpleasant to him as it would skew the interviews to be more about the past than the future. I don’t know. It would sound self-serving from me to mention that the release manager of the next version of Python sounds like a good candidate for this… so I won’t suggest that 😉 There is one missing piece of the PEP that I want to address but somehow failed to find a good place for so far. It would address your concern around “coherent vision” too, and thus maybe dial down the need for a singular spokesperson. It’s around making Python core values more explicit. What are our design goals, where do we want to go. Maybe PEP 20 could be that but it doesn’t address some important aspects of Python: being usable out of the box (“batteries included”), being dynamic and introspectable (“we are all consenting adults”, “duck typing”), and so on. I feel like codifying such slogans that summarize design values is very imporant in a distributed model like the PEP specifies. There is value in having core values exposed so that broad ideas can be evaluated against them. Maybe I can somehow convince @tim.one to write a sequel to the Zen, let’s call it the Python Manifesto. ---
**Author:** ![jackdied](https://avatars.discourse-cdn.com/v4/letter/j/b9e5f3/32.png) [@jackdied](https://discuss.python.org/u/jackdied)\ **Post date:** [October 4, 2018, 1:45am UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/5 "2018-10-04T01:45:25Z")
> [@ambv](#): > > New core developer nomination requires there to be no votes cast > against it. “Blackball” does not work outside of very small organizations. Most voters will have had very few interactions with any newly proposed core-dev so they will be working with a very limited data set. We would hope that they would trust the champion who proposed the person for core-dev status (and has interacted with them many times) but you can’t guarantee that. You’ll find that there is one person, or a small group of people, that are responsible for _all_ of the blackballs. I’m OK with requiring a super-majority of the votes, but allowing one person to jam up the works assures that sooner or later you will have one person who jams up the works. ---
**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 4, 2018, 12:58pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/6 "2018-10-04T12:58:01Z")
One other thing that isn’t addressed in the PEP is how the moderators get chosen and which rules they follow. Since it seems there is an expectation for higher moderation in the future, we need to formalize how it works. We can’t really continue with a tiny team of self-appointed moderators, frequently overworked or emotionally exhausted, following no written rules. ---
**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 4, 2018, 1:25pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/7 "2018-10-04T13:25:44Z")
> [@pitrou](#): > > One other thing that isn’t addressed in the PEP is how the moderators get chosen and which rules they follow. I doubt that will be addressed in any of the proposals. It’s probably going to be worth splitting it out and working with the PSF or the CoC group to come up with a process for this. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 4, 2018, 1:26pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/8 "2018-10-04T13:26:29Z")
Agreed with Steve. I will add this to Omissions. ☑️ done in Revision 3 here and [a python/peps commit](https://github.com/python/peps/commit/873b4435a2328c091cfbec3d6c5b1320bc33406f) ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 4, 2018, 3:02pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/9 "2018-10-04T15:02:28Z")
> [@jackdied](#): > > You’ll find that there is one person, or a small group of people, that are responsible for _all_ of the blackballs. Has this been your experience so far? Where would those hypothetical people with trust issues come from? In such case where somebody is clearly abusing their vote without credible reason, there’s recourse: you can talk to them. If that fails and the situation is dire, the last resort is a vote of no confidence for the offender. But as I communicated through my questions above, I find it extremely unlikely somebody would unreasonably obstruct growing the team. > [@jackdied](#): > > “Blackball” does not work outside of very small organizations. Most voters will have had very few interactions with any newly proposed core-dev so they will be working with a very limited data set. We would hope that they would trust the champion who proposed the person for core-dev status (and has interacted with them many times) but you can’t guarantee that. We _are_ a small organization, with 93 members on GitHub. Until now most of us indeed assume that the champion knows what they are talking about. There is little push-back. However, if any of us feels uncomfortable with a new person joining, this is strong signal to revisit the nomination. The way the votes are done, there’s 14 days to convince the blackballer to change their mind. I think this is a rather critical piece of this PEP as experts assign themselves to areas of interest at will. Also, sub-PEP changes are much less scrutinized. Without trust this entire setup needs to be changed. ☑ I made it more explicit in Revision 4 and [this commit to python/peps](https://github.com/python/peps/commit/8bcad514587c9b3e06252b3b6eec2737541135fd) the intent behind blackball in new core developer nominations. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 4, 2018, 3:34pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/10 "2018-10-04T15:34:34Z")
> [@pitrou](#): > > I don’t know how the Council PEP(s) will look like, but it’s not necessarily how you say. Right, I will revise when I see the other Council-based PEPs, so far the only available one is PEP 8014 where indeed the “Council of Elders” is said to only be responsible for ensuring the outcome of a vote represents the will of the community. @jackjansen can speak more to clarify but I find it more in a shape of an idea rather than a concrete proposal. @jackjansen, would you mind starting a topic in Committers so we could discuss? Either just link the PEP from python/peps or paste the contents inline. In the former case it’s easier to maintain a source of truth for the content (it’s in the repo) but in the latter case it’s easier for people to comment on particular pieces of the proposal (as you can see in this topic). ---
**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:41pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/11 "2018-10-04T17:41:34Z")
There are a lot of similarities between PEP8012 and PEP8014, and a couple of differences. Enough similarities that I think we should examine these similarities and differences, and see whether the two can be merged, or whether one clearly has more support than the other so that we can retire one of the two. Similarities: - Both are against a new BDFL - Both are against a multi-person-bdfl-replacement - Both place ultimate decision power with “the community” - Both are vague on who “the community” is, what changes are “substantial” and how “the vote” is taken - Both Differences: - PEP8014 has its _Council of Elders_ with the specific role of overseeing the voting process - PEP8014 is explicit in its vagueness on community/voting/gravity of a decision, and puts the decision power on these (but _only_ on these) explicitly on the Council of Elders. - PEP8012 has more details on voting mechanics, which PEP8014 explicitly wants to leave to the CoE. - PEP8014 has a list of drawbacks on hard voting models (specifically the fear that it may lead to aspiring core developers not being accepted because of potential conflict of interest) Editorial differences, which I think could be added to the other PEP easily : - PEP8012 has an explicit list of rejected models (8014 could share these) - PEP8014 has an explicit list of BDFL/Guido tasks not handled by the proposal ---
**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:43pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/12 "2018-10-04T17:43:33Z")
I’ll try to start a new topic (but no guarantees that I’ll succeed:-) ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [October 5, 2018, 10:56pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/13 "2018-10-05T22:56:51Z")
> [@ambv](#): > > If the experts team for an area of interest is disbanded, other core > developers can step up to fill the void at will. Members of the > disbanded experts team cannot self-nominate to return. So I take this to mean that once the experts are dissolved then others are free to volunteer to fill in the void? And once new volunteers are in place they can then decide unanimously to bring in select members of the previous group? ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [October 5, 2018, 11:09pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/14 "2018-10-05T23:09:41Z")
> [@ambv](#): > > a submitted PEP needs to identify the area of interest and relevant > experts as the body that makes the final decision on it Taking PEP 572 as an example, who would have been the experts for such a syntactic language change? In such instances like this or any other one where there is no clear expert team would it fall to all core devs and a majority or super-majority would be required for the PEP to be accepted? ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 5, 2018, 11:11pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/15 "2018-10-05T23:11:19Z")
> [@brettcannon](#): > > So I take this to mean that once the experts are dissolved then others are free to volunteer to fill in the void? And once new volunteers are in place they can then decide unanimously to bring in select members of the previous group? Yes, exactly right. This way you incentivize the experts team to work it out before it gets so bad that they get disbanded. But allows reforming of essentially the same group if they so choose… which could game the system somewhat but frankly I’m not overly worried about such scenario. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 5, 2018, 11:29pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/16 "2018-10-05T23:29:07Z")
> [@brettcannon](#): > > who would have been the experts for such a syntactic language change? I suspect we will grow a “language grammar” team for this purpose. It could grow to be larger than the others but I don’t think too many people would want all the work that comes with being on a team. I am already listing the expectation of timely basis for response and code review. I need to make that more explicit. As I say in the document, for a PEP to enter FCP, all team members need to sign off on it. In other words, the team has to be unanimous about the change being ready. Otherwise it doesn’t get past the “summary comment”. Remember I’m stating that all community members need to be enabled to comment on the proposal so those voices should appear in the summary comment. This means you don’t have to be on the respective team to be able to influence the process. Now, before I comment on PEP 572, I’d like to make clear I make no specific judgment here on whether it’s a good feature to have. I am discussing the consensus for it, which we did not achieve as a community. Without further ado, in case of PEP 572 specifically, the experts would probably not be unanimous on this one. And even if they were, due to the rather substantial general commiter and community backlash for the proposal, they would need to take into account a potential PEP rejection by vote. Since it’s a heavy hammer, they would probably not risk it. With PEP 8012 in place, we are unlikely to have another outlier like PEP 572 accepted. ---
**Author:** ![ambv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ambv/32/25884_2.png) [@ambv](https://discuss.python.org/u/ambv)\ **Post date:** [October 5, 2018, 11:49pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/17 "2018-10-05T23:49:26Z")
Some more thoughts: - I think it makes sense to expect every core developer to have at least 1 area of interest; - I am still trying to come up with a good way to balance the expectation of timely contribution to your team’s area of interest with not ostracizing contributors with less time. I want the model to be inclusive but I need it to not be paralyzed by “occasional” contributors. - I will spend some time on Monday figuring out which parts we could share with @jackjansen and whether it’s feasible to merge the two without killing them both. ---
**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 6, 2018, 1:03pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/18 "2018-10-06T13:03:59Z")
> [@ambv](#): > > will spend some time on Monday figuring out which parts we could share with @jackjansen and whether it’s feasible to merge the two without killing them both My feeling now (but that could change again:-) is that sharing is a good idea, but merging isn’t. Both proposals put decision power with the community, but they take different angles at how to make that manageable that I think it’s worthwhile to keep separate proposals. 8012 addresses manageability by having subcommittees of experts, with each subcommittee usually being trusted for their specific area that they can decide. Each individual decision is then normally handled by the responsible subcommittee. 8014 addresses manageability by having the council of elders oversee the voting process, and deciding (based on the councils collective knowledge of python, the proposal and the community) whether the subset of the community that bothered to vote is representative for this specific proposal. ---
**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:16pm UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/19 "2018-10-06T21:16:58Z")
I think for now PEP 8012 and 8014 are different enough, especially since PEP 8014 gives ample powers to its Council of Elders. ---
**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 8, 2018, 10:19am UTC](https://discuss.python.org/t/pep-8012-the-community-model/156/20 "2018-10-08T10:19:05Z")
@ambv I’ve left a PR on your PEP. Not in the PR but I feel as if the proposal should flesh out the workgroups concept a bit more. Perhaps naming a few standing workgroups (ones that we expect to have) would be helpful. It may also be helpful to state that workgroups can be formed for specific time-bounded/project-bounded efforts (i.e. improvement/migration for bpo). [Next page](https://discuss.python.org/t/pep-8012-the-community-model/156.md?page=2)