Fixed #30573 -- Rephrased documentation to avoid words that minimise the involved difficulty.

This patch does not remove all occurrences of the words in question.
Rather, I went through all of the occurrences of the words listed
below, and judged if they a) suggested the reader had some kind of
knowledge/experience, and b) if they added anything of value (including
tone of voice, etc). I left most of the words alone. I looked at the
following words:

- simply/simple
- easy/easier/easiest
- obvious
- just
- merely
- straightforward
- ridiculous

Thanks to Carlton Gibson for guidance on how to approach this issue, and
to Tim Bell for providing the idea. But the enormous lion's share of
thanks go to Adam Johnson for his patient and helpful review.

3 files changed, 15 insertions, 16 deletions

diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt
index 5bfff59b52..d70bc428d1 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/submitting-patches.txt
@@ -85,10 +85,9 @@ Which tickets should be claimed?
 Of course, going through the steps of claiming tickets is overkill in some
 cases.
 
-In the case of small changes, such as typos in the documentation or
-small bugs that will only take a few minutes to fix, you don't need to jump
-through the hoops of claiming tickets. Just submit your patch and be done with
-it.
+In the case of small changes, such as typos in the documentation or small bugs
+that will only take a few minutes to fix, you don't need to jump through the
+hoops of claiming tickets. Submit your patch directly and you're done!
 
 Of course, it is *always* acceptable, regardless whether someone has claimed it
 or not, to submit patches to a ticket if you happen to have a patch ready.
@@ -145,14 +144,14 @@ Regardless of the way you submit your work, follow these steps.
 Non-trivial patches
 ===================
 
-A "non-trivial" patch is one that is more than a simple bug fix. It's a patch
+A "non-trivial" patch is one that is more than a small bug fix. It's a patch
 that introduces Django functionality and makes some sort of design decision.
 
 If you provide a non-trivial patch, include evidence that alternatives have
 been discussed on |django-developers|.
 
-If you're not sure whether your patch should be considered non-trivial, just
-ask.
+If you're not sure whether your patch should be considered non-trivial, ask on
+the ticket for opinions.
 
 .. _deprecating-a-feature:
 
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index 291c50852c..a4c7ea09b0 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -45,10 +45,10 @@ test dependencies. If you don't have an optional dependency installed, the
 tests that require it will be skipped.
 
 Running the tests requires a Django settings module that defines the databases
-to use. To make it easy to get started, Django provides and uses a sample
-settings module that uses the SQLite database. See
-:ref:`running-unit-tests-settings` to learn how to use a different settings
-module to run the tests with a different database.
+to use. To help you get started, Django provides and uses a sample settings
+module that uses the SQLite database. See :ref:`running-unit-tests-settings` to
+learn how to use a different settings module to run the tests with a different
+database.
 
 Having problems? See :ref:`troubleshooting-unit-tests` for some common issues.
 
@@ -199,7 +199,7 @@ internationalization, type:
 How do you find out the names of individual tests? Look in ``tests/`` — each
 directory name there is the name of a test.
 
-If you just want to run a particular class of tests, you can specify a list of
+If you want to run only a particular class of tests, you can specify a list of
 paths to individual test classes. For example, to run the ``TranslationTests``
 of the ``i18n`` module, type:
 
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index 60ba1345a4..639f7719b8 100644
--- a/docs/internals/contributing/writing-code/working-with-git.txt
+++ b/docs/internals/contributing/writing-code/working-with-git.txt
@@ -98,7 +98,7 @@ necessary::
 Publishing work
 ---------------
 
-You can publish your work on GitHub just by doing::
+You can publish your work on GitHub by running::
 
   git push origin ticket_xxxxx
 
@@ -186,9 +186,9 @@ the changes::
     git push -f origin ticket_xxxxx
 
 Note that this will rewrite history of ticket_xxxxx - if you check the commit
-hashes before and after the operation at GitHub you will notice that the
-commit hashes do not match anymore. This is acceptable, as the branch is merely
-a topic branch, and nobody should be basing their work on it.
+hashes before and after the operation at GitHub you will notice that the commit
+hashes do not match anymore. This is acceptable, as the branch is a topic
+branch, and nobody should be basing their work on it.
 
 After upstream has changed
 --------------------------