13 files changed, 123 insertions, 112 deletions
diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 2dc42d8853..c2dc0eee48 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -4,7 +4,8 @@ Committing code
 
 This section is addressed to the mergers and to anyone interested in knowing
 how code gets committed into Django. If you're a community member who wants to
-contribute code to Django, look at :doc:`writing-code/working-with-git` instead.
+contribute code to Django, look at :doc:`writing-code/working-with-git`
+instead.
 
 .. _handling-pull-requests:
 
diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index c0d87dcb7c..aac1354e5e 100644
--- a/docs/internals/contributing/triaging-tickets.txt
+++ b/docs/internals/contributing/triaging-tickets.txt
@@ -438,10 +438,10 @@ Next, we mark the current point in history as being "bad" since the test fails:
 
 Now, we need to find a point in git history before the regression was
 introduced (i.e. a point where the test passes). Use something like
-``git checkout HEAD~100`` to check out an earlier revision (100 commits earlier,
-in this case). Check if the test fails. If so, mark that point as "bad"
-(``git bisect bad``), then check out an earlier revision and recheck. Once you
-find a revision where your test passes, mark it as "good":
+``git checkout HEAD~100`` to check out an earlier revision (100 commits
+earlier, in this case). Check if the test fails. If so, mark that point as
+"bad" (``git bisect bad``), then check out an earlier revision and recheck.
+Once you find a revision where your test passes, mark it as "good":
 
 .. code-block:: shell
 
diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index 125525c737..64ef6c5a51 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -96,13 +96,12 @@ Python style
 
 * In docstrings, follow the style of existing docstrings and :pep:`257`.
 
-* In tests, use
-  :meth:`~django.test.SimpleTestCase.assertRaisesMessage` and
-  :meth:`~django.test.SimpleTestCase.assertWarnsMessage`
-  instead of :meth:`~unittest.TestCase.assertRaises` and
-  :meth:`~unittest.TestCase.assertWarns` so you can check the
-  exception or warning message. Use :meth:`~unittest.TestCase.assertRaisesRegex`
-  and :meth:`~unittest.TestCase.assertWarnsRegex` only if you need regular
+* In tests, use :meth:`~django.test.SimpleTestCase.assertRaisesMessage` and
+  :meth:`~django.test.SimpleTestCase.assertWarnsMessage` instead of
+  :meth:`~unittest.TestCase.assertRaises` and
+  :meth:`~unittest.TestCase.assertWarns` so you can check the exception or
+  warning message. Use :meth:`~unittest.TestCase.assertRaisesRegex` and
+  :meth:`~unittest.TestCase.assertWarnsRegex` only if you need regular
   expression matching.
 
   Use :meth:`assertIs(…, True/False)<unittest.TestCase.assertIs>` for testing
@@ -149,9 +148,10 @@ Imports
 
 * Put imports in these groups: future, standard library, third-party libraries,
   other Django components, local Django component, try/excepts. Sort lines in
-  each group alphabetically by the full module name. Place all ``import module``
-  statements before ``from module import objects`` in each section. Use absolute
-  imports for other Django components and relative imports for local components.
+  each group alphabetically by the full module name. Place all
+  ``import module`` statements before ``from module import objects`` in each
+  section. Use absolute imports for other Django components and relative
+  imports for local components.
 
 * On each line, alphabetize the items with the upper case items grouped before
   the lowercase items.
diff --git a/docs/internals/contributing/writing-code/javascript.txt b/docs/internals/contributing/writing-code/javascript.txt
index 25165206f0..b61fc009b7 100644
--- a/docs/internals/contributing/writing-code/javascript.txt
+++ b/docs/internals/contributing/writing-code/javascript.txt
@@ -17,8 +17,8 @@ Code style
   for indentation, but there are some exceptions.
 
 * When naming variables, use ``camelCase`` instead of ``underscore_case``.
-  Different JavaScript files sometimes use a different code style. Please try to
-  conform to the code style of each file.
+  Different JavaScript files sometimes use a different code style. Please try
+  to conform to the code style of each file.
 
 * Use the `ESLint`_ code linter to check your code for bugs and style errors.
   ESLint will be run when you run the JavaScript tests. We also recommended
@@ -89,8 +89,8 @@ The JavaScript tests may be run from a web browser or from the command line.
 Testing from a web browser
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To run the tests from a web browser, open up :source:`js_tests/tests.html` in your
-browser.
+To run the tests from a web browser, open up :source:`js_tests/tests.html` in
+your browser.
 
 To measure code coverage when running the tests, you need to view that file
 over HTTP. To view code coverage:
diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt
index 75186111dd..d1d5a8a32d 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/submitting-patches.txt
@@ -204,9 +204,12 @@ whether to accept it.
 
 Some examples of DEPs that have been approved and fully implemented:
 
-* `DEP 181: ORM Expressions <https://github.com/django/deps/blob/main/final/0181-orm-expressions.rst>`_
-* `DEP 182: Multiple Template Engines <https://github.com/django/deps/blob/main/final/0182-multiple-template-engines.rst>`_
-* `DEP 201: Simplified routing syntax <https://github.com/django/deps/blob/main/final/0201-simplified-routing-syntax.rst>`_
+* `DEP 181: ORM Expressions
+  <https://github.com/django/deps/blob/main/final/0181-orm-expressions.rst>`_
+* `DEP 182: Multiple Template Engines
+  <https://github.com/django/deps/blob/main/final/0182-multiple-template-engines.rst>`_
+* `DEP 201: Simplified routing syntax
+  <https://github.com/django/deps/blob/main/final/0201-simplified-routing-syntax.rst>`_
 
 .. _Django Forum: https://forum.djangoproject.com/
 .. _Django Enhancement Proposals: https://github.com/django/deps
@@ -226,19 +229,19 @@ There are a couple of reasons that code in Django might be deprecated:
   no longer needs to support the older version of Python that doesn't include
   the library, the library will be deprecated in Django.
 
-As the :ref:`deprecation policy<internal-release-deprecation-policy>` describes,
-the first release of Django that deprecates a feature (``A.B``) should raise a
-``RemovedInDjangoXXWarning`` (where XX is the Django version where the feature
-will be removed) when the deprecated feature is invoked. Assuming we have good
-test coverage, these warnings are converted to errors when :ref:`running the
-test suite <running-unit-tests>` with warnings enabled:
+As the :ref:`deprecation policy<internal-release-deprecation-policy>`
+describes, the first release of Django that deprecates a feature (``A.B``)
+should raise a ``RemovedInDjangoXXWarning`` (where XX is the Django version
+where the feature will be removed) when the deprecated feature is invoked.
+Assuming we have good test coverage, these warnings are converted to errors
+when :ref:`running the test suite <running-unit-tests>` with warnings enabled:
 ``python -Wa runtests.py``. Thus, when adding a ``RemovedInDjangoXXWarning``
 you need to eliminate or silence any warnings generated when running the tests.
 
-The first step is to remove any use of the deprecated behavior by Django itself.
-Next you can silence warnings in tests that actually test the deprecated
-behavior by using the ``ignore_warnings`` decorator, either at the test or class
-level:
+The first step is to remove any use of the deprecated behavior by Django
+itself. Next you can silence warnings in tests that actually test the
+deprecated behavior by using the ``ignore_warnings`` decorator, either at the
+test or class level:
 
 #) In a particular test::
 
@@ -305,8 +308,9 @@ Finally, there are a couple of updates to Django's documentation to make:
    applicable, to the current release notes (``docs/releases/A.B.txt``) under
    the "Features deprecated in A.B" heading.
 
-#) Add an entry in the deprecation timeline (``docs/internals/deprecation.txt``)
-   under the appropriate version describing what code will be removed.
+#) Add an entry in the deprecation timeline
+   (``docs/internals/deprecation.txt``) under the appropriate version
+   describing what code will be removed.
 
 Once you have completed these steps, you are finished with the deprecation.
 In each :term:`feature release <Feature release>`, all
@@ -402,10 +406,10 @@ Bugs
 
 * Is there a proper regression test (the test should fail before the fix
   is applied)?
