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/howto/static-files/deployment.txt

@@ -12,13 +12,14 @@ Deploying static files
 Serving static files in production
 ==================================
 
-The basic outline of putting static files into production is simple: run the
-:djadmin:`collectstatic` command when static files change, then arrange for
-the collected static files directory (:setting:`STATIC_ROOT`) to be moved to
-the static file server and served. Depending on :setting:`STATICFILES_STORAGE`,
-files may need to be moved to a new location manually or the :func:`post_process
-<django.contrib.staticfiles.storage.StaticFilesStorage.post_process>` method
-of the ``Storage`` class might take care of that.
+The basic outline of putting static files into production consists of two
+steps: run the :djadmin:`collectstatic` command when static files change, then
+arrange for the collected static files directory (:setting:`STATIC_ROOT`) to be
+moved to the static file server and served. Depending on
+:setting:`STATICFILES_STORAGE`, files may need to be moved to a new location
+manually or the :func:`post_process
+<django.contrib.staticfiles.storage.StaticFilesStorage.post_process>` method of
+the ``Storage`` class might take care of that.
 
 Of course, as with all deployment tasks, the devil's in the details. Every
 production setup will be a bit different, so you'll need to adapt the basic
@@ -80,11 +81,11 @@ When using these services, the basic workflow would look a bit like the above,
 except that instead of using ``rsync`` to transfer your static files to the
 server you'd need to transfer the static files to the storage provider or CDN.
 
-There's any number of ways you might do this, but if the provider has an API a
-:doc:`custom file storage backend </howto/custom-file-storage>` will make the
-process incredibly simple. If you've written or are using a 3rd party custom
-storage backend, you can tell :djadmin:`collectstatic` to use it by setting
-:setting:`STATICFILES_STORAGE` to the storage engine.
+There's any number of ways you might do this, but if the provider has an API,
+you can use a :doc:`custom file storage backend </howto/custom-file-storage>`
+to integrate the CDN with your Django project. If you've written or are using a
+3rd party custom storage backend, you can tell :djadmin:`collectstatic` to use
+it by setting :setting:`STATICFILES_STORAGE` to the storage engine.
 
 For example, if you've written an S3 storage backend in
 ``myproject.storage.S3Storage`` you could use it with::
@@ -93,8 +94,8 @@ For example, if you've written an S3 storage backend in
 
 Once that's done, all you have to do is run :djadmin:`collectstatic` and your
 static files would be pushed through your storage package up to S3. If you
-later needed to switch to a different storage provider, it could be as simple
-as changing your :setting:`STATICFILES_STORAGE` setting.
+later needed to switch to a different storage provider, you may only have to
+change your :setting:`STATICFILES_STORAGE` setting.
 
 For details on how you'd write one of these backends, see
 :doc:`/howto/custom-file-storage`. There are 3rd party apps available that