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.

docs/internals/contributing/bugs-and-features.txt

@@ -46,13 +46,13 @@ particular:
   include a clear, concise description of the problem, and a set of
   instructions for replicating it. Add as much debug information as you can:
   code snippets, test cases, exception backtraces, screenshots, etc. A nice
-  small test case is the best way to report a bug, as it gives us an easy
-  way to confirm the bug quickly.
+  small test case is the best way to report a bug, as it gives us a
+  helpful way to confirm the bug quickly.
 
-* **Don't** post to |django-developers| just to announce that you have
-  filed a bug report. All the tickets are mailed to another list,
-  |django-updates|, which is tracked by developers and interested
-  community members; we see them as they are filed.
+* **Don't** post to |django-developers| only to announce that you have filed a
+  bug report. All the tickets are mailed to another list, |django-updates|,
+  which is tracked by developers and interested community members; we see them
+  as they are filed.
 
 To understand the lifecycle of your ticket once you have created it, refer to
 :doc:`triaging-tickets`.
@@ -116,8 +116,8 @@ ticket description.
 
 As with most open-source projects, code talks. If you are willing to write the
 code for the feature yourself or, even better, if you've already written it,
-it's much more likely to be accepted. Just fork Django on GitHub, create a
-feature branch, and show us your work!
+it's much more likely to be accepted. Fork Django on GitHub, create a feature
+branch, and show us your work!
 
 See also: :ref:`documenting-new-features`.
 

docs/internals/contributing/committing-code.txt

@@ -11,8 +11,8 @@ contribute code to Django, look at :doc:`writing-code/working-with-git` instead.
 Handling pull requests
 ======================
 
-Since Django is now hosted at GitHub, most patches are provided in the form of
-pull requests.
+Since Django is hosted on GitHub, patches are provided in the form of pull
+requests.
 
 When committing a pull request, make sure each individual commit matches the
 commit guidelines described below. Contributors are expected to provide the
@@ -26,14 +26,14 @@ builders that doesn't run automatically, such as Oracle or Selenium. See the
 
 .. _Jenkins wiki page: https://code.djangoproject.com/wiki/Jenkins
 
-An easy way to checkout a pull request locally is to add an alias to your
-``~/.gitconfig`` (``upstream`` is assumed to be ``django/django``)::
+If you find yourself checking out pull requests locally more often, this git
+alias will be helpful::
 
     [alias]
         pr = !sh -c \"git fetch upstream pull/${1}/head:pr/${1} && git checkout pr/${1}\"
 
-Now you can simply run ``git pr ####`` to checkout the corresponding pull
-request.
+Add it to your ``~/.gitconfig``, and set ``upstream`` to be ``django/django``.
+Then you can run ``git pr ####`` to checkout the corresponding pull request.
 
 At this point, you can work on the code. Use ``git rebase -i`` and ``git
 commit --amend`` to make sure the commits have the expected level of quality.
@@ -243,8 +243,8 @@ When a mistaken commit is discovered, please follow these guidelines:
 * The release branch maintainer may back out commits to the release
   branch without permission if the commit breaks the release branch.
 
-* If you mistakenly push a topic branch to ``django/django``, just delete it.
+* If you mistakenly push a topic branch to ``django/django``, delete it.
   For instance, if you did: ``git push upstream feature_antigravity``,
-  just do a reverse push: ``git push upstream :feature_antigravity``.
+  do a reverse push: ``git push upstream :feature_antigravity``.
 
 .. _ticket tracker: https://code.djangoproject.com/

docs/internals/contributing/index.txt

@@ -36,7 +36,7 @@ development:
   on the `#django-dev IRC channel`_.
 
 * :doc:`Submit patches <writing-code/submitting-patches>` for new and/or
-  fixed behavior. If you're looking for an easy way to start contributing
+  fixed behavior. If you're looking for a way to get started contributing
   to Django read the :doc:`/intro/contributing` tutorial and have a look at the
   `easy pickings`_ tickets. The :ref:`patch-review-checklist` will also be
   helpful.

docs/internals/contributing/new-contributors.txt

@@ -13,7 +13,7 @@ to get started? This is the section for you.
 First steps
 ===========
 
-Start with these easy tasks to discover Django's development process.
+Start with these steps to discover Django's development process.
 
 * **Sign the Contributor License Agreement**
 
@@ -45,7 +45,7 @@ Start with these easy tasks to discover Django's development process.
 
   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. Simply updating a patch is both useful and important! See more on
+  expected. Updating a patch is both useful and important! See more on
   :doc:`writing-code/submitting-patches`.
 
 * **Write some documentation**

