From 4d10225a61e325825b4de7eeccbff89e2c3d4f9c Mon Sep 17 00:00:00 2001
From: Baptiste Mispelon <bmispelon@gmail.com>
Date: Wed, 6 Nov 2024 22:19:17 +0100
Subject: [PATCH] Fixed #35894 -- renamed patch to pull request

---
 .github/pull_request_template.md              |  2 +-
 .github/workflows/new_contributor_pr.yml      |  4 +-
 CONTRIBUTING.rst                              |  8 +-
 docs/internals/_images/triage_process.svg     |  2 +-
 .../contributing/bugs-and-features.txt        |  2 +-
 .../contributing/committing-code.txt          |  7 +-
 docs/internals/contributing/localizing.txt    |  6 +-
 .../contributing/new-contributors.txt         | 57 ++++++-------
 .../contributing/triaging-tickets.txt         | 84 +++++++++----------
 .../writing-code/coding-style.txt             |  4 +-
 .../contributing/writing-code/index.txt       |  2 +-
 ...bmitting-patches.txt => pull-requests.txt} | 48 ++++++-----
 .../writing-code/working-with-git.txt         | 12 +--
 docs/internals/git.txt                        |  2 +-
 docs/internals/release-process.txt            |  2 +-
 docs/intro/contributing.txt                   | 10 +--
 16 files changed, 127 insertions(+), 125 deletions(-)
 rename docs/internals/contributing/writing-code/{submitting-patches.txt => pull-requests.txt} (92%)

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 6c43c1c99adc..dfa9384c8616 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -9,7 +9,7 @@ Provide a concise overview of the issue or rationale behind the proposed changes
 #### Checklist
 - [ ] This PR targets the `main` branch. <!-- Backports will be evaluated and done by mergers, when necessary. -->
 - [ ] The commit message is written in past tense, mentions the ticket number, and ends with a period.
-- [ ] I have checked the "Has patch" ticket flag in the Trac system.
+- [ ] I have checked the "Has pull request" ticket flag in the Trac system.
 - [ ] I have added or updated relevant tests.
 - [ ] I have added or updated relevant docs, including release notes if applicable.
 - [ ] I have attached screenshots in both light and dark modes for any UI changes.
diff --git a/.github/workflows/new_contributor_pr.yml b/.github/workflows/new_contributor_pr.yml
index 3e0119ebdc2f..36b5936aed37 100644
--- a/.github/workflows/new_contributor_pr.yml
+++ b/.github/workflows/new_contributor_pr.yml
@@ -18,9 +18,9 @@ jobs:
           pr-message: |
             Hello! Thank you for your contribution 💪
 
-            As it's your first contribution be sure to check out the [patch review checklist](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist).
+            As it's your first contribution be sure to check out the [pull request review checklist](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/pull-requests/#contribution-checklist).
 
-            If you're fixing a ticket [from Trac](https://code.djangoproject.com/) make sure to set the _"Has patch"_ flag and include a link to this PR in the ticket!
+            If you're fixing a ticket [from Trac](https://code.djangoproject.com/) make sure to set the _"Has pull request"_ flag and include a link to this PR in the ticket!
 
             If you have any design or process questions then you can ask in the [Django forum](https://forum.djangoproject.com/c/internals/5).
 
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 4b2ab363660d..f27b0acbc807 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -6,9 +6,9 @@ As an open source project, Django welcomes contributions of many forms.
 
 Examples of contributions include:
 
-* Code patches
+* Pull requests
 * Documentation improvements
-* Bug reports and patch reviews
+* Bug reports and code reviews
 
 Extensive contribution guidelines are available in the repository at
 ``docs/internals/contributing/``, or online at:
@@ -20,10 +20,6 @@ Trac tickets will be closed!** `Please file a ticket`__ to suggest changes.
 
 __ https://code.djangoproject.com/newticket
 
-Django uses Trac to keep track of bugs, feature requests, and associated
-patches because GitHub doesn't provide adequate tooling for its community.
-Patches can be submitted as pull requests, but if you don't file a ticket,
-it's unlikely that we'll notice your contribution.
 
 Code of Conduct
 ===============
diff --git a/docs/internals/_images/triage_process.svg b/docs/internals/_images/triage_process.svg
index 6fbf1cbcc7f2..9babf2f4e8a4 100644
--- a/docs/internals/_images/triage_process.svg
+++ b/docs/internals/_images/triage_process.svg
@@ -264,7 +264,7 @@
         <rect x="72" y="522" width="342" height="36" fill="white"/>
         <path d="M 414 558 L 72 558 L 72 522 L 414 522 Z" stroke="#595959" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="4.0,4.0" stroke-width="1"/>
         <text transform="translate(76 526)" fill="#595959">
-          <tspan font-family="Helvetica" font-size="12" fill="#595959" x="7.241211" y="11">The ticket has a patch which applies cleanly and includes all </tspan>
+          <tspan font-family="Helvetica" font-size="12" fill="#595959" x="7.241211" y="11">The ticket has a pull request which includes all </tspan>
           <tspan font-family="Helvetica" font-size="12" fill="#595959" x="26.591797" y="25">needed tests and docs. A merger can commit it as is.</tspan>
         </text>
       </g>
diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt
index c59f79e6b871..73d3e39c4073 100644
--- a/docs/internals/contributing/bugs-and-features.txt
+++ b/docs/internals/contributing/bugs-and-features.txt
@@ -71,7 +71,7 @@ are a few additional guidelines to follow:
   capturing a *brief* screencast. If your software permits it, capture only
   the relevant area of the screen.
 
-* If you're offering a patch that changes the look or behavior of Django's
+* If you're proposing a change that changes the look or behavior of Django's
   UI, you **must** attach before *and* after screenshots/screencasts.
   Tickets lacking these are difficult for triagers to assess quickly.
 
diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 91c6d21beb56..f6f4711436c9 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -11,8 +11,7 @@ contribute code to Django, look at :doc:`writing-code/working-with-git` instead.
 Handling pull requests
 ======================
 
-Since Django is hosted on GitHub, patches are provided in the form of pull
-requests.
+Django is hosted on GitHub and uses pull requests (PRs) for contributions.
 
 When committing a pull request, make sure each individual commit matches the
 commit guidelines described below. Contributors are expected to provide the
@@ -74,7 +73,7 @@ line.
 When rewriting the commit history of a pull request, the goal is to make
 Django's commit history as usable as possible:
 
-* If a patch contains back-and-forth commits, then rewrite those into one.
+* If a PR contains back-and-forth commits, then rewrite those into one.
   For example, if a commit adds some code and a second commit fixes stylistic
   issues introduced in the first commit, those commits should be squashed
   before merging.
@@ -89,7 +88,7 @@ Django's commit history as usable as possible:
 * Tests should pass and docs should build after each commit. Neither the
   tests nor the docs should emit warnings.
 
-* Trivial and small patches usually are best done in one commit. Medium to
+* Trivial and small changes usually are best done in one commit. Medium to
   large work may be split into multiple commits if it makes sense.
 
 Practicality beats purity, so it is up to each merger to decide how much
diff --git a/docs/internals/contributing/localizing.txt b/docs/internals/contributing/localizing.txt
index 112a74dd9e2a..4d9f848daa01 100644
--- a/docs/internals/contributing/localizing.txt
+++ b/docs/internals/contributing/localizing.txt
@@ -61,12 +61,12 @@ the date, time and numbers formatting particularities of your locale. See
 The format files aren't managed by the use of Transifex. To change them, you
 must:
 
-* :doc:`Create a pull request<writing-code/submitting-patches>` against the
+* :doc:`Create a pull request<writing-code/pull-requests>` against the
   Django Git ``main`` branch, as for any code change.
 
 * Open a ticket in Django's ticket system, set its ``Component`` field to
-  ``Translations``, set the "has patch" flag, and include the link to the pull
-  request.
+  ``Translations``, set the "has pull request" flag, and include the link to
+  the pull request.
 
 .. _Transifex: https://www.transifex.com/
 .. _Django project page: https://app.transifex.com/django/django/
diff --git a/docs/internals/contributing/new-contributors.txt b/docs/internals/contributing/new-contributors.txt
index c728abccd6ca..d126b8a6751a 100644
--- a/docs/internals/contributing/new-contributors.txt
+++ b/docs/internals/contributing/new-contributors.txt
@@ -27,39 +27,39 @@ Triage tickets
 If an `unreviewed ticket`_ reports a bug, try and reproduce it. If you can
 reproduce it and it seems valid, make a note that you confirmed the bug and
 accept the ticket. Make sure the ticket is filed under the correct component
-area. Consider writing a patch that adds a test for the bug's behavior, even if
-you don't fix the bug itself. See more at :ref:`how-can-i-help-with-triaging`
+area. Consider writing a test for the bug's behavior, even if you don't fix the
+bug itself. See more at :ref:`how-can-i-help-with-triaging`
 
-Review patches of accepted tickets
-----------------------------------
+Review pull requests of accepted tickets
+----------------------------------------
 
 This will help you build familiarity with the codebase and processes. Mark the
-appropriate flags if a patch needs docs or tests. Look through the changes a
-patch makes, and keep an eye out for syntax that is incompatible with older but
-still supported versions of Python. :doc:`Run the tests
+appropriate flags if a pull request needs docs or tests. Look through the
+files changed in the PR, and keep an eye out for syntax that is incompatible
+with older but still supported versions of Python. :doc:`Run the tests
 </internals/contributing/writing-code/unit-tests>` and make sure they pass.
 Where possible and relevant, try them out on a database other than SQLite.
 Leave comments and feedback!
 
-Keep old patches up-to-date
----------------------------
+Keep old pull requests up-to-date
+---------------------------------
 
-Oftentimes the codebase will change between a patch being submitted and the
-time it gets reviewed. Make sure it still applies cleanly and functions as
-expected. Updating a patch is both useful and important! See more on
-:doc:`writing-code/submitting-patches`.
+Oftentimes the codebase will change between a pull request being submitted and
+the time it gets reviewed. Make sure there are no merge conflicts and that the
+code still functions as expected. Updating a pull request is both useful and
+important! See more on :doc:`writing-code/pull-requests`.
 
 Write some documentation
 ------------------------
 
 Django's documentation is great but it can always be improved. Did you find a
 typo? Do you think that something should be clarified? Go ahead and suggest a
-documentation patch! See also the guide on :doc:`writing-documentation`.
+documentation pull request! See also the guide on :doc:`writing-documentation`.
 
 .. note::
 
   The `reports page`_ contains links to many useful Trac queries, including
-  several that are useful for triaging tickets and reviewing patches as
+  several that are useful for triaging tickets and reviewing pull requests as
   suggested above.
 
   .. _reports page: https://code.djangoproject.com/wiki/Reports
@@ -118,7 +118,7 @@ Be bold! Leave feedback!
 ------------------------
 
 Sometimes it can be scary to put your opinion out to the world and say "this
-ticket is correct" or "this patch needs work", but it's the only way the
+ticket is correct" or "this pull request needs work", but it's the only way the
 project moves forward. The contributions of the broad Django community
 ultimately have a much greater impact than that of any one person. We can't do
 it without **you**!
@@ -141,25 +141,26 @@ wayside ends up doing more harm than good.
 Be rigorous
 -----------
 
-When we say ":pep:`8`, and must have docs and tests", we mean it. If a patch
-doesn't have docs and tests, there had better be a good reason. Arguments like
-"I couldn't find any existing tests of this feature" don't carry much weight.
-While it may be true, that means you have the extra-important job of writing
-the very first tests for that feature, not that you get a pass from writing
-tests altogether.
+When we say ":pep:`8`, and must have docs and tests", we mean it. If a pull
+request doesn't have docs and tests, there had better be a good reason.
+Arguments like "I couldn't find any existing tests of this feature" don't carry
+much weight. While it may be true, that means you have the extra-important job
+of writing the very first tests for that feature, not that you get a pass from
+writing tests altogether.
 
 Be patient
 ----------
 
-It's not always easy for your ticket or your patch to be reviewed quickly. This
-isn't personal. There are a lot of tickets and pull requests to get through.
+It's not always easy for your ticket or pull request to be reviewed quickly.
+This isn't personal. There are a lot of tickets and pull requests to get
+through.
 
-Keeping your patch up to date is important. Review the ticket on Trac to ensure
-that the *Needs tests*, *Needs documentation*, and *Patch needs improvement*
-flags are unchecked once you've addressed all review comments.
+Keeping your pull request up to date is important. Review the ticket on Trac to
+ensure that the *Needs tests*, *Needs documentation*, and *Pull request needs
+improvement* flags are unchecked once you've addressed all review comments.
 
 Remember that Django has an eight-month release cycle, so there's plenty of
-time for your patch to be reviewed.
+time for your contribution to be reviewed.
 
 Finally, a well-timed reminder can help. See :ref:`contributing code FAQ
 <new-contributors-faq>` for ideas here.
diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index 7987d63e9a61..5e43ba27d410 100644
--- a/docs/internals/contributing/triaging-tickets.txt
+++ b/docs/internals/contributing/triaging-tickets.txt
@@ -36,7 +36,7 @@ Triage workflow
 Unfortunately, not all bug reports and feature requests in the ticket tracker
 provide all the :doc:`required details<bugs-and-features>`. A number of
 tickets have proposed solutions, but those don't necessarily meet all the
-requirements :ref:`adhering to the guidelines for contributing <patch-style>`.
+requirements :ref:`adhering to the guidelines for contributing <contribution-style>`.
 
 One way to help out is to *triage* tickets that have been created by other
 users.
@@ -70,17 +70,17 @@ By way of example, here we see the lifecycle of an average ticket:
   incorrect implementation).
 
 * Bob reviews the pull request, marks the ticket as "Accepted", "needs tests",
-  and "patch needs improvement", and leaves a comment telling Alice how the
-  patch could be improved.
+  and "pull request needs improvement", and leaves a comment telling Alice how
+  the pull request could be improved.
 
 * Alice updates the pull request, adding tests (but not changing the
   implementation). She removes the two flags.
 
-* Charlie reviews the pull request and resets the "patch needs improvement"
-  flag with another comment about improving the implementation.
+* Charlie reviews the pull request and resets the "pull request needs
+  improvement" flag with another comment about improving the implementation.
 
 * Alice updates the pull request, fixing the implementation. She removes the
-  "patch needs improvement" flag.
+  "pull request needs improvement" flag.
 
 * Daisy reviews the pull request and marks the ticket as "Ready for checkin".
 
@@ -114,39 +114,40 @@ Beyond that there are several considerations:
 
 * **Accepted + No Flags**
 
-  The ticket is valid, but no one has submitted a patch for it yet. Often this
-  means you could safely start writing a fix for it. This is generally more
-  true for the case of accepted bugs than accepted features. A ticket for a bug
-  that has been accepted means that the issue has been verified by at least one
-  triager as a legitimate bug - and should probably be fixed if possible. An
-  accepted new feature may only mean that one triager thought the feature would
-  be good to have, but this alone does not represent a consensus view or imply
-  with any certainty that a patch will be accepted for that feature. Seek more
-  feedback before writing an extensive contribution if you are in doubt.
+  The ticket is valid, but no one has submitted a pull request for it yet.
+  Often this means you could safely start writing a fix for it. This is
+  generally more true for the case of accepted bugs than accepted features. A
+  ticket for a bug that has been accepted means that the issue has been
+  verified by at least one triager as a legitimate bug - and should probably be
+  fixed if possible. An accepted new feature may only mean that one triager
+  thought the feature would be good to have, but this alone does not represent
+  a consensus view or imply with any certainty that a pull request will be
+  accepted for that feature. Seek more feedback before writing an extensive
+  contribution if you are in doubt.
 
-* **Accepted + Has Patch**
+* **Accepted + Has Pull Request**
 
   The ticket is waiting for people to review the supplied solution. This means
-  downloading the patch and trying it out, verifying that it contains tests
-  and docs, running the test suite with the included patch, and leaving
-  feedback on the ticket.
+  checking out the pull request and trying it out, verifying that it contains
+  tests and docs, checking that all the automated tests on the pull request are
+  passing, and leaving feedback on the ticket.
 
-* **Accepted + Has Patch + Needs ...**
+* **Accepted + Has Pull Request + Needs ...**
 
   This means the ticket has been reviewed, and has been found to need further
-  work. "Needs tests" and "Needs documentation" are self-explanatory. "Patch
-  needs improvement" will generally be accompanied by a comment on the ticket
-  explaining what is needed to improve the code.
+  work. "Needs tests" and "Needs documentation" are self-explanatory. "Pull
+  request needs improvement" will generally be accompanied by a comment on the
+  ticket explaining what is needed to improve the code.
 
 Ready For Checkin
 -----------------
 
 The ticket was reviewed by any member of the community other than the person
-who supplied the patch and found to meet all the requirements for a
+who submitted the pull request and found to meet all the requirements for a
 commit-ready contribution. A :ref:`merger <mergers-team>` now needs to give
 a final review prior to being committed.
 
-There are a lot of pull requests. It can take a while for your patch to get
+There are a lot of pull requests. It can take a while for yours to get
 reviewed. See the :ref:`contributing code FAQ<new-contributors-faq>` for some
 ideas here.
 
@@ -158,44 +159,43 @@ high-level ideas or long-term feature requests.
 
 These tickets are uncommon and overall less useful since they don't describe
 concrete actionable issues. They are enhancement requests that we might
-consider adding someday to the framework if an excellent patch is submitted.
-They are not a high priority.
+consider adding someday to the framework if an excellent contribution is
+submitted. They are not a high priority.
 
 Other triage attributes
 =======================
 
 A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
 
-Has patch
----------
+Has pull request
+----------------
 
 This means the ticket has an associated solution. These will be reviewed to
 ensure they adhere to the :doc:`documented guidelines
-<writing-code/submitting-patches>`.
+<writing-code/pull-requests>`.
 
 The following three fields (Needs documentation, Needs tests,
-Patch needs improvement) apply only if a patch has been supplied.
+Pull request needs improvement) apply only if a pull request has been supplied.
 
 Needs documentation
 -------------------
 
