Replaced usage of "patch" with more precise terms in faq, howto, and intro docs.

1 files changed, 42 insertions, 43 deletions

diff --git a/docs/intro/contributing.txt b/docs/intro/contributing.txt
index 06230b8ee3..7d590e76a2 100644
--- a/docs/intro/contributing.txt
+++ b/docs/intro/contributing.txt
@@ -1,6 +1,6 @@
-===================================
-Writing your first patch for Django
-===================================
+==========================================
+Writing your first contribution for Django
+==========================================
 
 Introduction
 ============
@@ -52,16 +52,16 @@ __ https://web.libera.chat/#django-dev
 What does this tutorial cover?
 ------------------------------
 
-We'll be walking you through contributing a patch to Django for the first time.
+We'll be walking you through contributing to Django for the first time.
 By the end of this tutorial, you should have a basic understanding of both the
 tools and the processes involved. Specifically, we'll be covering the following:
 
 * Installing Git.
 * Downloading a copy of Django's development version.
 * Running Django's test suite.
-* Writing a test for your patch.
-* Writing the code for your patch.
-* Testing your patch.
+* Writing a test for your changes.
+* Writing the code for your changes.
+* Testing your changes.
 * Submitting a pull request.
 * Where to look for more information.
 
@@ -91,7 +91,7 @@ Installing Git
 ==============
 
 For this tutorial, you'll need Git installed to download the current
-development version of Django and to generate patch files for the changes you
+development version of Django and to generate a branch for the changes you
 make.
 
 To check whether or not you have Git installed, enter ``git`` into the command
@@ -178,7 +178,7 @@ Go ahead and install the previously cloned copy of Django:
 
 The installed version of Django is now pointing at your local copy by installing
 in editable mode. You will immediately see any changes you make to it, which is
-of great help when writing your first patch.
+of great help when writing your first contribution.
 
 Creating projects with a local copy of Django
 ---------------------------------------------
@@ -188,8 +188,8 @@ have to create a new virtual environment, :ref:`install the previously cloned
 local copy of Django in editable mode <intro-contributing-install-local-copy>`,
 and create a new Django project outside of your local copy of Django. You will
 immediately see any changes you make to Django in your new project, which is
-of great help when writing your first patch, especially if testing any changes
-to the UI.
+of great help when writing your first contribution, especially if testing
+any changes to the UI.
 
 You can follow the :doc:`tutorial</intro/tutorial01>` for help in creating a
 Django project.
@@ -279,8 +279,8 @@ imaginary details:
 
 We'll now implement this feature and associated tests.
 
-Creating a branch for your patch
-================================
+Creating a branch
+=================
 
 Before making any changes, create a new branch for the ticket:
 
@@ -295,19 +295,19 @@ won't affect the main copy of the code that we cloned earlier.
 Writing some tests for your ticket
 ==================================
 
-In most cases, for a patch to be accepted into Django it has to include tests.
-For bug fix patches, this means writing a regression test to ensure that the
-bug is never reintroduced into Django later on. A regression test should be
-written in such a way that it will fail while the bug still exists and pass
-once the bug has been fixed. For patches containing new features, you'll need
-to include tests which ensure that the new features are working correctly.
-They too should fail when the new feature is not present, and then pass once it
-has been implemented.
+In most cases, for a contribution to be accepted into Django it has to include
+tests. For bug fix contributions, this means writing a regression test to
+ensure that  the bug is never reintroduced into Django later on. A regression
+test should be written in such a way that it will fail while the bug still
+exists and pass once the bug has been fixed. For contributions containing new
+features, you'll need to include tests which ensure that the new features are
+working correctly. They too should fail when the new feature is not present,
+and then pass once it has been implemented.
 
 A good way to do this is to write your new tests first, before making any
 changes to the code. This style of development is called
 `test-driven development`__ and can be applied to both entire projects and
-single patches. After writing your tests, you then run them to make sure that
+single changes. After writing your tests, you then run them to make sure that
 they do indeed fail (since you haven't fixed that bug or added that feature
 yet). If your new tests don't fail, you'll need to fix them so that they do.
 After all, a regression test that passes regardless of whether a bug is present
