Merge pull request borgbackup#4759 from cherouvim/patch-1

docs: List items consistency

docs/development.rst

@@ -17,33 +17,33 @@ Contributions
 
 Some guidance for contributors:
 
-- discuss changes on the GitHub issue tracker, on IRC or on the mailing list
+- Discuss changes on the GitHub issue tracker, on IRC or on the mailing list.
 
-- make your PRs on the ``master`` branch (see `Branching Model`_ for details)
+- Make your PRs on the ``master`` branch (see `Branching Model`_ for details).
 
-- do clean changesets:
+- Do clean changesets:
 
-  - focus on some topic, resist changing anything else.
-  - do not do style changes mixed with functional changes.
-  - try to avoid refactorings mixed with functional changes.
-  - if you need to fix something after commit/push:
+  - Focus on some topic, resist changing anything else.
+  - Do not do style changes mixed with functional changes.
+  - Try to avoid refactorings mixed with functional changes.
+  - If you need to fix something after commit/push:
 
-    - if there are ongoing reviews: do a fixup commit you can
+    - If there are ongoing reviews: do a fixup commit you can
       squash into the bad commit later.
-    - if there are no ongoing reviews or you did not push the
+    - If there are no ongoing reviews or you did not push the
       bad commit yet: amend the commit to include your fix or
       merge the fixup commit before pushing.
-  - have a nice, clear, typo-free commit comment
-  - if you fixed an issue, refer to it in your commit comment
-  - follow the style guide (see below)
+  - Have a nice, clear, typo-free commit comment.
+  - If you fixed an issue, refer to it in your commit comment.
+  - Follow the style guide (see below).
 
-- if you write new code, please add tests and docs for it
+- If you write new code, please add tests and docs for it.
 
-- run the tests, fix any issues that come up
+- Run the tests, fix any issues that come up.
 
-- make a pull request on GitHub
+- Make a pull request on GitHub.
 
-- wait for review by other developers
+- Wait for review by other developers.
 
 Branching model
 ---------------
@@ -66,10 +66,10 @@ be applied.
 
 Changes that are typically considered for backporting:
 
-- Data loss, corruption and inaccessibility fixes
-- Security fixes
-- Forward-compatibility improvements
-- Documentation corrections
+- Data loss, corruption and inaccessibility fixes.
+- Security fixes.
+- Forward-compatibility improvements.
+- Documentation corrections.
 
 .. rubric:: Maintainer part
 
@@ -311,56 +311,56 @@ Creating a new release
 
 Checklist:
 
-- make sure all issues for this milestone are closed or moved to the
-  next milestone
-- check if there are any pending fixes for security issues
-- find and fix any low hanging fruit left on the issue tracker
-- check that Travis CI is happy
-- update ``CHANGES.rst``, based on ``git log $PREVIOUS_RELEASE..``
-- check version number of upcoming release in ``CHANGES.rst``
-- verify that ``MANIFEST.in`` and ``setup.py`` are complete
+- Make sure all issues for this milestone are closed or moved to the
+  next milestone.
+- Check if there are any pending fixes for security issues.
+- Find and fix any low hanging fruit left on the issue tracker.
+- Check that Travis CI is happy.
+- Update ``CHANGES.rst``, based on ``git log $PREVIOUS_RELEASE..``.
+- Check version number of upcoming release in ``CHANGES.rst``.
+- Verify that ``MANIFEST.in`` and ``setup.py`` are complete.
 - ``python setup.py build_usage ; python setup.py build_man`` and
   commit (be sure to build with Python 3.5 as Python 3.6 added `more
   guaranteed hashing algorithms
-  <https://github.com/borgbackup/borg/issues/2123>`_)
-- tag the release::
+  <https://github.com/borgbackup/borg/issues/2123>`_).
+- Tag the release::
 
     git tag -s -m "tagged/signed release X.Y.Z" X.Y.Z
 
-- create a clean repo and use it for the following steps::
+- Create a clean repo and use it for the following steps::
 
     git clone borg borg-clean
 
   This makes sure no uncommitted files get into the release archive.
   It will also reveal uncommitted required files.
   Moreover, it makes sure the vagrant machines only get committed files and
   do a fresh start based on that.
-- run tox and/or binary builds on all supported platforms via vagrant,
-  check for test failures
-- create sdist, sign it, upload release to (test) PyPi:
+- Run tox and/or binary builds on all supported platforms via vagrant,
+  check for test failures.
+- Create sdist, sign it, upload release to (test) PyPi:
 
   ::
 
     scripts/sdist-sign X.Y.Z
     scripts/upload-pypi X.Y.Z test
     scripts/upload-pypi X.Y.Z
-- put binaries into dist/borg-OSNAME and sign them:
+- Put binaries into dist/borg-OSNAME and sign them:
 
   ::
 
     scripts/sign-binaries 201912312359
-- close the release milestone on GitHub
-- announce on:
+- Close the release milestone on GitHub.
+- Announce on:
 
- - Mailing list
- - Twitter
- - IRC channel (change ``/topic``)
+ - Mailing list.
+ - Twitter.
+ - IRC channel (change ``/topic``).
 
-- create a GitHub release, include:
+- Create a GitHub release, include:
 
-  * standalone binaries (see above for how to create them)
+  * Standalone binaries (see above for how to create them).
 
-    + for OS X, document the OS X Fuse version in the README of the binaries.
+    + For OS X, document the OS X Fuse version in the README of the binaries.
       OS X FUSE uses a kernel extension that needs to be compatible with the
       code contained in the binary.
-  * a link to ``CHANGES.rst``
+  * A link to ``CHANGES.rst``.