More uniform terminology: patch and changeset #1443 (#1446)

Co-authored-by: Hugo van Kemenade <[email protected]>
Co-authored-by: Ezio Melotti <[email protected]>

Author: 3 people

contrib/code/index.rst

@@ -9,7 +9,7 @@ Code contributions
    |purpose|
 
 * Code setup and building (more complex stuff, delta from basic setup above)
-* More git bootcamp (patches, etc)
+* More Git bootcamp (pull requests, etc)
 * Lifecycle of a code pull request
 * Development workflow (from devguide)
 * Testing and buildbots (from devguide)

core-developers/become-core-developer.rst

@@ -8,7 +8,7 @@ How to become a core developer
 What it takes
 =============
 
-When you have consistently contributed patches which meet quality standards
+When you have consistently made contributions which meet quality standards
 without requiring extensive rewrites prior to being committed,
 you may qualify for commit privileges and become a core developer of Python.
 You must also work well with other core developers (and people in general)

core-developers/committing.rst

@@ -31,11 +31,11 @@ to enter the public source tree. Ask yourself the following questions:
 * **Do the checks on the pull request show that the test suite passes?**
    Make sure that all of the status checks are passing.
 
-* **Is the patch in a good state?**
-   Check :ref:`patch` and :ref:`helptriage` to review what is expected of
-   a patch.
+* **Is the pull request in a good state?**
+   Check :ref:`pull-request-lifecycle` and :ref:`helptriage` to review what
+   is expected of a pull request.
 
-* **Does the patch break backwards-compatibility without a strong reason?**
+* **Does the change break backwards-compatibility without a strong reason?**
    :ref:`Run the entire test suite <runtests>` to make sure that everything
    still passes. If there is a change to the semantics, then there needs to
    be a strong reason, because it will cause some peoples' code to break.
@@ -165,7 +165,7 @@ number since it is part of the file name. You can use
 entry::
 
    Fix warning message when :func:`os.chdir` fails inside
-   :func:`test.support.temp_cwd`. Patch by Chris Jerdonek.
+   :func:`test.support.temp_cwd`. Contributed by Chris Jerdonek.
 
 The inline Sphinx roles like ``:func:`` can be used help readers
 find more information. You can build HTML and verify that the
@@ -182,7 +182,7 @@ As a core developer, you have the ability to push changes to the official
 Python repositories, so you need to be careful with your workflow:
 
 * **You should not push new branches to the main repository.**  You can
-  still use them in the fork that you use for the development of patches.
+  still use them in the fork that you use for your own development.
   You can also push these branches to a separate public repository
   for maintenance work before it is integrated into the main repository.
 

core-developers/motivations.rst

@@ -279,11 +279,11 @@ Goals of this page
 
 The `issue metrics`_ automatically collected by the CPython issue tracker
 strongly suggest that the current core development process is bottlenecked on
-core developer time - this is most clearly indicated in the first metrics graph,
-which shows both the number of open issues and the number of patches awaiting
+core developer time. This is most clearly indicated in the first metrics graph,
+which shows both the number of open issues and the number of pull requests awaiting
 review growing steadily over time, despite CPython being one of the most
 active open source projects in the world. This bottleneck then impacts not only
-resolving open issues and applying submitted patches, but also the process of
+resolving open issues and accepting submitted pull requests, but also the process of
 identifying, nominating and mentoring new core developers.
 
 The core commit statistics monitored by sites like `OpenHub`_ provide a good

core-developers/responsibilities.rst

@@ -7,8 +7,8 @@ Responsibilities
 As contributors to the CPython project, our shared responsibility is to
 collaborate constructively with other contributors, including core developers.
 This responsibility covers all forms of contribution, whether that's submitting
-patches to the implementation or documentation, reviewing other peoples'
-patches, triaging issues on the issue tracker, or discussing design and
+pull requests to the implementation or documentation, reviewing other peoples'
+pull requests, triaging issues on the issue tracker, or discussing design and
 development ideas on the core
 :ref:`communication channels <communication-channels>`.
 
@@ -68,7 +68,7 @@ the ability to license your code means it can be put under the PSF license so
 it can be legally distributed with Python.
 
 This is a very important step! Hopefully you have already submitted a
-contributor agreement if you have been submitting patches. But if you have not
+contributor agreement if you have been submitting pull requests. But if you have not
 done this yet, it is best to do this ASAP, probably before you even do your
 first commit so as to not forget. Also do not forget to enter your GitHub
 username into your details on the issue tracker.

developer-workflow/development-cycle.rst

