PEP 731: C API Working Group Charter (python#3476)

(Co-authored by all listed co-authors, and also by Jelle, since we cribbed a lot of words from his PEP 729.)

.github/CODEOWNERS

@@ -608,6 +608,7 @@ peps/pep-0726.rst  @AA-Turner
 peps/pep-0727.rst  @JelleZijlstra
 peps/pep-0729.rst  @JelleZijlstra @hauntsaninja
 peps/pep-0730.rst  @ned-deily
+peps/pep-0731.rst  @gvanrossum @encukou @vstinner @zooba @iritkatriel
 # ...
 # peps/pep-0754.rst
 # ...

peps/pep-0731.rst

@@ -0,0 +1,181 @@
+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>
+Status: Draft
+Type: Process
+Created: 11-Oct-2023
+Python-Version: 3.13
+
+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.
+The working group's members are the listed authors of this PEP.
+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.
+
+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.