@@ -398,7 +398,7 @@ function to the correct file.
 Running Django's test suite for the second time
 ===============================================
 
-Once you've verified that your patch and your test are working correctly, it's
+Once you've verified that your changes and test are working correctly, it's
 a good idea to run the entire Django test suite to verify that your change
 hasn't introduced any bugs into other areas of Django. While successfully
 passing the entire test suite doesn't guarantee your code is bug free, it does
@@ -450,7 +450,7 @@ preview the HTML that will be generated.
 Previewing your changes
 =======================
 
-Now it's time to go through all the changes made in our patch. To stage all the
+Now it's time to review the changes made in the branch. To stage all the
 changes ready for commit, run:
 
 .. console::
@@ -528,12 +528,11 @@ Use the arrow keys to move up and down.
     +    def test_make_toast(self):
     +        self.assertEqual(make_toast(), 'toast')
 
-When you're done previewing the patch, hit the ``q`` key to return to the
-command line. If the patch's content looked okay, it's time to commit the
-changes.
+When you're done previewing the changes, hit the ``q`` key to return to the
+command line. If the diff looked okay, it's time to commit the changes.
 
-Committing the changes in the patch
-===================================
+Committing the changes
+======================
 
 To commit the changes:
 
@@ -551,7 +550,7 @@ message guidelines <committing-guidelines>` and write a message like:
 Pushing the commit and making a pull request
 ============================================
 
-After committing the patch, send it to your fork on GitHub (substitute
+After committing the changes, send it to your fork on GitHub (substitute
 "ticket_99999" with the name of your branch if it's different):
 
 .. console::
@@ -563,7 +562,7 @@ You can create a pull request by visiting the `Django GitHub page
 recently pushed branches". Click "Compare & pull request" next to it.
 
 Please don't do it for this tutorial, but on the next page that displays a
-preview of the patch, you would click "Create pull request".
+preview of the changes, you would click "Create pull request".
 
 Next steps
 ==========
@@ -578,14 +577,14 @@ codebase.
 More information for new contributors
 -------------------------------------
 
-Before you get too into writing patches for Django, there's a little more
+Before you get too into contributing to Django, there's a little more
 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 patches
+  :doc:`claiming tickets and submitting pull requests
   </internals/contributing/writing-code/submitting-patches>`.
   It covers Trac etiquette, how to claim tickets for yourself, expected
-  coding style for patches, and many other important details.
+  coding style (both for code and docs), and many other important details.
 * First time contributors should also read Django's :doc:`documentation
   for first time contributors</internals/contributing/new-contributors/>`.
   It has lots of good advice for those of us who are new to helping out
@@ -600,19 +599,19 @@ Finding your first real ticket
 ------------------------------
 
 Once you've looked through some of that information, you'll be ready to go out
-and find a ticket of your own to write a patch for. Pay special attention to
+and find a ticket of your own to contribute to. Pay special attention to
 tickets with the "easy pickings" criterion. These tickets are often much
 simpler in nature and are great for first time contributors. Once you're
-familiar with contributing to Django, you can move on to writing patches for
-more difficult and complicated tickets.
+familiar with contributing to Django, you can start working on more difficult
+and complicated tickets.
 
 If you just want to get started already (and nobody would blame you!), try
-taking a look at the list of `easy tickets that need patches`__ and the
-`easy tickets that have patches which need improvement`__. If you're familiar
+taking a look at the list of `easy tickets without a branch`__ and the
+`easy tickets that have branches which need improvement`__. If you're familiar
 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 patches
+:doc:`claiming tickets and submitting branches
 </internals/contributing/writing-code/submitting-patches>`.
 
 __ 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
@@ -622,9 +621,9 @@ __ https://code.djangoproject.com/query?status=new&status=reopened&needs_tests=1
 What's next after creating a pull request?
 ------------------------------------------
 
-After a ticket has a patch, it needs to be reviewed by a second set of eyes.
+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 a
-patch from scratch. Reviewing existing patches is also a very helpful
+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.