@@ -118,7 +118,7 @@ Commits to security branches are to be coordinated with the release manager
 for the corresponding feature version, as listed in the :ref:`branchstatus`.
 Merging of pull requests to security branches is restricted to release managers.
 Any release made from a security branch is source-only and done only when actual
-security patches have been applied to the branch. These releases have a
+security fixes have been applied to the branch. These releases have a
 **micro version** number greater than the last **bugfix** release.
 
 .. _eolbranch:
@@ -151,8 +151,8 @@ Pre-alpha
 
 The branch is in this stage when no official release has been done since
 the latest final release.  There are no special restrictions placed on
-commits, although the usual advice applies (getting patches reviewed, avoiding
-breaking the buildbots).
+commits, although the usual advice applies (getting pull requests reviewed,
+avoiding breaking the buildbots).
 
 .. _alpha:
 

developer-workflow/psrt.rst

@@ -68,24 +68,24 @@ severity, advisory text, and fixes.
   * Affected components and APIs. The module, function, class, or method must be specified so users can
     search their codebase for usage. For issues affecting the entire project, this can be omitted.
 
-  * Mitigations for the vulnerability beyond upgrading to a patched version, if applicable.
+  * Mitigations for the vulnerability beyond upgrading to a fixed version, if applicable.
 
   This can all be done within the GitHub Security Advisory UI for easier collaboration between reporter and coordinator.
 
-* The coordinator determines the fix approach and who will provide a patch.
-  Some reporters are willing to provide or collaborate to create a patch,
+* 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
   the coordinator.
 
   * For **Low** and **Medium** severity vulnerabilities it is acceptable
-    to develop a patch in public.
+    to develop a fix in public.
     The pull request must be marked with the ``security`` and ``release-blocker``
-    labels so that a release is not created without including the patch.
+    labels so that a release is not created without including the fix.
 
-  * For **High** and **Critical** severity vulnerabilities the patch must be
+  * 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"
-    to work on the fix together. Once a patch is approved privately and tested,
+    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

@@ -36,7 +36,7 @@ You have a several options for this:
 
 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 <patch>`. If possible, also submit 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
@@ -91,7 +91,7 @@ In order for a module to even be considered for inclusion into the stdlib, a
 couple of requirements must be met.
 
 The most basic is that the code must meet
-:ref:`standard patch requirements <patch>`. For code that has
+:ref:`standard pull request requirements <pullrequest>`. For code that has
 been developed outside the stdlib typically this means making sure the coding
 style guides are followed and that the proper tests have been written.
 
@@ -112,7 +112,7 @@ 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 patches to an external issue
+core developers 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

getting-started/fixing-issues.rst

@@ -6,7 +6,7 @@ Fixing "easy" issues (and beyond)
 =================================
 
 When you feel comfortable enough to want to help tackle issues by trying to
-create a patch to fix an issue, you can start by looking at the `"easy"
+create a pull request to fix an issue, you can start by looking at the `"easy"
 issues`_. These issues *should* be ones where it should take no longer than a
 day or weekend to fix. But because the "easy" classification is typically done
 at triage time it can turn out to be inaccurate, so do feel free to leave a
@@ -17,8 +17,8 @@ are not considered easy and try to fix those. It must be warned, though, that
 it is quite possible that a bug that has been left open has been left into that
 state because of the difficulty compared to the benefit of the fix. It could
 also still be open because no consensus has been reached on how to fix the
-issue (although having a patch that proposes a fix can turn the tides of the
-discussion to help bring it to a close). Regardless of why the issue is open,
+issue, although having a pull request that proposes a fix can turn the tides of the
+discussion to help bring it to a close. Regardless of why the issue is open,
 you can also always provide useful comments if you do attempt a fix, successful
 or not.
 

getting-started/git-boot-camp.rst

@@ -132,7 +132,7 @@ Enabling ``autocrlf`` on Windows
 
 The ``autocrlf`` option will fix automatically any Windows-specific line endings.
 This should be enabled on Windows, since the public repository has a hook which
-will reject all changesets having the wrong line endings::
+will reject all commits having the wrong line endings::
 
     $ git config --global core.autocrlf input
 
@@ -356,7 +356,7 @@ Scenario:
   the upstream CPython repository.
 
 Please do not try to solve this by creating a pull request from
-``python:main`` to ``<username>:main`` as the authors of the patches will
+``python:main`` to ``<username>:main`` as the authors of the pull requests will
 get notified unnecessarily.
 
 Solution::
@@ -435,8 +435,8 @@ Solution:
 
 .. _git_pr:
 
-Downloading other's patches
----------------------------
+Checking out others' pull requests
+----------------------------------
 
 Scenario: