Prefer 'core team' in developer-workflow/ (#1615)

Author: hugovk

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
-<https://github.com/python/cpython>`_ core developers.
+<https://github.com/python/cpython>`_ 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 <https://planetpython.org/>`__.
 

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 <indevbranch>` 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
 <https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles>`_.
-Common reasons for this role are: maintenance of Core Developer
-Workflow tooling, Release Managers for all :ref:`in-development <indevbranch>`,
+Common reasons for this role are: maintenance of core
+workflow tooling, Release Managers for all :ref:`in-development <indevbranch>`,
 :ref:`maintenance <maintbranch>`, and :ref:`security mode <secbranch>`
-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.

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.

developer-workflow/stdlib.rst

@@ -28,17 +28,17 @@ 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,
 you can open an issue on the `issue tracker`_ with the code attached as a
 :ref:`pull request <pullrequest>`. If possible, also submit a
 :ref:`contributor agreement <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.