-This flag is used for tickets with patches that need associated
+This flag is used for tickets with pull requests that need associated
 documentation. Complete documentation of features is a prerequisite
 before we can check them into the codebase.
 
 Needs tests
 -----------
 
-This flags the patch as needing associated unit tests. Again, this
+This flags the pull request as needing associated unit tests. Again, this
 is a required part of a valid contribution.
 
-Patch needs improvement
------------------------
+Pull request needs improvement
+------------------------------
 
 This flag means that although the ticket *has* a solution, it's not quite
-ready for checkin. This could mean the patch no longer applies
-cleanly, there is a flaw in the implementation, or that the code
-doesn't meet our standards.
+ready for checkin. This could mean the pull request has merge conflicts, there
+is a flaw in the implementation, or that the code doesn't meet our standards.
 
 Easy pickings
 -------------
@@ -296,7 +296,7 @@ If you do close a ticket, you should always make sure of the following:
 A ticket can be resolved in a number of ways:
 
 * fixed
-      Used once a patch has been rolled into Django and the issue is fixed.
+      Used once a pull request has been merged and the issue is fixed.
 
 * invalid
       Used if the ticket is found to be incorrect. This means that the
@@ -356,7 +356,7 @@ Then, you can help out by:
   sparse to be actionable, or when they're feature requests requiring a
   discussion on the `Django Forum`_ or |django-developers|.
 
