The Council of Auditors (CoA) is a council of varying size, typically two to four people, who are elected for the duration of a Python release. One member of the CoA is considered the President, who has some minor points of authority over the other members.
The CoA has responsibility for reviewing controversial decisions in the form of PEPs written by members of the core development team. The CoA may choose to accept a PEP exactly as presented, or may request clarification or changes. These changes may be of any form and for any reason. This flexibility is intentional, and allows the process to change over time as different members are elected to the CoA. See the later sections of this document for examples of the kinds of requests that are expected.
The CoA only pronounces on PEPs submitted to python-committers. There is no expectation that the CoA follows or participates on any other mailing lists. (Note that this implies that only core developers may submit PEPs. Non-core developers may write and discuss proposals on other mailing lists, but without a core developer willing to support the proposal by requesting pronouncement, it cannot proceed to acceptance. This is essentially the same as the current system, but is made explicit here to ensure that members of the CoA are not expected to deal with proposals that are not supported by at least one core developer.)
The CoA may not delegate authority to individuals who have not been elected by the core developer team. (One relevant case here is that this changes the implementation of the existing BDFL-Delegate system, though without necessarily changing the spirit of that system. See the later sections, particularly example scenario four, for more discussion on this point.)
The Release Manager (RM) is also permitted the same ability to request changes on any PEPs that specify the release they are responsible for. After feature freeze, the RM retains this responsibility for their release, while the CoA rotates and begins to focus on the subsequent release. This is no different from the current process. The process for selection of a RM is not changed in this proposal.
Core developers are responsible for electing members of the CoA, and have the ability to call a “vote of no confidence” against a member of the CoA. The details of these votes are discussed in a later section.
Where discussions between core developers and members of the CoA appear to be ongoing but unfruitful, the President may step in to overrule either party. Where the discussion involves the President, it should be handled using a vote of no confidence.
Members of the CoA may choose to resign at any point. If at least two members of the CoA remain, they may request a new election to refill the group. If only one member remains, the election is triggered automatically. (The scenario when the President resigns is described in a later section.)
The intended balance of power is that the core developers will elect members of the CoA who reflect the direction and have the trust of the development team, and also have the ability to remove members who do not honour commitments made prior to election.
Regular decisions continue to be made as at present.
For the sake of clarity, controversial decisions require a PEP, and any decisions requiring a PEP are considered as controversial.
The CoA may be asked to advise on whether a decision would be better made using the controversial decision process, or individual members of the CoA may volunteer such a suggestion, but the core development team is not bound by this advice.
Controversial decisions are always written up as PEPs, following the existing process. The approver (formerly “BDFL-Delegate”) is always the CoA, and can no longer be delegated. Note that this does not prevent the CoA from deciding to nominate a core developer to assess the proposal and provide the CoA with a recommendation, which is essentially the same as the current delegation process.
The CoA will pronounce on PEPs submitted to python-committers with a request for pronouncement. Any member of the CoA, or the current RM, may request changes to a PEP for any reason, provided they include some indication of what additional work is required to meet their expectations. See later sections for examples of expected reasons.
When all members of the CoA and the RM indicate that they have no concerns with a PEP, it is formally accepted. When one or more members of the CoA fail to respond in a reasonable time, the President of the CoA may choose to interpret that as implied approval. Failure of the President to respond should be handled using a vote of no confidence.