Fixed #35894 -- Reduced the usage of "patch" when referring to a code contribution.

.github/workflows/new_contributor_pr.yml

@@ -18,7 +18,7 @@ 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 [contribution checklist](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-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!
 

CONTRIBUTING.rst

@@ -6,9 +6,9 @@ As an open source project, Django welcomes contributions of many forms.
 
 Examples of contributions include:
 
-* Code patches
+* Code contributions
 * 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:
@@ -21,9 +21,9 @@ 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.
+code contributions. Code contributions can be submitted as pull requests,
-Patches can be submitted as pull requests, but if you don't file a ticket,
+but if you don't file a ticket, it's unlikely that we'll notice your
-it's unlikely that we'll notice your contribution.
+contribution.
 
 Code of Conduct
 ===============

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>

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 impacts 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.
 

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
+Django is hosted on GitHub and uses pull requests (PRs) for contributions.
-requests.
 
 When committing a pull request, make sure each individual commit matches the
 commit guidelines described below. Contributors are expected to provide the
@@ -74,10 +73,10 @@ 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 contribution contains back-and-forth commits, then rewrite those into
-  For example, if a commit adds some code and a second commit fixes stylistic
+  one. For example, if a commit adds some code and a second commit fixes
-  issues introduced in the first commit, those commits should be squashed
+  stylistic issues introduced in the first commit, those commits should be
-  before merging.
+  squashed before merging.
 
 * Separate changes to different commits by logical grouping: if you do a
   stylistic cleanup at the same time as you do other changes to a file,
@@ -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

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
+area. Consider writing a test for the bug's behavior, even if you don't fix the
-you don't fix the bug itself. See more at :ref:`how-can-i-help-with-triaging`
+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
+appropriate flags if a pull request needs docs or tests. Look through the
-patch makes, and keep an eye out for syntax that is incompatible with older but
+files changed in the PR, and keep an eye out for syntax that is incompatible
-still supported versions of Python. :doc:`Run the tests
+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
+Oftentimes the codebase will change between a pull request being submitted and
-time it gets reviewed. Make sure it still applies cleanly and functions as
+the time it gets reviewed. Make sure there are no merge conflicts and that the
-expected. Updating a patch is both useful and important! See more on
+code still functions as expected. Updating a pull request is both useful and
-:doc:`writing-code/submitting-patches`.
+important! See more on :doc:`writing-code/submitting-patches`.
 
 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 change! 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
+When we say ":pep:`8`, and must have docs and tests", we mean it. If a pull
-doesn't have docs and tests, there had better be a good reason. Arguments like
+request doesn't have docs and tests, there had better be a good reason.
-"I couldn't find any existing tests of this feature" don't carry much weight.
+Arguments like "I couldn't find any existing tests of this feature" don't carry
-While it may be true, that means you have the extra-important job of writing
+much weight. While it may be true, that means you have the extra-important job
-the very first tests for that feature, not that you get a pass from writing
+of writing the very first tests for that feature, not that you get a pass from
-tests altogether.
+writing tests altogether.
 
 Be patient
 ----------
 
-It's not always easy for your ticket or your patch to be reviewed quickly. This
+It's not always easy for your ticket or pull request to be reviewed quickly.
-isn't personal. There are a lot of tickets and pull requests to get through.
+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
+Keeping your pull request up to date is important. Review the ticket on Trac to
-that the *Needs tests*, *Needs documentation*, and *Patch needs improvement*
+ensure that the *Needs tests*, *Needs documentation*, and *Patch needs
-flags are unchecked once you've addressed all review comments.
+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.

docs/internals/contributing/triaging-tickets.txt

@@ -71,7 +71,7 @@ By way of example, here we see the lifecycle of an average ticket:
 
 * 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.
+  pull request could be improved.
 
 * Alice updates the pull request, adding tests (but not changing the
   implementation). She removes the two flags.
@@ -114,22 +114,23 @@ 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
+  The ticket is valid, but no one has submitted a pull request for it yet.
-  means you could safely start writing a fix for it. This is generally more
+  Often this means you could safely start writing a fix for it. This is
-  true for the case of accepted bugs than accepted features. A ticket for a bug
+  generally more true for the case of accepted bugs than accepted features. A
-  that has been accepted means that the issue has been verified by at least one
+  ticket for a bug that has been accepted means that the issue has been
-  triager as a legitimate bug - and should probably be fixed if possible. An
+  verified by at least one triager as a legitimate bug - and should probably be
-  accepted new feature may only mean that one triager thought the feature would
+  fixed if possible. An accepted new feature may only mean that one triager
-  be good to have, but this alone does not represent a consensus view or imply
+  thought the feature would be good to have, but this alone does not represent
-  with any certainty that a patch will be accepted for that feature. Seek more
+  a consensus view or imply with any certainty that a pull request will be
-  feedback before writing an extensive contribution if you are in doubt.
+  accepted for that feature. Seek more feedback before writing an extensive
+  contribution if you are in doubt.
 
 * **Accepted + Has Patch**
 
   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
+  checking out the pull request and trying it out, verifying that it contains
-  and docs, running the test suite with the included patch, and leaving
+  tests and docs, checking that all the automated tests on the pull request are
-  feedback on the ticket.
+  passing, and leaving feedback.
 
 * **Accepted + Has Patch + Needs ...**
 
@@ -142,11 +143,11 @@ 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,8 +159,8 @@ 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.
+consider adding someday to the framework if an excellent contribution is
-They are not a high priority.
+submitted. They are not a high priority.
 
 Other triage attributes
 =======================
@@ -174,28 +175,27 @@ ensure they adhere to the :doc:`documented guidelines
 <writing-code/submitting-patches>`.
 
 The following three fields (Needs documentation, Needs tests,
-Patch needs improvement) apply only if a patch has been supplied.
+Patch 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
+documentation. Complete documentation of features is a prerequisite before we
-before we can check them into the codebase.
+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
-is a required part of a valid contribution.
+required part of a valid contribution.
 
 Patch 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
+ready for checkin. This could mean the pull request has merge conflicts, there
-cleanly, there is a flaw in the implementation, or that the code
+is a flaw in the implementation, or that the code doesn't meet our standards.
-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 commit has been merged and the issue is fixed.
 
 * invalid
       Used if the ticket is found to be incorrect. This means that the
@@ -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.

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 ``git diff`` 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 contribution if you make more than a
   single trivial change.
 
 JavaScript style

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 <submitting-patches>
    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>

docs/internals/contributing/writing-code/javascript.txt

@@ -30,10 +30,8 @@ Code style
   ``$(selector).click(func)``. This makes it easier for projects to extend
   Django's default behavior with JavaScript.
 
-.. _javascript-patches:
+jQuery and performance
-
+======================
-JavaScript patches
-==================
 
 Django's admin system leverages the jQuery framework to increase the
 capabilities of the admin interface. In conjunction, there is an emphasis on

docs/internals/contributing/writing-code/submitting-patches.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
+documentation, the preferred way is to open a pull request on GitHub without a
-requests without a Trac ticket.
+Trac ticket.
 
 See the :doc:`working-with-git` for more details on how to use pull requests.
 
@@ -112,7 +112,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 in the future.
 
 * If the code adds a new feature, or modifies the behavior of an existing
   feature, the change should also contain documentation.
@@ -147,7 +147,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 +306,14 @@ In each :term:`feature release <Feature release>`, all
 JavaScript contributions
 ========================
 
-For information on JavaScript contributions, see the :ref:`javascript-patches`
+For information on JavaScript contributions, see the :doc:`javascript`
 documentation.
 
-Optimization patches
+Optimization changes
 ====================
 
-Patches aiming to deliver a performance improvement should provide benchmarks
+Changes aiming to deliver a performance improvement should provide benchmarks
-showing the before and after impact of the patch and sharing the commands for
+showing the before and after impact of the change and sharing the commands for
 reviewers to reproduce.
 
 .. _django-asv-benchmarks:
@@ -349,12 +349,14 @@ 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
+Looking for a pull request to review? Check out the "Patches needing review"
-of the `Django Development Dashboard <https://dashboard.djangoproject.com/>`_.
+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 +407,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
+* Are you the pull request author and a new contributor? Please add yourself to
-  :source:`AUTHORS` file and submit a `Contributor License Agreement`_.
+  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>`.
 

docs/internals/contributing/writing-code/unit-tests.txt

@@ -129,7 +129,7 @@ Running the JavaScript tests
 Django includes a set of :ref:`JavaScript unit tests <javascript-tests>` for
 functions in certain contrib apps. The JavaScript tests aren't run by default
 using ``tox`` because they require ``Node.js`` to be installed and aren't
-necessary for the majority of patches. To run the JavaScript tests using
+necessary for the majority of contributions. To run the JavaScript tests using
 ``tox``:
 
 .. console::

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
+Testing a pull request locally
-==================
+==============================
 
-One of the ways that developers can contribute to Django is by reviewing
+One of the ways that developers can contribute to Django is by reviewing and
-patches. Those patches will typically exist as pull requests on GitHub and
+testing pull requests. Pull requests can be easily integrated into your local
-can be easily integrated into your local repository:
+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>`.

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 submit a pull request.
 
 Stable branches
 ===============

docs/internals/release-process.txt

@@ -131,9 +131,9 @@ 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 applied to the last feature release
-  release branch, to be released in the next patch release of that feature
+  branch, to be released in the next patch release of that feature series, when
-  series, when they fix critical problems:
+  they fix critical problems:
 
   * Security issues.