Prefer 'core team' in documentation/ and getting-started/ (#1616)

Co-authored-by: Mariatta <Mariatta@users.noreply.github.com>

Author: hugovk

documentation/translations/coordinating.rst

@@ -106,7 +106,7 @@ We recommend two or three coordinators, though you may begin with one.
 Here are some general suggestions.
 
 -  Coordinator requests are to be public on the `translation mailing list <translation_ml_>`_.
--  If the given language has a native core dev, the core dev has input
+-  If the given language has a native core team member, they have input
    on the coordinator request.
 -  Anyone who wants to become coordinator for their native language and shows
    motivation by translating and building a community will be named

getting-started/getting-help.rst

@@ -5,7 +5,7 @@ Where to get help
 =================
 
 If you are working on Python it is very possible you will come across an issue
-where you need some assistance to solve it (this happens to core developers
+where you need some assistance to solve it (this happens to the core team
 all the time).
 
 Should you require help, there are a :ref:`variety of options available
@@ -42,7 +42,7 @@ Ask #python-dev
 
 If you are comfortable with IRC you can try asking on ``#python-dev`` (on
 the `Libera.Chat`_ network). Typically there are a number of experienced
-developers, ranging from triagers to core developers, who can answer
+contributors, ranging from triagers to the core team, who can answer
 questions about developing for Python.  As with the mailing lists,
 ``#python-dev`` is for questions involving the development *of* Python
 whereas ``#python`` is for questions concerning development *with* Python.
@@ -60,7 +60,7 @@ Core mentorship
 If you are interested in improving Python and contributing to its development,
 but don’t yet feel entirely comfortable with the public channels mentioned
 above, `Python Mentors`_ are here to help you.  Python is fortunate to have a
-community of volunteer core developers willing to mentor anyone wishing to
+community of volunteer core team members willing to mentor anyone wishing to
 contribute code, work on bug fixes or improve documentation.  Everyone is
 welcomed and encouraged to contribute.
 

getting-started/pull-request-lifecycle.rst

@@ -131,7 +131,7 @@ You should have already :ref:`set up your system <setup>`,
    git commit -m '<message>'
    git push origin <branch-name>
 
-  * If a core developer reviewing your PR pushed one or more commits to your
+  * If a core team member reviewing your PR pushed one or more commits to your
     PR branch, then after checking out your branch and before editing, run::
 
      git pull origin <branch-name>  # pull = fetch + merge
@@ -204,7 +204,7 @@ should do to help ensure that your pull request is accepted.
 
 #. **Make sure to follow Python's style guidelines.** For Python code you
    should follow :PEP:`8`, and for C code you should follow :PEP:`7`. If you have
-   one or two discrepancies those can be fixed by the core developer who merges
+   one or two discrepancies those can be fixed by the core team member who merges
    your pull request. But if you have systematic deviations from the style guides
    your pull request will be put on hold until you fix the formatting issues.
 
@@ -324,7 +324,7 @@ Furthermore, the first line should not end in a period.
 
 If this is not enough detail for a commit, a new paragraph(s) can be added
 to explain in proper depth what has happened (detail should be good enough
-that a core developer reading the commit message understands the
+that a core team member reading the commit message understands the
 justification for the change).
 
 Check :ref:`the Git bootcamp <accepting-and-merging-a-pr>` for further
@@ -447,7 +447,7 @@ to ask for someone to review your pull request.
 
 When someone does manage to find the time to look at your pull request
 they will most likely make comments about how it can be improved
-(don't worry, even core developers of Python have their pull requests sent
+(don't worry, even core team members of Python have their pull requests sent
 back to them for changes).  It is then expected that you update your
 pull request to address these comments, and the review process will
 thus iterate until a satisfactory solution has emerged.
@@ -514,11 +514,13 @@ Instead of simply "approving" the pull request, leave comments.  For example:
 #. Look at any failures in CI on the current PR. See :ref:`"Keeping CI green"
    <keeping-ci-green>` below for simple things you can do to help move the PR forward.
 
-Dismissing review from another core developer
----------------------------------------------
+.. _dismissing-review-from-another-core-developer:
 
-A core developer can dismiss another core developer's review if they confirmed
-that the requested changes have been made.  When a core developer has assigned
+Dismissing review from another core team member
+-----------------------------------------------
+
+A core team member can dismiss another team member's review if they confirmed
+that the requested changes have been made.  When a core team member has assigned
 the PR to themselves, then it is a sign that they are actively looking after
 the PR, and their review should not be dismissed.
 
@@ -589,7 +591,7 @@ Python is tricky and we simply cannot accept everyone's contributions.
 But if your pull request is merged it will then go into Python's
 :abbr:`VCS (version control system)` to be released
 with the next feature release of Python. It may also be backported to older
-versions of Python as a bugfix if the core developer doing the merge believes
+versions of Python as a bugfix if the core team member doing the merge believes
 it is warranted.
 
 
@@ -598,7 +600,7 @@ Crediting
 
 Non-trivial contributions are credited in the ``Misc/ACKS`` file (and, most
 often, in a contribution's news entry as well).  You may be
-asked to make these edits on the behalf of the core developer who
+asked to make these edits on the behalf of the core team member who
 accepts your pull request.
 
 .. _issue tracker: https://github.com/python/cpython/issues