Skip to content

Commit

Permalink
Update Operations and process section, and edits
Browse files Browse the repository at this point in the history
  • Loading branch information
@gvanrossum
gvanrossum committed Oct 11, 2023
1 parent 326cb4a commit dc44c79
Showing 1 changed file with 74 additions and 53 deletions.
127 changes: 74 additions & 53 deletions peps/pep-9999.rst
View file
Original file line number Diff line number Diff line change
@@ -1,16 +1,16 @@
PEP: 9999
Title: C API Working Group Process
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>
Discussions-To: https://discuss.python.org/t/pep-731-c-api-working-group-process
Discussions-To: https://discuss.python.org/t/pep-731-c-api-working-group
Status: Draft
Type: Process
Topic: Typing
Created: 11-Oct-2023
Python-Version: 3.13
Post-History: `11-Oct-2023 <https://discuss.python.org/t/pep-731-c-api-working-group-process>`__
Post-History: `11-Oct-2023 <https://discuss.python.org/t/pep-731-c-api-working-group>`__

Abstract
========
Expand All @@ -30,8 +30,9 @@ 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 languages.

The C API Working Group serves at the pleasure of the Python Steering Council.
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
========
Expand All @@ -57,8 +58,8 @@ Auuuuuuuugh!
Motivation
==========

Despite many discussions and in-person meetings at
core developer sprints and Language Summits,
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 limted to:
Expand Down Expand Up @@ -98,57 +99,77 @@ be governed.
Mandate
-------

The C API Working Group's mandate is to ensure that the Python C API is:
The working group's mandate is to ensure that the Python C API is:

* **Blah**: Blah, blah.
* **Blah**: Blah, blah.
* **Blah**: Blah, blah.
* **Useful**: It should provide access to all relevant functionality.
* **Ergonomic**: It should be easy to use.
* **Fair**: It should serve the purposes of a variety of stakeholders.
* **Stable**: It should avoid requiring users to update their code more than necessary.
* **Evolvable**: It should give Python implementers enough freedom to change implementation details.
* **Maintainable**: It should be easy to maintain and extend.

For several of these items, a more comprehensive listing of constraints
can be found in the PEP being drafted by Irit Katriel on the basis of the
`inventory of C API problems <https://github.com/capi-working-group/problems>`__.

The stability requirement is not meant to prevent sweeping C API changes ---
one of the working group's initial tasks is to settle the question of
whether we intend any landmark changes to the C API in the coming five years,
and if so, to select or write a suitable proposal.
However, the working group is required to carefully consider the migration
efforts required of package maintainers and other stakeholders.

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

XXX HIRO TODO XXX
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 would appoint 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 would 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 a not particularly democratic structure
and puts a lot of faith in the working group.
However, the Python community has a long history of success
with not particularly democratic structures!
We believe that self-governance, cycling of membership,
and accountability to the Steering Council will be sufficient
to ensure that the Typing Council 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 council 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 council's decision.

The council would have three members, comprised of prominent community members,
such as Python core developers and maintainers of major type checkers. The members
should include people affiliated with a variety of projects related to type checking,
which may include type checkers, CPython, typeshed, or other projects.

The Steering Council would appoint the initial Typing Council. There is no term
limit for council members. Council members may resign their position at any time.
There is an expectation that at least one person will voluntarily resign from the
Typing Council each year.

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

The Typing Council 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
Typing Council.

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

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

The council should aim for transparency, posting all decisions publicly on
`discuss.python.org <https://discuss.python.org/c/typing/32>`__, with a
rationale if possible. Before making a decision, the council should give
all interested community members a chance to weigh in. There should be at
least a week between the start of a discussion and the council's decision.

Members of the council will be eligible to sponsor PEPs. If this PEP is accepted,
:pep:`1` should be amended to note this fact.
XXX HIRO TODO XXX

Relationship with the Steering Council
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Expand Down Expand Up @@ -202,12 +223,12 @@ Council. However, as support for runtime type checkers is within the remit
of the Council, they should monitor such changes and provide feedback when
appropriate.

XXX
XXX END TODO XXX

Amendments
----------

This PEP serves as a charter for the C API Working Group.
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 would be decided upon
Expand Down

0 comments on commit dc44c79

Please sign in to comment.