-* If it's a bug that :ref:`qualifies for a backport <supported-versions-policy>`
-  to the stable version of Django, is there a release note in
-  ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the main
-  branch don't need a release note.
+* If it's a bug that :ref:`qualifies for a backport
+  <supported-versions-policy>` to the stable version of Django, is there a
+  release note in ``docs/releases/A.B.C.txt``? Bug fixes that will be applied
+  only to the main branch don't need a release note.
 
 New Features
 ------------
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index 1c993f5fc6..05b2bf09c6 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -398,9 +398,9 @@ and also excludes several directories not relevant to the results
 Contrib apps
 ============
 
-Tests for contrib apps can be found in the :source:`tests/` directory, typically
-under ``<app_name>_tests``. For example, tests for ``contrib.auth`` are located
-in :source:`tests/auth_tests`.
+Tests for contrib apps can be found in the :source:`tests/` directory,
+typically under ``<app_name>_tests``. For example, tests for ``contrib.auth``
+are located in :source:`tests/auth_tests`.
 
 .. _troubleshooting-unit-tests:
 
diff --git a/docs/internals/contributing/writing-documentation.txt b/docs/internals/contributing/writing-documentation.txt
index 2654cce06e..ff9bf5da47 100644
--- a/docs/internals/contributing/writing-documentation.txt
+++ b/docs/internals/contributing/writing-documentation.txt
@@ -205,8 +205,8 @@ All Python code blocks should be formatted using the :pypi:`blacken-docs`
 auto-formatter. This is automatically run by the :ref:`pre-commit hook
 <coding-style-pre-commit>` if configured.
 
-The check can also be run manually: provided that ``blacken-docs`` is installed,
-run the following command from the ``docs`` directory:
+The check can also be run manually: provided that ``blacken-docs`` is
+installed, run the following command from the ``docs`` directory:
 
 .. console::
 
@@ -245,8 +245,8 @@ Entries that have a status of "broken" need to be fixed. Those that have a
 status of "redirected" may need to be updated to point to the canonical
 location, e.g. the scheme has changed ``http://`` → ``https://``. In certain
 cases, we do not want to update a "redirected" link, e.g. a rewrite to always
-point to the latest or stable version of the documentation, e.g. ``/en/stable/`` →
-``/en/3.2/``.
+point to the latest or stable version of the documentation, e.g.
+``/en/stable/`` → ``/en/3.2/``.
 
 Writing style
 =============
@@ -523,12 +523,12 @@ General improvements or other changes to the APIs that should be emphasized
 should use the "``.. versionchanged:: X.Y``" directive (with the same format
 as the ``versionadded`` mentioned above.
 
-These ``versionadded`` and ``versionchanged`` blocks should be "self-contained."
-In other words, since we only keep these annotations around for two releases,
-it's nice to be able to remove the annotation and its contents without having
-to reflow, reindent, or edit the surrounding text. For example, instead of
-putting the entire description of a new or changed feature in a block, do
-something like this:
+These ``versionadded`` and ``versionchanged`` blocks should be
+"self-contained." In other words, since we only keep these annotations around
+for two releases, it's nice to be able to remove the annotation and its
+contents without having to reflow, reindent, or edit the surrounding text. For
+example, instead of putting the entire description of a new or changed feature
+in a block, do something like this:
 
 .. code-block:: rst
 
@@ -659,12 +659,12 @@ you'd like to help translate the documentation into another language.
 ``django-admin`` man page
 =========================
 
-Sphinx can generate a manual page for the
-:doc:`django-admin </ref/django-admin>` command. This is configured in
-``docs/conf.py``. Unlike other documentation output, this man page should be
-included in the Django repository and the releases as
-``docs/man/django-admin.1``. There isn't a need to update this file when
-updating the documentation, as it's updated once as part of the release process.
+Sphinx can generate a manual page for the :doc:`django-admin
+</ref/django-admin>` command. This is configured in ``docs/conf.py``. Unlike
+other documentation output, this man page should be included in the Django
+repository and the releases as ``docs/man/django-admin.1``. There isn't a need
+to update this file when updating the documentation, as it's updated once as
+part of the release process.
 
 To generate an updated version of the man page, in the ``docs`` directory, run:
 
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index b5dc17fd6a..5337800d67 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -748,8 +748,8 @@ details on these changes.
   (replaced by :py:mod:`argparse`).
 
 * The class ``django.core.management.NoArgsCommand`` will be removed. Use
-  :class:`~django.core.management.BaseCommand` instead, which takes no arguments
-  by default.
+  :class:`~django.core.management.BaseCommand` instead, which takes no
+  arguments by default.
 
 * ``django.core.context_processors`` module will be removed.
 
@@ -779,7 +779,8 @@ details on these changes.
   * ``get_all_related_many_to_many_objects()``
   * ``get_all_related_m2m_objects_with_model()``
 
-* The ``error_message`` argument of ``django.forms.RegexField`` will be removed.
+* The ``error_message`` argument of ``django.forms.RegexField`` will be
+  removed.
 
 * The ``unordered_list`` filter will no longer support old style lists.
 
@@ -805,7 +806,8 @@ details on these changes.
   ``django.contrib.admin.helpers.InlineAdminForm`` will be removed.
 
 * The backwards compatibility shim to allow ``FormMixin.get_form()`` to be
-  defined with no default value for its ``form_class`` argument will be removed.
+  defined with no default value for its ``form_class`` argument will be
+  removed.
 
 * The following settings will be removed:
 
@@ -872,14 +874,14 @@ details on these changes.
 * Support for the legacy ``%(<foo>)s`` syntax in ``ModelFormMixin.success_url``
   will be removed.
 
-* ``GeoQuerySet`` aggregate methods ``collect()``, ``extent()``, ``extent3d()``,
-  ``make_line()``, and ``unionagg()`` will be removed.
+* ``GeoQuerySet`` aggregate methods ``collect()``, ``extent()``,
+  ``extent3d()``, ``make_line()``, and ``unionagg()`` will be removed.
 
 * Ability to specify ``ContentType.name`` when creating a content type instance
   will be removed.
 
-* Support for the old signature of ``allow_migrate`` will be removed. It changed
-  from ``allow_migrate(self, db, model)`` to
+* Support for the old signature of ``allow_migrate`` will be removed. It
+  changed from ``allow_migrate(self, db, model)`` to
   ``allow_migrate(self, db, app_label, model_name=None, **hints)``.
 
 * Support for the syntax of ``{% cycle %}`` that uses comma-separated arguments
@@ -1002,8 +1004,8 @@ details on these changes.
 * ``django.utils.module_loading.import_by_path`` will be removed in favor of
   ``django.utils.module_loading.import_string``.
 
-* ``ssi`` and ``url`` template tags will be removed from the ``future`` template
-  tag library (used during the 1.3/1.4 deprecation period).
+* ``ssi`` and ``url`` template tags will be removed from the ``future``
+  template tag library (used during the 1.3/1.4 deprecation period).
 
 * ``django.utils.text.javascript_quote`` will be removed.
 
@@ -1013,9 +1015,9 @@ details on these changes.
 * The ``cache_choices`` option to :class:`~django.forms.ModelChoiceField` and
   :class:`~django.forms.ModelMultipleChoiceField` will be removed.
 
-* The default value of the
-  :attr:`RedirectView.permanent <django.views.generic.base.RedirectView.permanent>`
-  attribute will change from ``True`` to ``False``.
+* The default value of the :attr:`RedirectView.permanent
+  <django.views.generic.base.RedirectView.permanent>` attribute will change
+  from ``True`` to ``False``.
 
 * ``django.contrib.sitemaps.FlatPageSitemap`` will be removed in favor of
   ``django.contrib.flatpages.sitemaps.FlatPageSitemap``.
@@ -1098,8 +1100,8 @@ details on these changes.
 * The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting will be removed.
 
 * Usage of the hardcoded *Hold down "Control", or "Command" on a Mac, to select
-  more than one.* string to override or append to user-provided ``help_text`` in
-  forms for ManyToMany model fields will not be performed by Django anymore
+  more than one.* string to override or append to user-provided ``help_text``
+  in forms for ManyToMany model fields will not be performed by Django anymore
   either at the model or forms layer.
 
 * The ``Model._meta.get_(add|change|delete)_permission`` methods will
@@ -1112,8 +1114,9 @@ details on these changes.
   (``django.contrib.gis.sitemaps.views.index`` and
   ``django.contrib.gis.sitemaps.views.sitemap``).
 
-* ``django.utils.html.fix_ampersands``, the ``fix_ampersands`` template filter and
-  ``django.utils.html.clean_html`` will be removed following an accelerated deprecation.
+* ``django.utils.html.fix_ampersands``, the ``fix_ampersands`` template filter
+  and ``django.utils.html.clean_html`` will be removed following an accelerated
+  deprecation.
 
 .. _deprecation-removed-in-1.7:
 
@@ -1251,8 +1254,8 @@ details on these changes.
 * Setting the ``is_safe`` and ``needs_autoescape`` flags as attributes of
   template filter functions will no longer be supported.
 
-* The attribute ``HttpRequest.raw_post_data`` was renamed to ``HttpRequest.body``
-  in 1.4. The backward compatibility will be removed --
+* The attribute ``HttpRequest.raw_post_data`` was renamed to
+  ``HttpRequest.body`` in 1.4. The backward compatibility will be removed --
   ``HttpRequest.raw_post_data`` will no longer work.
 
 * The value for the ``post_url_continue`` parameter in
@@ -1337,10 +1340,10 @@ details on these changes.
   performance issues and will follow a slightly accelerated deprecation
   timeframe.
 
-* Translations located under the so-called *project path* will be ignored during
-  the translation building process performed at runtime. The
-  :setting:`LOCALE_PATHS` setting can be used for the same task by including the
-  filesystem path to a ``locale`` directory containing non-app-specific
+* Translations located under the so-called *project path* will be ignored
+  during the translation building process performed at runtime. The
+  :setting:`LOCALE_PATHS` setting can be used for the same task by including
+  the filesystem path to a ``locale`` directory containing non-app-specific
   translations in its value.
 
 * The Markup contrib app will no longer support versions of Python-Markdown
diff --git a/docs/internals/git.txt b/docs/internals/git.txt
index 7329fe0bbc..8b6ce3d453 100644
--- a/docs/internals/git.txt
+++ b/docs/internals/git.txt
@@ -115,11 +115,11 @@ updates.
     committed until the final release happened.
 
     For example, shortly after the release of Django 1.3 the branch
-    ``stable/1.3.x`` was created. Official support for that release has expired,
-    and so it no longer receives direct maintenance from the Django project.
-    However, that and all other similarly named branches continue to exist, and
-    interested community members have occasionally used them to provide
-    unofficial support for old Django releases.
+    ``stable/1.3.x`` was created. Official support for that release has
+    expired, and so it no longer receives direct maintenance from the Django
+    project. However, that and all other similarly named branches continue to
+    exist, and interested community members have occasionally used them to
+    provide unofficial support for old Django releases.
 
 Tags
 ====
diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt
index 5e0f8469d2..de5e076702 100644
--- a/docs/internals/howto-release-django.txt
+++ b/docs/internals/howto-release-django.txt
@@ -471,7 +471,8 @@ Building the artifacts
 
 .. admonition:: Optionally use helper scripts
 
-    You can streamline some of the steps below using helper scripts from the Wiki:
+    You can streamline some of the steps below using helper scripts from the
+    Wiki:
 
     * `Release script
       <https://code.djangoproject.com/wiki/ReleaseScript>`_
diff --git a/docs/internals/organization.txt b/docs/internals/organization.txt
index 907c4185cc..a213794ad3 100644
--- a/docs/internals/organization.txt
+++ b/docs/internals/organization.txt
@@ -72,9 +72,9 @@ to make the role of Merger sustainable.
 
 The following restrictions apply to the role of Merger:
 
-- A person must not simultaneously serve as a member of the steering council. If
-  a Merger is elected to the steering council, they shall cease to be a Merger
-  immediately upon taking up membership in the steering council.
+- A person must not simultaneously serve as a member of the steering council.
+  If a Merger is elected to the steering council, they shall cease to be a
+  Merger immediately upon taking up membership in the steering council.
 - A person may serve in the roles of Releaser and Merger simultaneously.
 
 The selection process, when a vacancy occurs or when the steering council deems
@@ -122,10 +122,10 @@ upload them to the :pypi:`Python Package Index <Django>` and to the
 Membership
 ----------
 
-`The steering council`_ selects Releasers_ as necessary to maintain their number
-at a minimum of three, in order to spread the workload and avoid over-burdening
-or burning out any individual Releaser. There is no upper limit to the number
-of Releasers.
+`The steering council`_ selects Releasers_ as necessary to maintain their
+number at a minimum of three, in order to spread the workload and avoid
+over-burdening or burning out any individual Releaser. There is no upper limit
+to the number of Releasers.
 
 It's not a requirement that a Releaser is also a Django Fellow, but the Django
 Software Foundation has the power to use funding of Fellow positions as a way
