Merge pull request #5567 from risaacson/doc_corrections

A few documentation corrections

docsite/rst/developing_modules.rst

@@ -91,7 +91,7 @@ The example usage we are trying to achieve to set the time is::
 
 If no time parameter is set, we'll just leave the time as is and return the current time.
 
-.. note:
+.. note::
    This is obviously an unrealistic idea for a module.  You'd most likely just
    use the shell module.  However, it probably makes a decent tutorial.
 

docsite/rst/guide_rolling_upgrade.rst

@@ -75,7 +75,7 @@ as push updates to all of the servers::
       - base-apache
       - nagios
 
-.. note:
+.. note::
 
    If you're not familiar with terms like playbooks and plays, you should review :doc:`playbooks`.
 

docsite/rst/playbooks_intro.rst

@@ -96,7 +96,7 @@ documentation.  The `remote_user` is just the name of the user account::
     - hosts: webservers
       remote_user: root
 
-.. Note::
+.. note::
 
     The `remote_user` parameter was formerly called just `user`. It was renamed in Ansible 1.4 to make it more distinguishable from the `user` module (used to create users on remote systems).
 
@@ -110,7 +110,7 @@ Remote users can also be defined per task::
           ping:
           remote_user: yourname
 
-.. Note::
+.. note::
 
     The `remote_user` parameter for tasks was added in 1.4.
 
@@ -203,9 +203,9 @@ the service module takes key=value arguments::
      - name: make sure apache is running
        service: name=httpd state=running
 
-The `command` and `shell` modules are the one modules that just takes a list
-of arguments, and don't use the key=value form.  This makes
-them work just like you would expect. Simple::
+The `command` and `shell` modules are the only modules that just take a list
+of arguments and don't use the key=value form.  This makes
+them work as simply as you would expect::
 
    tasks:
      - name: disable selinux

docsite/rst/playbooks_variables.rst

@@ -110,7 +110,7 @@ it's more than that -- you can also read variables about other hosts.  We'll sho
 Jinja2 Filters
 ``````````````
 
-.. note: These are infrequently utilized features.  Use them if they fit a use case you have, but this is optional knowledge.
+.. note:: These are infrequently utilized features.  Use them if they fit a use case you have, but this is optional knowledge.
 
 Filters in Jinja2 are a way of transforming template expressions from one kind of data into another.  Jinja2
 ships with many of these as documented on the official Jinja2 template documentation.
@@ -737,7 +737,7 @@ or in a file as above.
 Conditional Imports
 ```````````````````
 
-.. note: this behavior is infrequently used in Ansible.  You may wish to skip this section.  The 'group_by' module as described in the module documentation is a better way to achieve this behavior in most cases.
+.. note:: This behavior is infrequently used in Ansible.  You may wish to skip this section.  The 'group_by' module as described in the module documentation is a better way to achieve this behavior in most cases.
 
 Sometimes you will want to do certain things differently in a playbook based on certain criteria.
 Having one playbook that works on multiple platforms and OS versions is a good example.