-* Correcting the "Needs tests", "Needs documentation", or "Has patch"
+* Correcting the "Needs tests", "Needs documentation", or "Has pull request"
   flags for tickets where they are incorrectly set.
 
 * Setting the "`Easy pickings`_" flag for tickets that are small and
@@ -377,7 +377,7 @@ Then, you can help out by:
 * Verify if solutions submitted by others are correct. If they are correct
   and also contain appropriate documentation and tests then move them to the
   "Ready for Checkin" stage. If they are not correct then leave a comment to
-  explain why and set the corresponding flags ("Patch needs improvement",
+  explain why and set the corresponding flags ("Pull request needs improvement",
   "Needs tests" etc.).
 
 .. note::
@@ -396,7 +396,7 @@ the ticket database:
 * Please **don't** promote your own tickets to "Ready for checkin". You
   may mark other people's tickets that you've reviewed as "Ready for
   checkin", but you should get at minimum one other community member to
-  review a patch that you submit.
+  review a pull request that you submit.
 
 * Please **don't** reverse a decision without posting a message to the
   `Django Forum`_ or |django-developers| to find consensus.
diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index 20605aef5684..b5e29c5cfd63 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -489,7 +489,7 @@ Miscellaneous
   silence the flake8 warning.
 
 * Systematically remove all trailing whitespaces from your code as those
-  add unnecessary bytes, add visual clutter to the patches and can also
+  add unnecessary bytes, add visual clutter to the pull request and can also
   occasionally cause unnecessary merge conflicts. Some IDE's can be
   configured to automatically remove them and most VCS tools can be set to
   highlight them in diff outputs.
@@ -497,7 +497,7 @@ Miscellaneous
 * Please don't put your name in the code you contribute. Our policy is to
   keep contributors' names in the ``AUTHORS`` file distributed with Django
   -- not scattered throughout the codebase itself. Feel free to include a
-  change to the ``AUTHORS`` file in your patch if you make more than a
+  change to the ``AUTHORS`` file in your pull request if you make more than a
   single trivial change.
 
 JavaScript style
diff --git a/docs/internals/contributing/writing-code/index.txt b/docs/internals/contributing/writing-code/index.txt
index 72cc26452460..7b09972a35bd 100644
--- a/docs/internals/contributing/writing-code/index.txt
+++ b/docs/internals/contributing/writing-code/index.txt
@@ -25,7 +25,7 @@ our documentation also contains useful guidance on specific topics:
 .. toctree::
    :maxdepth: 1
 
-   How to submit a patch to Django for new and/or fixed behavior <submitting-patches>
+   How to submit a pull request to Django for new and/or fixed behavior <pull-requests>
    How to write and run tests </topics/testing/overview>
    How to run Django's unit tests <unit-tests>
    How to work with Git and GitHub <working-with-git>
diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/pull-requests.txt
similarity index 92%
rename from docs/internals/contributing/writing-code/submitting-patches.txt
rename to docs/internals/contributing/writing-code/pull-requests.txt
index c3d0e1745f29..7968394b315a 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/pull-requests.txt
@@ -12,8 +12,8 @@ Typo fixes and trivial documentation changes
 ============================================
 
 If you are fixing a really trivial issue, for example changing a word in the
-documentation, the preferred way to provide the patch is using GitHub pull
-requests without a Trac ticket.
+documentation, the preferred way is to open a pull request on GitHub without a
+Trac ticket.
 
 See the :doc:`working-with-git` for more details on how to use pull requests.
 
@@ -98,6 +98,8 @@ hoops of claiming tickets. Submit your changes directly and you're done!
 It is *always* acceptable, regardless whether someone has claimed it or not, to
 link proposals to a ticket if you happen to have the changes ready.
 
+.. TODO: link
+
 .. _patch-style:
 
 Contribution style
@@ -112,7 +114,7 @@ requirements:
   fixed and to prevent the problem from arising again. Also, if some tickets
   are relevant to the code that you've written, mention the ticket numbers in
   some comments in the test so that one can easily trace back the relevant
-  discussions after your patch gets committed, and the tickets get closed.
+  discussions after your pull request gets merged, and the tickets get closed.
 
 * If the code adds a new feature, or modifies the behavior of an existing
   feature, the change should also contain documentation.
@@ -133,13 +135,15 @@ Trac. When using this style, follow these guidelines.
 
 Regardless of the way you submit your work, follow these steps.
 
+.. TODO: link
+
 * Make sure your code fulfills the requirements in our :ref:`contribution
   checklist <patch-review-checklist>`.
 
-* Check the "Has patch" box on the ticket and make sure the "Needs
-  documentation", "Needs tests", and "Patch needs improvement" boxes aren't
-  checked. This makes the ticket appear in the "Patches needing review" queue
-  on the `Development dashboard`_.
+* Check the "Has pull request" box on the ticket and make sure the "Needs
+  documentation", "Needs tests", and "Pull request needs improvement" boxes
+  aren't checked. This makes the ticket appear in the "Pull requests needing
+  review" queue on the `Development dashboard`_.
 
 .. _ticket tracker: https://code.djangoproject.com/
 .. _Development dashboard: https://dashboard.djangoproject.com/
@@ -147,7 +151,7 @@ Regardless of the way you submit your work, follow these steps.
 Contributions which require community feedback
 ==============================================
 
-A wider community discussion is required when a patch introduces new Django
+A wider community discussion is required when a change introduces new Django
 functionality and makes some sort of design decision. This is especially
 important if the approach involves a :ref:`deprecation <deprecating-a-feature>`
 or introduces breaking changes.
@@ -306,14 +310,16 @@ In each :term:`feature release <Feature release>`, all
 JavaScript contributions
 ========================
 
+.. TODO: link/ref
+
 For information on JavaScript contributions, see the :ref:`javascript-patches`
 documentation.
 
-Optimization patches
+Optimization changes
 ====================
 
-Patches aiming to deliver a performance improvement should provide benchmarks
-showing the before and after impact of the patch and sharing the commands for
+Changes aiming to deliver a performance improvement should provide benchmarks
+showing the before and after impact of the change and sharing the commands for
 reviewers to reproduce.
 
 .. _django-asv-benchmarks:
@@ -327,8 +333,6 @@ benchmarks can be run on a pull request by labeling the pull request with
 
 .. _django-asv: https://github.com/django/django-asv/
 
-.. _patch-review-checklist:
-
 Contribution checklist
 ======================
 
@@ -340,21 +344,23 @@ If the pull request passes all the criteria below and is not your own, please
 set the "Triage Stage" on the corresponding Trac ticket to "Ready for checkin".
 If you've left comments for improvement on the pull request, please tick the
 appropriate flags on the Trac ticket based on the results of your review:
-"Patch needs improvement", "Needs documentation", and/or "Needs tests". As time
-and interest permits, mergers do final reviews of "Ready for checkin" tickets
-and will either commit the changes or bump it back to "Accepted" if further
-work needs to be done.
+"Pull request needs improvement", "Needs documentation", and/or "Needs tests".
+As time and interest permits, mergers do final reviews of "Ready for checkin"
+tickets and will either commit the changes or bump it back to "Accepted" if
+further work needs to be done.
 
 If you're looking to become a member of the `triage & review team
 <https://www.djangoproject.com/foundation/teams/#triage-review-team>`_, doing
 thorough reviews of contributions is a great way to earn trust.
 
-Looking for a patch to review? Check out the "Patches needing review" section
-of the `Django Development Dashboard <https://dashboard.djangoproject.com/>`_.
+Looking for a pull request to review? Check out the "Pull requests needing
+review" section of the `Django Development Dashboard`_.
 
 Looking to get your pull request reviewed? Ensure the Trac flags on the ticket
 are set so that the ticket appears in that queue.
 
+.. _Django Development Dashboard: https://dashboard.djangoproject.com/
+
 Documentation
 -------------
 
@@ -405,8 +411,8 @@ All tickets
 
 * Is the pull request a single squashed commit with a message that follows our
   :ref:`commit message format <committing-guidelines>`?
-* Are you the patch author and a new contributor? Please add yourself to the
-  :source:`AUTHORS` file and submit a `Contributor License Agreement`_.
+* Are you the pull request author and a new contributor? Please add yourself to
+  the :source:`AUTHORS` file and submit a `Contributor License Agreement`_.
 * Does this have an accepted ticket on Trac? All contributions require a ticket
   unless the :ref:`change is considered trivial <trivial-change>`.
 
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index 579543f8767f..d4e7d3bcae70 100644
--- a/docs/internals/contributing/writing-code/working-with-git.txt
+++ b/docs/internals/contributing/writing-code/working-with-git.txt
@@ -281,12 +281,12 @@ Your pull request should now contain the new commit too.
 Note that the merger is likely to squash the review commit into the previous
 commit when committing the code.
 
-Working on a patch
-==================
+Working on a pull request
+=========================
 
-One of the ways that developers can contribute to Django is by reviewing
-patches. Those patches will typically exist as pull requests on GitHub and
-can be easily integrated into your local repository:
+One of the ways that developers can contribute to Django is by reviewing pull
+requests on GitHub. Those pull requests can be easily integrated into your
+local repository:
 
 .. code-block:: shell
 
@@ -295,7 +295,7 @@ can be easily integrated into your local repository:
 
 This will create a new branch and then apply the changes from the pull request
 to it. At this point you can run the tests or do anything else you need to
-do to investigate the quality of the patch.
+do to investigate the quality of the pull request.
 
 For more detail on working with pull requests see the
 :ref:`guidelines for mergers <handling-pull-requests>`.
diff --git a/docs/internals/git.txt b/docs/internals/git.txt
index 7329fe0bbcbc..0814e3718af2 100644
--- a/docs/internals/git.txt
+++ b/docs/internals/git.txt
@@ -80,7 +80,7 @@ If you're going to be working on Django's code (say, to fix a bug or
 develop a new feature), you can probably stop reading here and move
 over to :doc:`the documentation for contributing to Django
 </internals/contributing/index>`, which covers things like the preferred
-coding style and how to generate and submit a patch.
+coding style and how to generate and submit a pull request.
 
 Stable branches
 ===============
diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index a845faf33070..b6170c86ae48 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -131,7 +131,7 @@ page for the current state of support for each version.
 * The current development branch ``main`` will get new features and bug fixes
   requiring non-trivial refactoring.
 
-* Patches applied to the main branch must also be applied to the last feature
+* Commits from the main branch must also be included in the last feature
   release branch, to be released in the next patch release of that feature
   series, when they fix critical problems:
 
diff --git a/docs/intro/contributing.txt b/docs/intro/contributing.txt
index 0900fdae37e4..bcccc2a13c43 100644
--- a/docs/intro/contributing.txt
+++ b/docs/intro/contributing.txt
@@ -581,7 +581,7 @@ information on contributing that you should probably take a look at:
 
 * You should make sure to read Django's documentation on
   :doc:`claiming tickets and submitting pull requests
-  </internals/contributing/writing-code/submitting-patches>`.
+  </internals/contributing/writing-code/pull-requests>`.
   It covers Trac etiquette, how to claim tickets for yourself, expected
   coding style (both for code and docs), and many other important details.
 * First time contributors should also read Django's :doc:`documentation
@@ -611,7 +611,7 @@ with writing tests, you can also look at the list of
 `easy tickets that need tests`__. Remember to follow the guidelines about
 claiming tickets that were mentioned in the link to Django's documentation on
 :doc:`claiming tickets and submitting branches
-</internals/contributing/writing-code/submitting-patches>`.
+</internals/contributing/writing-code/pull-requests>`.
 
 __ https://code.djangoproject.com/query?status=new&status=reopened&has_patch=0&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority
 __ https://code.djangoproject.com/query?status=new&status=reopened&needs_better_patch=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority
@@ -622,7 +622,7 @@ What's next after creating a pull request?
 
 After a ticket has a branch, it needs to be reviewed by a second set of eyes.
 After submitting a pull request, update the ticket metadata by setting the
-flags on the ticket to say "has patch", "doesn't need tests", etc, so others
-can find it for review. Contributing doesn't necessarily always mean writing
-code from scratch. Reviewing open pull requests is also a very helpful
+flags on the ticket to say "has pull request", "doesn't need tests", etc, so
+others can find it for review. Contributing doesn't necessarily always mean
+writing code from scratch. Reviewing open pull requests is also a very helpful
 contribution. See :doc:`/internals/contributing/triaging-tickets` for details.
