From a049c9f4770b99ee636f9186c1e5230470017e87 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Date: Sun, 20 Jul 2025 13:19:21 +0200 Subject: [PATCH] Prefer 'core team' in developer-workflow/ --- developer-workflow/communication-channels.rst | 18 +++++++-------- developer-workflow/development-cycle.rst | 22 +++++++++---------- developer-workflow/psrt.rst | 6 ++--- developer-workflow/stdlib.rst | 16 +++++++------- 4 files changed, 31 insertions(+), 31 deletions(-) diff --git a/developer-workflow/communication-channels.rst b/developer-workflow/communication-channels.rst index e9360d201..9b088b350 100644 --- a/developer-workflow/communication-channels.rst +++ b/developer-workflow/communication-channels.rst @@ -84,10 +84,10 @@ take place in the open forum categories for `PEPs`_ and `Core Development`_ (these are the Discourse equivalents to the python-dev mailing list). All categories are open for users to read and post with the exception of the `Committers`_ category, where posting is restricted to the `CPython -`_ core developers. +`_ core team. The Committers category is often used for announcements and notifications. -It is also the designated venue for the core developer promotion votes. +It is also the designated venue for the core team promotion votes. Tutorials for new users ----------------------- @@ -189,22 +189,22 @@ Discord (private chat server) ============================= For more real-time discussions, the core development team have a private Discord -server available. Core developers, Steering Council members, triagers, and +server available. Core team members, Steering Council members, triagers, and documentarians on the project are eligible to join the server. Joining the Discord server is entirely optional, as all essential communications occur on the mailing lists and Discourse forums. -For core developers, a long lived multiple use invitation link for this server -can be found in the private core developer only section of the Discourse forum. +For core team members, a long-lived multiple-use invitation link for this server +can be found in the private core team only section of the Discourse forum. For triagers and documentarians joining the Discord server, a single use invitation link should be generated and sent to them directly. When first joining the server, new users will only have access to the ``#welcome`` and ``#rules-and-info`` channels. To link their Discord ID with their project -role, core developers may update their Steering Council 🔒 `voter record`_ with +role, core team members may update their Steering Council 🔒 `voter record`_ with their Discord ID before posting in the ``#welcome`` channel to request access -to the rest of the server channels. Triagers, documentarians, and core developers +to the rest of the server channels. Triagers, documentarians, and core team members that would prefer not to add their Discord ID to their Steering Council voter record may instead be vouched for by an existing member of the Discord server. @@ -225,7 +225,7 @@ set a specific `Server Nickname`_ IRC === -Some core developers still participate in the ``#python-dev`` IRC channel on +Some core team members still participate in the ``#python-dev`` IRC channel on ``irc.libera.chat``. This is not a place to ask for help with Python, but to discuss issues related to Python's own development. See also the ``#python-dev-notifs`` channel for bots notifications. @@ -234,7 +234,7 @@ discuss issues related to Python's own development. See also the Blogs ===== -Several core developers are active bloggers and discuss Python's development +Several core team members are active bloggers and discuss Python's development that way. You can find their blogs (and various other developers who use Python) at `Planet Python `__. diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst index d807d74ec..c8b2d5ebf 100644 --- a/developer-workflow/development-cycle.rst +++ b/developer-workflow/development-cycle.rst @@ -4,7 +4,7 @@ Development cycle ================= -The responsibilities of a core developer shift based on what kind of branch of +The responsibilities of a core team member shift based on what kind of branch of Python a developer is working on and what stage the branch is in. To clarify terminology, Python uses a ``major.minor.micro`` nomenclature @@ -142,7 +142,7 @@ Stages ------ Based on what stage the :ref:`in-development ` version of Python -is in, the responsibilities of a core developer change in regards to commits +is in, the responsibilities of a core team member change in regards to commits to the :abbr:`VCS (version control system)`. @@ -159,7 +159,7 @@ avoiding breaking the buildbots). Alpha ^^^^^ -Alpha releases typically serve as a reminder to core developers that they +Alpha releases typically serve as a reminder to the core team that they need to start getting in changes that change semantics or add something to Python as such things should not be added during a Beta_. Otherwise no new restrictions are in place while in alpha. @@ -171,7 +171,7 @@ Beta After a first beta release is published, no new features are accepted. Only bug fixes and improvements to documentation and tests can now be committed. -This is when core developers should concentrate on the task of fixing +This is when the core team should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases. @@ -185,7 +185,7 @@ Release Candidate (RC) ^^^^^^^^^^^^^^^^^^^^^^ A branch preparing for an RC release can only have bugfixes applied that have -been reviewed by other core developers. Generally, these issues must be +been reviewed by other core team members. Generally, these issues must be severe enough (for example, crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point. @@ -196,7 +196,7 @@ changes should be discussed first with the release manager. You **cannot** skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, **everything** requires peer review from -a core developer. +a core team member. .. _final: @@ -316,12 +316,12 @@ including collaborators, access control, integrations, webhooks, and branch protection. For full details of the permission levels see `GitHub's documentation on repository permission levels `_. -Common reasons for this role are: maintenance of Core Developer -Workflow tooling, Release Managers for all :ref:`in-development `, +Common reasons for this role are: maintenance of core +workflow tooling, Release Managers for all :ref:`in-development `, :ref:`maintenance `, and :ref:`security mode ` -releases, and additional Python Core Developers as necessary for redundancy. -Occasional temporary administrator access is acceptable as necessary for Core -Developer workflow projects. +releases, and additional Python core team members as necessary for redundancy. +Occasional temporary administrator access is acceptable as necessary for core +workflow projects. Inactive or unreachable members may be removed with or without notice. Members who no longer necessitate this level of access will be removed with notice. diff --git a/developer-workflow/psrt.rst b/developer-workflow/psrt.rst index f469f68d1..9d9019dbf 100644 --- a/developer-workflow/psrt.rst +++ b/developer-workflow/psrt.rst @@ -31,7 +31,7 @@ If a coordinator can't complete the process for any reason (time obligation, vacation, etc.) they must find a replacement coordinator in the PSRT and reassign the vulnerability report appropriately. -Coordinators are expected to collaborate with other PSRT members and core developers +Coordinators are expected to collaborate with other PSRT and core team members when needed for guidance on whether the report is an actual vulnerability, severity, advisory text, and fixes. @@ -74,7 +74,7 @@ severity, advisory text, and fixes. * The coordinator determines the fix approach and who will provide a fix. Some reporters are willing to provide or collaborate to create a fix, - otherwise relevant core developers can be invited to collaborate by + otherwise relevant core team members can be invited to collaborate by the coordinator. * For **Low** and **Medium** severity vulnerabilities it is acceptable @@ -84,7 +84,7 @@ severity, advisory text, and fixes. * For **High** and **Critical** severity vulnerabilities the fix must be developed privately using GitHub Security Advisories' "Private Forks" feature. - Core developers can be added to the GitHub Security Advisory via "collaborators" + Core team members can be added to the GitHub Security Advisory via "collaborators" to work on the fix together. Once a fix is approved privately and tested, a public issue and pull request can be created with the ``security`` and ``release-blocker`` labels. diff --git a/developer-workflow/stdlib.rst b/developer-workflow/stdlib.rst index 60112d6d3..b683e55e9 100644 --- a/developer-workflow/stdlib.rst +++ b/developer-workflow/stdlib.rst @@ -28,7 +28,7 @@ You have a several options for this: * Search the `issue tracker`_ for discussion related to the proposed addition. This may turn up an issue that explains why the suggestion wasn't accepted. * Open a new thread in the `Ideas Discourse category`_ - to gather feedback directly from the Python core developers and community. + to gather feedback directly from the Python core team and community. * Write a blog post about the code, which may also help gather useful feedback. If you have found general acceptance and usefulness for your code from people, @@ -36,9 +36,9 @@ you can open an issue on the `issue tracker`_ with the code attached as a :ref:`pull request `. If possible, also submit a :ref:`contributor agreement `. -If a core developer decides that your code would be useful to the general +If a core team member decides that your code would be useful to the general Python community, they will then commit your code. If your code is not picked -up by a core developer and committed then please do not take this personally. +up by a core team and committed then please do not take this personally. Through your public sharing of your code in order to gauge community support for it you at least can know that others will come across it who may find it useful. @@ -51,8 +51,8 @@ Adding a new module It must be stated upfront that getting a new module into the stdlib is very difficult. Adding any significant amount of code to the stdlib increases the -burden placed upon core developers. It also means that the module somewhat -becomes "sanctioned" by the core developers as a good way to do something, +burden placed upon the core team. It also means that the module somewhat +becomes "sanctioned" by the core team as a good way to do something, typically leading to the rest of the Python community to using the new module over other available solutions. All of this means that additions to the stdlib are not taken lightly. @@ -76,7 +76,7 @@ that the stdlib consists of. While a new stdlib module does not need to appeal to all users of Python, it should be something that a large portion of the community will find useful. -This makes sure that the developer burden placed upon core developers is worth +This makes sure that the developer burden placed upon the core team is worth it. @@ -108,12 +108,12 @@ infrastructure (that is, the module is no longer directly maintained outside of Python). This prevents a divergence between the code that is included in the stdlib and that which is released outside the stdlib (typically done to provide the module to older versions of Python). It also removes the burden of forcing -core developers to have to redirect bug reports or changes to an external issue +the core team to have to redirect bug reports or changes to an external issue tracker and :abbr:`VCS (version control system)`. Someone involved with the development of the module must promise to help maintain the module in the stdlib for two years. -This not only helps out other core developers by alleviating workload from bug +This not only helps out other core team members by alleviating workload from bug reports that arrive from the first Python release containing the module, but also helps to make sure that the overall design of the module continues to be uniform.