docs/internals/contributing/triaging-tickets.txt

@@ -17,12 +17,11 @@ community as a whole to self-manage, keep the problems to a minimum, and
 educate those coming into the community so that they can become valuable
 contributing members.
 
-Similarly, while we aim for Trac to be a perfect representation of the state
-of Django's progress, we acknowledge that this simply will not happen. By
-distributing the load of Trac maintenance to the community, we accept that
-there will be mistakes. Trac is "mostly accurate", and we give allowances for
-the fact that sometimes it will be wrong. That's okay. We're perfectionists
-with deadlines.
+Similarly, while we aim for Trac to be a perfect representation of the state of
+Django's progress, we acknowledge that this will not happen. By distributing
+the load of Trac maintenance to the community, we accept that there will be
+mistakes. Trac is "mostly accurate", and we give allowances for the fact that
+sometimes it will be wrong. That's okay. We're perfectionists with deadlines.
 
 We rely on the community to keep participating, keep tickets as accurate as
 possible, and raise issues for discussion on our mailing lists when there is
@@ -269,8 +268,8 @@ When a ticket has completed its useful lifecycle, it's time for it to be
 closed. Closing a ticket is a big responsibility, though. You have to be sure
 that the issue is really resolved, and you need to keep in mind that the
 reporter of the ticket may not be happy to have their ticket closed (unless
-it's fixed, of course). If you're not certain about closing a ticket, just
-leave a comment with your thoughts instead.
+it's fixed, of course). If you're not certain about closing a ticket, leave a
+comment with your thoughts instead.
 
 If you do close a ticket, you should always make sure of the following:
 

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:
 

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:
 

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

docs/internals/contributing/writing-documentation.txt

@@ -201,15 +201,15 @@ documentation:
   This is because Sphinx will generate proper links for the latter, which
   greatly helps readers.
 
-  You can prefix the target with a ``~`` (that's a tilde) to get just the
-  "last bit" of that path. So ``:mod:`~django.contrib.auth``` will just
+  You can prefix the target with a ``~`` (that's a tilde) to get only the
+  "last bit" of that path. So ``:mod:`~django.contrib.auth``` will
   display a link with the title "auth".
 
 * Use :mod:`~sphinx.ext.intersphinx` to reference Python's and Sphinx'
   documentation.
 
 * Add ``.. code-block:: <lang>`` to literal blocks so that they get
-  highlighted. Prefer relying on automatic highlighting simply using ``::``
+  highlighted. Prefer relying on automatic highlighting using ``::``
   (two colons). This has the benefit that if the code contains some invalid
   syntax, it won't be highlighted. Adding ``.. code-block:: python``, for
   example, will force highlighting despite invalid syntax.
@@ -383,8 +383,8 @@ If a function, attribute, etc. is added, it's also okay to use a
 
         An author's middle name.
 
-We can simply remove the ``.. versionadded:: A.B`` annotation without any
-indentation changes when the time comes.
+We can remove the ``.. versionadded:: A.B`` annotation without any indentation
+changes when the time comes.
 
 Minimizing images
 =================

docs/internals/git.txt

@@ -70,10 +70,10 @@ documentation, test suite, packaging scripts and other miscellaneous bits.
 Django's code will be present in your clone as a directory named
 ``django``.
 
-To try out the in-development code with your own applications, simply place
-the directory containing your clone on your Python import path. Then
-``import`` statements which look for Django will find the ``django`` module
-within your clone.
+To try out the in-development code with your own applications, place the
+directory containing your clone on your Python import path. Then ``import``
+statements which look for Django will find the ``django`` module within your
+clone.
 
 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

docs/internals/howto-release-django.txt

@@ -172,7 +172,7 @@ OK, this is the fun part, where we actually push out a release!
 
 #. If this is a security release, merge the appropriate patches from
    ``django-security``. Rebase these patches as necessary to make each one a
-   simple commit on the release branch rather than a merge commit. To ensure
+   plain commit on the release branch rather than a merge commit. To ensure
    this, merge them with the ``--ff-only`` flag; for example::
 
         $ git checkout stable/1.5.x

docs/internals/security.txt

@@ -163,8 +163,8 @@ notification of security issues is not and will not be made public.
 We also aim to keep this list as small as effectively possible, in
 order to better manage the flow of confidential information prior to
 disclosure. As such, our notification list is *not* simply a list of
-users of Django, and merely being a user of Django is not sufficient
-reason to be placed on the notification list.
+users of Django, and being a user of Django is not sufficient reason
+to be placed on the notification list.
 
 In broad terms, recipients of security notifications fall into three
 groups: