Add empty lines between list items: learn rst

brettcannon · Jan 30, 2021 · Dec 23, 2020 · Dec 23, 2020 · Dec 23, 2020 · Dec 23, 2020
commit f4e9e83ea3cf97607ca04a360f84bfcad78ce327
diff --git a/committing.rst b/committing.rst
@@ -18,35 +18,43 @@ the public source tree. Ask yourself the following questions:
    only branch that receives new features is ``master``, the in-development 
    branch.
 
+
 #. **Are there comments on the PR?** Look for explanations about whether 
    the code coverage increased or stayed the same.
 
+
 #. **Are the changes acceptable?** If you want to share your work-in-progress 
    code on a feature or bugfix, then you can open a ``WIP``-prefixed PR, 
    publish patches on the `issue tracker <https://bugs.python.org/>`_, or 
    create a public fork of the repository.
 
+
 #. **Does the check on the PR show that the test suite passes?** :ref:`Run the 
    entire test suite <runtests>` to ensure that it passes. Running a single 
    test is not enough since the changes may have unforeseen effects on other 
    tests or library modules.
 
+
 #. **Is the patch in a good state?** Check :ref:`patch` and
    :ref:`helptriage` to review what is expected of a patch.
 
+
 #. **Do the changes meet the requirements of the patch checklist?** :ref:`Run 
    patchcheck <patchcheck>` to perform a quick confidence check on the changes.
 
+
 #. **Does the patch break backwards-compatibility without a strong 
    reason?** :ref:`Run the entire test suite <runtests>` to
    make sure that everything still passes. If there is a change to the
    semantics, then there needs to be a strong reason, because it will 
    cause some peoples' code to break. If you are unsure if the breakage
    is worth it, then ask on python-dev.
 
+
 #. **Were configure and pyconfig.h.in regenerated?** 
    Regnenerate them if necessary.
 
+
 #. **Were appropriate labels added to signify necessary backporting of the
    pull request?** If it is determined that a pull request needs to be 
    backported into one or more of the maintenance branches, then a core 
@@ -56,6 +64,7 @@ the public source tree. Ask yourself the following questions:
    core developers and members of the `Python Triage Team`_ can apply 
    labels to GitHub pull requests).
 
+
 #. **Does the PR have a label indicating that the submitter has signed the 
    CLA?** Make sure that the contributor has signed a `Contributor Licensing 
    Agreement`_ (CLA), unless their change has no possible intellectual 
@@ -65,6 +74,7 @@ the public source tree. Ask yourself the following questions:
    put in their GitHub username. For further questions about the CLA 
    process, write to: contributors@python.org.
 
+
 #. **Was the contributor added to Misc/ACKS?** Make sure that 
    the patch is attributed correctly with the contributor's name in 
    ``Misc/ACKS``. If the patch has been heavily modified, then "Initial
@@ -74,6 +84,7 @@ the public source tree. Ask yourself the following questions:
    in a commit. Add ``Co-authored-by: name <name@example.com>`` at the end 
    of the commit message.
 
+
 #. **Were What's New in Python (in Doc/whatsnew/) and 
    Misc/NEWS.d/next updated?** If the change is particularly interesting 
    for end users (e.g. new features, significant improvements, or 
@@ -82,6 +93,7 @@ the public source tree. Ask yourself the following questions:
    as well. Changes that affect only documentation generally do not require
    a NEWS entry. (See the following section for more information.)
 
+
 Updating NEWS and What's New in Python
 --------------------------------------