python-peps/peps/pep-0731.rst

PEP: 731
Title: C API Working Group Charter
Author: Guido van Rossum <guido@python.org>,
        Petr Viktorin <encukou@gmail.com>,
        Victor Stinner <vstinner@python.org>,
        Steve Dower <steve.dower@python.org>,
        Irit Katriel <irit@python.org>
Discussions-To: https://discuss.python.org/t/pep-731-c-api-working-group-charter/36117
Status: Active
Type: Process
Topic: Governance
Created: 11-Oct-2023
Post-History: `13-Oct-2023 <https://discuss.python.org/t/pep-731-c-api-working-group-charter/36117>`__
Resolution: https://discuss.python.org/t/pep-731-c-api-working-group-charter/36117/12

Abstract
========

This PEP proposes to establish the C API Working Group:
a small committee of Python core developers responsible for
overseeing and coordinating the development and maintenance of the Python C API.

The working group will maintain
documentation, test suites and tooling related to Python's C API.
As delegated by the Steering Council
it is the deciding body for changes to the C API,
from the addition or removal of individual API functions, types, etc.,
to the acceptance of new designs of a more or less radical nature.

The working group's mandate is to represent the interests of all Python users,
but especially all maintainers of code that uses Python's C API,
whether in the context of CPython, using an alternate Python implementation,
or using a binding framework for other programming languages (such as C++ and Rust).

The working group serves at the pleasure of the Python Steering Council.
This document serves as the working group's charter.

Epigraph
========

| KEEPER
| Stop!
  Who would cross the Bridge of Death must answer me these questions three,
  ere the other side he see.

#. What was Python named after?
#. What was Python 2's EOL?
#. What is the optimal strategy to evolve the CPython C API?

| LANCELOT
| Auuuuuuuugh!

Motivation
==========

Despite many discussions and in-person meetings
at core developer sprints and Language Summits,
and a thorough inventory of the problems and stakeholders of the C API,
no consensus has been reached about many contentious issues,
including, but not limited to:

- Conventions for designing new API functions;
- How to deal with compatibility;
- What's the best strategy for handling errors;
- The future of the Stable ABI and the Limited API;
- Whether to switch to a handle-based API convention (and how).

The general feeling is that there are too many stakeholders,
proposals, requirements, constraints, and conventions,
to make progress without having a small trusted group of deciders.

At the 2023 Language Summit in Salt Lake City it was decided to start work on
an `inventory of problems <https://github.com/capi-working-group/problems>`__.
At the 2023 core developer sprint in Brno this work is more or less finished
and after a discussion it appeared that the next step is to establish
a working group to ensure that we're not stymied forever.

The Steering Council has
`indicated <https://github.com/python/steering-council/issues/201#issuecomment-1648848155>`__
its desire to delegate decisions about the C API
to such a working group, anticipating its formal establishment.

Specification
=============

We propose the creation of a new group, the C API Working Group.
This group will be responsible for overseeing and coordinating the development and
maintenance of the Python C API.
It will do this by establishing the principles underpinning the work
and publishing guidelines that the core developers can refer to.

The "operations and process" section below describes
how the working group operates and how it is governed.

Members
-------

The members of the working group are:

- Guido van Rossum
- Petr Viktorin
- Victor Stinner
- Steve Dower
- Irit Katriel


Mandate
-------

The working group's mandate is to ensure that the Python C API
is suitable for all users of and contributors to the API,
without unduly preferencing one group over another.
The working group will identify exemplar stakeholders,
their needs and preferences,
and will determine a plan for meeting these needs equitably and sustainably.
It will oversee execution of the plan.

Operations and process
----------------------

The working group has at least three members,
comprised of prominent Python core developers.
The members should consider the needs of the various stakeholders carefully.

The Steering Council appoints the initial working group.
There is no term limit for working group members.
Working group members may resign their position at any time, for any reason.
There is an expectation that the membership will change over time.

To determine replacements,
nominations will be collected from the core developer community.
Self-nominations are allowed.
The existing working group will then decide the replacement member(s)
from the nominees.
The expectation is that this will be done by fiat,
but the working group can choose a replacement by any means they see fit,
including a vote.

The working group remains accountable to the Steering Council.
At any point, for any reason, the Steering Council could
(publicly or privately) make a specific change
or request a non-specific change to the composition of the working group.

We acknowledge that this is not a particularly democratic structure
and puts a lot of faith in the working group.
However, the Python community has a long history of success
with structures that are not fully democratic!
We believe that self-governance, cycling of membership,
and accountability to the Steering Council will be sufficient
to ensure that the C API workgroup is meeting the needs of the community.

The working group may operate primarily through reviews of GitHub issues and PRs.
Regular meetings are likely not necessary,
but the working group may set up video calls,
a private chat, or whatever other mechanism they decide upon internally.

The working group should aim for transparency,
posting all decisions publicly on
`discuss.python.org <https://discuss.python.org>`__,
with a rationale if possible.
Before making a decision, the working group should give
all interested community members
(as examples of different categories of stakeholders)
a chance to weigh in.
There should be at least a week between the start of a discussion
and the working group's decision.

Relationship with the Steering Council
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Just like today, the Python Steering Council remains responsible
for the overall direction of the Python C API
and continues to decide on PEPs related to the C API,
using the standard PEP review process (community discussion, etc.).
The C API working group provides written opinions and
recommendations to the Steering Council on PEPs related to the C API.

However, the working group can make smaller C API changes directly.
The Steering Council may also choose to delegate decisions on some PEPs
to the working group (exactly as any other PEP delegation).

Amendments
----------

This PEP serves as a charter for the working group.
Changes to its operation can be made either through a new PEP
or through a change to this PEP.
In either case, the change will be decided upon
by the Steering Council after discussion in the community.

Copyright
=========

This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.