--- a/docs/devguide/jenkins.rst
+++ b/docs/devguide/jenkins.rst
@@ -33,17 +33,17 @@ that executes::
 
    testing/jenkins/run-main.py
 
 For post-build actions, you have a number of options.
 
 You can *Publish Cobertura Coverage Report* by using
 ``**/coverage/coverage.xml`` for the *Cobertura xml report pattern*.
 
-You can *Publish JUnit test result report*s by using
+You can *Publish JUnit test result reports* by using
 ``coverage/results.xml`` as the *Test Reports XML* value.
 
 You can *Publish coverage.py HTML reports* by setting
 ``coverage/html`` as the *Report directory*.
 
 You can *Publish HTML Reports* containing the generated Sphinx
 documentation by setting ``sphinx-docs/html`` as the *HTML directory to
 archive* and setting the *Index Page* to ``index.html``.

--- a/docs/hgmozilla/dag.rst
+++ b/docs/hgmozilla/dag.rst
@@ -44,17 +44,17 @@ this file::
 
    $ hg add file
 
 We then use ``hg commit`` to create a new node (*changeset* in Mercurial
 parlance) and add it to the DAG::
 
    $ hg commit -m A
 
-(``-m A`` says to use ``A`` for the commit message.
+(``-m A`` says to use ``A`` for the commit message).
 
 Now let's take a look a the DAG::
 
    $ hg log -G -T '{desc}'
    @  A
 
 .. note::
 
@@ -330,17 +330,17 @@ head node as well).
 Because the visualization of the graph can resemble a tree (from
 nature, not your computer science textbooks), small *protrusions*
 from the main *trunk* are referred to as *branches* from the
 perspective of the DAG. (Mercurial has overloaded *branch* to convey
 additional semantics, so try not to confuse a *DAG branch* with
 a *Mercurial branch*.)
 
 The *created new head* message was Mercurial telling us that we
-created not only a a new *DAG head* but also a new *DAG branch*.
+created not only a new *DAG head* but also a new *DAG branch*.
 
 Because your commit is taking the repository in a different
 *direction* (very non-scientific word), this act of creating new
 DAG branches is sometimes referred to as *divergence* or *diverging*.
 
 DAG branches turn out to be an excellent way to work on separate
 and isolated units of change. These are often referred to as
 *feature branches* because each DAG branch consists of a specific

--- a/docs/mozreview/install-git.rst
+++ b/docs/mozreview/install-git.rst
@@ -60,17 +60,17 @@ To clone version-control-tools manually:
    $ git clone hg::https://hg.mozilla.org/hgcustom/version-control-tools
 
 .. note::
 
    We'll use ``vct`` as an abbreviation for *version-control-tools*.
 
 Next, tell Git to find Git commands located in the ``git/commands`` directory
 of this repository by updating your ``PATH`` environment variable (likely
-in your ``~/.profile`` or similar shell init script):
+in your ``~/.profile`` or similar shell init script)::
 
    $ export PATH=/path/to/vct/git/commands:$PATH
 
 .. tip::
 
    You likely updated your ``PATH`` variable as part of installing git-cinnabar.
    You should update the same thing to register version-control-tool's Git
    commands.