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

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

.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 [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!
+            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).
 

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.
-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 contributions. Code contributions 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
 ===============

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
-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,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.
-  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.
+* If a contribution 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.
 
 * 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/localizing.txt

@@ -65,8 +65,8 @@ must:
   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/

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

docs/internals/contributing/triaging-tickets.txt

@@ -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.
 
-* **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>`.
 
 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
-documentation. Complete documentation of features is a prerequisite
-before we can check them into the codebase.
+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
-is a required part of a valid contribution.
+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 commit 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.