@@ -223,13 +223,14 @@ who demonstrate:
   years must still demonstrate an understanding of Django's changes and
   direction within those three years.
 
-A new council is elected after each release cycle of Django. The election process
-works as follows:
+A new council is elected after each release cycle of Django. The election
+process works as follows:
 
-#. The steering council directs one of its members to notify the Secretary of the
-   Django Software Foundation, in writing, of the triggering of the election,
-   and the condition which triggered it. The Secretary post to the appropriate
-   venue -- the `Django Forum`_ to announce the election and its timeline.
+#. The steering council directs one of its members to notify the Secretary of
+   the Django Software Foundation, in writing, of the triggering of the
+   election, and the condition which triggered it. The Secretary post to the
+   appropriate venue -- the `Django Forum`_ to announce the election and its
+   timeline.
 #. As soon as the election is announced, the `DSF Board`_ begin a period of
    voter registration. All `individual members of the DSF`_ are automatically
    registered and need not explicitly register. All other persons who believe
@@ -267,12 +268,12 @@ A member of the steering council may be removed by:
 - Becoming disqualified due to actions taken by the Code of Conduct committee
   of the Django Software Foundation.
 - Determining that they did not possess the qualifications of a member of the
-  steering council. This determination must be made jointly by the other members
-  of the steering council, and the `DSF Board`_. A valid determination of
-  ineligibility requires that all other members of the steering council and all
-  members of the DSF Board vote who can vote on the issue (the affected person,
-  if a DSF Board member, must not vote) vote "yes" on a motion that the person
-  in question is ineligible.
+  steering council. This determination must be made jointly by the other
+  members of the steering council, and the `DSF Board`_. A valid determination
+  of ineligibility requires that all other members of the steering council and
+  all members of the DSF Board vote who can vote on the issue (the affected
+  person, if a DSF Board member, must not vote) vote "yes" on a motion that the
+  person in question is ineligible.
 
 .. _`Django Forum`: https://forum.djangoproject.com/
 .. _`Django Git repository`: https://github.com/django/django/
diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index ec5bdd3c7a..53c60d50db 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -45,8 +45,8 @@ security purposes, please see :doc:`our security policies <security>`.
     bugs and/or security issues.
 
     These releases will be 100% compatible with the associated feature release,
-    unless this is impossible for security reasons or to prevent data loss.
-    So the answer to "should I upgrade to the latest patch release?" will always
+    unless this is impossible for security reasons or to prevent data loss. So
+    the answer to "should I upgrade to the latest patch release?" will always
     be "yes."
 
   Long-term support release
@@ -123,8 +123,8 @@ See also the :ref:`deprecating-a-feature` guide.
 Supported versions
 ==================
 
-At any moment in time, Django's developer team will support a set of releases to
-varying levels. See `the supported versions section
+At any moment in time, Django's developer team will support a set of releases
+to varying levels. See `the supported versions section
 <https://www.djangoproject.com/download/#supported-versions>`_ of the download
 page for the current state of support for each version.
 
diff --git a/docs/internals/security.txt b/docs/internals/security.txt
index 567446c30e..745f26f5f5 100644
--- a/docs/internals/security.txt
+++ b/docs/internals/security.txt
@@ -292,7 +292,8 @@ requires a security release:
   * Exploits which fail to follow security best practices, such as failure to
     sanitize user input. For other examples, see our :ref:`security
     documentation <cross-site-scripting>`.
-  * Exploits in AI generated code that do not adhere to security best practices.
+  * Exploits in AI generated code that do not adhere to security best
+    practices.
 
 The security team may conclude that the source of the vulnerability is within
 the Python standard library, in which case the reporter will be asked to report
@@ -303,8 +304,8 @@ On occasion, a security release may be issued to help resolve a security
 vulnerability within a popular third-party package. These reports should come
 from the package maintainers.
 
-If you are unsure whether your finding meets these criteria, please still report
-it :ref:`privately by emailing security@djangoproject.com
+If you are unsure whether your finding meets these criteria, please still
+report it :ref:`privately by emailing security@djangoproject.com
 <reporting-security-issues>`. The security team will review your report and
 recommend the correct course of action.