Key people and their functions

The Council of Auditors (CoA) is a council of varying size, typicallytwo to four people, who are elected for the duration of a Pythonrelease. One member of the CoA is considered the President, who hassome minor points of authority over the other members.

The CoA has responsibility for reviewing controversial decisions inthe form of PEPs written by members of the core development team. TheCoA may choose to accept a PEP exactly as presented, or may requestclarification or changes. These changes may be of any form and for anyreason. This flexibility is intentional, and allows the process tochange over time as different members are elected to the CoA. See thelater sections of this document for examples of the kinds of requeststhat are expected.

The CoA only pronounces on PEPs submitted to python-committers. Thereis no expectation that the CoA follows or participates on any othermailing lists. (Note that this implies that only core developers maysubmit PEPs. Non-core developers may write and discuss proposals onother mailing lists, but without a core developer willing to supportthe proposal by requesting pronouncement, it cannot proceed toacceptance. This is essentially the same as the current system, but ismade explicit here to ensure that members of the CoA are not expectedto deal with proposals that are not supported by at least one coredeveloper.)

The CoA may not delegate authority to individuals who have not beenelected by the core developer team. (One relevant case here is thatthis changes the implementation of the existing BDFL-Delegate system,though without necessarily changing the spirit of that system. See thelater sections, particularly example scenario four, for morediscussion on this point.)

The Release Manager (RM) is also permitted the same ability to requestchanges on any PEPs that specify the release they are responsible for.After feature freeze, the RM retains this responsibility for theirrelease, while the CoA rotates and begins to focus on the subsequentrelease. This is no different from the current process. The processfor selection of a RM is not changed in this proposal.

Core developers are responsible for electing members of the CoA, andhave the ability to call a “vote of no confidence” against a member ofthe CoA. The details of these votes are discussed in a later section.

Where discussions between core developers and members of the CoAappear to be ongoing but unfruitful, the President may step in tooverrule either party. Where the discussion involves the President, itshould be handled using a vote of no confidence.

Members of the CoA may choose to resign at any point. If at least twomembers of the CoA remain, they may request a new election to refillthe group. If only one member remains, the election is triggeredautomatically. (The scenario when the President resigns is describedin a later section.)

The intended balance of power is that the core developers will electmembers of the CoA who reflect the direction and have the trust of thedevelopment team, and also have the ability to remove members who donot honour commitments made prior to election.

Regular decision process

Regular decisions continue to be made as at present.

For the sake of clarity, controversial decisions require a PEP, andany decisions requiring a PEP are considered as controversial.

The CoA may be asked to advise on whether a decision would be bettermade using the controversial decision process, or individual membersof the CoA may volunteer such a suggestion, but the core developmentteam is not bound by this advice.

Controversial decision process

Controversial decisions are always written up as PEPs, following theexisting process. The approver (formerly “BDFL-Delegate”) is alwaysthe CoA, and can no longer be delegated. Note that this does notprevent the CoA from deciding to nominate a core developer to assessthe proposal and provide the CoA with a recommendation, which isessentially the same as the current delegation process.

The CoA will pronounce on PEPs submitted to python-committers with arequest for pronouncement. Any member of the CoA, or the current RM,may request changes to a PEP for any reason, provided they includesome indication of what additional work is required to meet theirexpectations. See later sections for examples of expected reasons.

When all members of the CoA and the RM indicate that they have noconcerns with a PEP, it is formally accepted. When one or more membersof the CoA fail to respond in a reasonable time, the President of theCoA may choose to interpret that as implied approval. Failure of thePresident to respond should be handled using a vote of no confidence.

Election terms

Members of the CoA are elected for the duration of a release. Themembers are elected prior to feature freeze for the previous release,and hold their position until feature freeze for their release.

Members may seek re-election as many times as they like. There are noterm limits. It is up to the core developers to prevent re-election ofthe CoA members where there is consensus that the individual shouldnot serve again.

Election voting process

The election process for each member of the CoA proceeds as follows:

• a nomination email is sent to python-committers
• a seconding email is sent
• the nominee is temporarily added to python-committers for thepurpose of introducing themselves and presenting their position
• voting opens two weeks prior to the scheduled feature freeze of theprevious release
• votes are contributed by modifying a document in a private githubrepository
• each core developer may add +1 votes for as many candidates as theylike
• after seven days, voting closes
• the nominee with the most votes is elected as President of the CoA
• the next three nominees with the most votes and also at least 50%the number of votes received by the President are elected as theother members of the CoA
• where ties need to be resolved, the RM may apply one extra vote fortheir preferred candidates
• accepted nominees remain on python-committers; others are removed

No-confidence voting process

A vote of no confidence proceeds as follows:

