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/ref/contrib/admin/index.txt

@@ -83,8 +83,7 @@ Other topics
 
     The ``ModelAdmin`` class is the representation of a model in the admin
     interface. Usually, these are stored in a file named ``admin.py`` in your
-    application. Let's take a look at a very simple example of
-    the ``ModelAdmin``::
+    application. Let's take a look at an example of the ``ModelAdmin``::
 
         from django.contrib import admin
         from myproject.myapp.models import Author
@@ -1195,8 +1194,8 @@ subclass::
     A read-only field can not only display data from a model's field, it can
     also display the output of a model's method or a method of the
     ``ModelAdmin`` class itself. This is very similar to the way
-    :attr:`ModelAdmin.list_display` behaves. This provides an easy way to use
-    the admin interface to provide feedback on the status of the objects being
+    :attr:`ModelAdmin.list_display` behaves. This provides a way to use the
+    admin interface to provide feedback on the status of the objects being
     edited, for example::
 
         from django.contrib import admin
@@ -1742,7 +1741,7 @@ templates used by the :class:`ModelAdmin` views:
                     kwargs['form'] = MySuperuserForm
                 return super().get_form(request, obj, **kwargs)
 
-    You may also simply return a custom :class:`~django.forms.ModelForm` class
+    You may also return a custom :class:`~django.forms.ModelForm` class
     directly.
 
 .. method:: ModelAdmin.get_formsets_with_inlines(request, obj=None)
@@ -2159,9 +2158,9 @@ return the uncompressed versions of the various JavaScript files, including
 Adding custom validation to the admin
 -------------------------------------
 
-Adding custom validation of data in the admin is quite easy. The automatic
-admin interface reuses :mod:`django.forms`, and the ``ModelAdmin`` class gives
-you the ability define your own form::
+You can also add custom validation of data in the admin. The automatic admin
+interface reuses :mod:`django.forms`, and the ``ModelAdmin`` class gives you
+the ability define your own form::
 
     class ArticleAdmin(admin.ModelAdmin):
         form = MyArticleAdminForm
@@ -2535,8 +2534,7 @@ layout required for multiple widgets will vary depending on the intermediate
 model.
 
 However, we still want to be able to edit that information inline. Fortunately,
-this is easy to do with inline admin models. Suppose we have the following
-models::
+we can do this with inline admin models. Suppose we have the following models::
 
     from django.db import models
 
@@ -2560,7 +2558,7 @@ define an inline class for the ``Membership`` model::
         model = Membership
         extra = 1
 
-This simple example uses the default ``InlineModelAdmin`` values for the
+This example uses the default ``InlineModelAdmin`` values for the
 ``Membership`` model, and limits the extra add forms to one. This could be
 customized using any of the options available to ``InlineModelAdmin`` classes.
 
@@ -2633,9 +2631,9 @@ specific information.
 Overriding admin templates
 ==========================
 
-It is relatively easy to override many of the templates which the admin module
-uses to generate the various pages of an admin site. You can even override a
-few of these templates for a specific app, or a specific model.
+You can override many of the templates which the admin module uses to generate
+the various pages of an admin site. You can even override a few of these
+templates for a specific app, or a specific model.
 
 Set up your projects admin template directories
 -----------------------------------------------
@@ -2732,7 +2730,7 @@ app or per model. The following can:
 * ``submit_line.html``
 
 For those templates that cannot be overridden in this way, you may still
-override them for your entire project. Just place the new version in your
+override them for your entire project by placing the new version in your
 ``templates/admin`` directory. This is particularly useful to create custom 404
 and 500 pages.
 
@@ -2923,11 +2921,11 @@ Customizing the :class:`AdminSite` class
 ----------------------------------------
 
 If you'd like to set up your own admin site with custom behavior, you're free
-to subclass ``AdminSite`` and override or add anything you like. Then, simply
-create an instance of your ``AdminSite`` subclass (the same way you'd
-instantiate any other Python class) and register your models and
-``ModelAdmin`` subclasses with it instead of with the default site. Finally,
-update :file:`myproject/urls.py` to reference your :class:`AdminSite` subclass.
+to subclass ``AdminSite`` and override or add anything you like. Then, create
+an instance of your ``AdminSite`` subclass (the same way you'd instantiate any
+other Python class) and register your models and ``ModelAdmin`` subclasses with
+it instead of with the default site. Finally, update :file:`myproject/urls.py`
+to reference your :class:`AdminSite` subclass.
 
 .. code-block:: python
     :caption: myapp/admin.py
@@ -3000,9 +2998,9 @@ returns a site instance.
 Multiple admin sites in the same URLconf
 ----------------------------------------
 
-It's easy to create multiple instances of the admin site on the same
-Django-powered website. Just create multiple instances of ``AdminSite`` and
-root each one at a different URL.
+You can create multiple instances of the admin site on the same Django-powered
+website. Create multiple instances of ``AdminSite`` and place each one at a
+different URL.
 
 In this example, the URLs ``/basic-admin/`` and ``/advanced-admin/`` feature
 separate versions of the admin site -- using the ``AdminSite`` instances