• a vote of no confidence email is sent to python-committers, namingthe affected member of the CoA, justifying the nomination, andoptionally listing accepted PEPs that the nominator believes shouldbe reverted
• a seconding email is sent within seven days
• the nominated member of the CoA is allowed seven days to respond,after which the nominator or the seconder may withdraw
• if no nominator or seconder is available, no further action istaken
• voting opens immediately
• each core developer may add a +1 vote (remove the CoA member) ora -1 vote (keep the CoA member) by modifying a document in aprivate github repository
• after seven days, voting closes
• if +1 votes exceed -1 votes, the CoA member is removed frompython-committers and any nominated PEPs are reverted
• if requested by the remaining members of the CoA, or if only onemember of the CoA remains, a new election to replace the removedmember may be held following the usual process.
• in the case of removing the President of the CoA, the candidatewho originally received the second-most votes becomes President

Scenario 1 - The Case of the Vague PEP

Often in the past, initial proposals have lacked sufficient detail tobe implementable by anyone other than the proposer. To avoid this,the CoA should read proposals “fresh” when submitted, and withoutinferring or using any implied context. Then, when an aspect of a PEPis not clear, the CoA can reject the proposal and requestclarifications.

Since the proposal is rejected, it must be modified and resubmitted inorder to be reviewed again. The CoA will determine how much guidanceto provide when rejecting the PEP, as that will affect how many timesit will likely be resubmitted (and hence affect the CoA’s ownworkload). This ensures that the final PEP text stands alone with allrequired information.

Scenario 2 - The Case of the Endless Discussion

From time to time, a discussion between Python contributors may seemto be no longer providing value. For example, when a large number ofemails are repeating points that have already been dealt with, or areactively hostile towards others, there is no point continuing the“discussion”.

When such a discussion is occurring on python-committers as part of arequest for pronouncement, a member of the CoA should simply declarethe thread over by rejecting the proposal. In most known cases,discussion of this sort indicates that not all concerns have beensufficiently addressed in the proposal and the author may need toenhance some sections.

Alternatively, and in the absence of any rejection from the othermembers of the CoA, the President may declare the thread over byaccepting the proposal. Ideally this would occur after directlyconfirming with the rest of the CoA and the RM that there are noconcerns among them.

When such a discussion is occurring on another list, members of theCoA should be viewed as respected voices similar to other coredevelopers (particularly those core developers who are the namedexperts for the subject area). While none have specific authority toend a thread, preemptively stating an intent to block a proposal is auseful way to defuse potentially useless discussions. Members of theCoA who voluntarily follow discussions other than on python-committersare allowed to suggest the proposer withdraw, but can only actuallyapprove or reject a proposal that is formally submitted forpronouncement.

Scenario 3 - The Case of the Unconsidered Users

Some proposals in the past may be written up and submitted forpronouncement without considering the impact on particular groups ofusers. For example, a proposal that affects the dependencies requiredto use Python on various machines may have an adverse impact on someusers, even if many are unaffected due to the dependencies beingtypically available by default.

Where a proposal does not appear to consider all users, the CoA mightchoose to use their judgement and past experience to determine thatmore users are affected by the change than described in the PEP, andrequest that the PEP also address these users. They should identifythe group of users clearly enough that the proposer is able to alsoidentify these users, and either clarify how they were addressed, ormade amendments to the PEP to explicitly address them. (Note that thisdoes not involve evaluating the usefulness of the feature to varioususer groups, but simply whether the PEP indicates that the usefulnessof the feature has been evaluated.)

Where a proposal appears to have used flawed logic or incorrect datato come to a certain conclusion, the CoA might choose to use othersources of information (such as the prior discussion or a submissionfrom other core developers) to request reconsideration of certainpoints. The proposer does not necessarily need to use the exactinformation obtained by the CoA to update their proposal, providedthat whatever amendments they make are satisfactory to the CoA. Forexample, a PEP may indicate that 30% of users would be affected, whilethe CoA may argue that 70% of users are affected. A successfulamendment may include a different but more reliable percentage, or maybe rewritten to no longer depend on the number of affected users.

Scenario 4 - The Case of the Delegated Decision

Some proposals may require review and approval from a specialist inthe area. Historically, these would have been handled by appointing aBDFL-Delegate to make the final decision on the proposal. However, inthis model, the CoA may not delegate the final decision makingprocess. When the CoA believes that a subject matter expert shoulddecide on a particular proposal, the CoA may nominate one or moreindividuals (or accept their self-nomination) to a similar position toa BDFL Delegate. The terms of these expert’s role may be set as theCoA sees fit, though the CoA always retains the final approval.

As a concrete example, assume a proposal is being discussed about anew language feature. Proponents claim that it will make the languageeasier for new developers to learn. Even before an official proposalis made, the CoA may indicate that they will not accept the proposalunless person X approves, since person X has a long history teachingPython and their judgement is trusted. (Note that person X need not bea core developer.)

Having been given this role, person X is able to drive the discussionand quickly focus it on viable alternatives. Eventually, person Xchooses the alternative they are most satisfied with and indicates tothe CoA that they approve. The proposal is submitted as usual, and theCoA reviews and accepts it, factoring in person X’s opinion.