Fixed several minor misspellings and acronym capitalizations.

doc/index.rst

@@ -15,7 +15,7 @@ for orchestration, remote execution, configuration management and much more.
 Download
 ========
 
-Salt source releases are available for download via pypi:
+Salt source releases are available for download via PyPI:
 
     https://pypi.python.org/pypi/salt
 
@@ -201,7 +201,7 @@ Salt is many splendid things.
     Looking for an easy way to manage software on Windows machines? 
     Search no more! Salt has an integrated software package manager for
     Windows machines! Install software hosted on the master, somewhere on the
-    network, or any http, https, or ftp server.
+    network, or any HTTP, HTTPS, or ftp server.
 
 Reference
 ---------

doc/ref/cli/salt.rst

@@ -32,7 +32,7 @@ Options
 .. option:: -t TIMEOUT, --timeout=TIMEOUT
 
     The timeout in seconds to wait for replies from the Salt minions. The
-    timeout number specifes how long the command line client will wait to
+    timeout number specifies how long the command line client will wait to
     query the minions and check on running jobs.
 
 .. option:: -s, --static

doc/ref/clientacl.rst

@@ -2,10 +2,10 @@
 Client ACL system
 =================
 
-The salt client acl system is a means to allow system users other than root to
+The salt client ACL system is a means to allow system users other than root to
 have access to execute select salt commands on minions from the master.
 
-The client acl system is configured in the master configuration file via the
+The client ACL system is configured in the master configuration file via the
 ``client_acl`` configuration option. Under the ``client_acl`` configuration
 option the users open to send commands are specified and then a list of regular
 expressions which specify the minion functions which will be made available to

doc/ref/configuration/master.rst

@@ -72,7 +72,7 @@ seeing on the console(and then salt-master crashes)::
   Too many open files (tcp_listener.cpp:335)
   Aborted (core dumped)
 
-By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
+By default this value will be the one of `ulimit -Hn`, i.e., the hard limit for
 max open files.
 
 If you wish to set a different value than the default one, uncomment and
@@ -409,7 +409,7 @@ at the moment a single state fails
 
 Default:: ``False``
 
-Set all state calls to only test if they are going to acctually make changes
+Set all state calls to only test if they are going to actually make changes
 or just post what changes are going to be made
 
 .. code-block:: yaml
@@ -426,7 +426,7 @@ Master File Server Settings
 
 Default: ``base: [/srv/salt]``
 
-Salt runs a lightweight file server written in zeromq to deliver files to
+Salt runs a lightweight file server written in ZeroMQ to deliver files to
 minions. This file server is built into the master daemon and does not
 require a dedicated port.
 
@@ -706,7 +706,7 @@ One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
 
 Default: ``%H:%M:%S``
 
-The date and time format used in console log messages. Allowed date/time formating
+The date and time format used in console log messages. Allowed date/time formatting
 can be seen on http://docs.python.org/library/time.html#time.strftime
 
 .. code-block:: yaml
@@ -720,7 +720,7 @@ can be seen on http://docs.python.org/library/time.html#time.strftime
 
 Default: ``%Y-%m-%d %H:%M:%S``
 
-The date and time format used in log file messages. Allowed date/time formating
+The date and time format used in log file messages. Allowed date/time formatting
 can be seen on http://docs.python.org/library/time.html#time.strftime
 
 .. code-block:: yaml
@@ -762,7 +762,7 @@ be seen on http://docs.python.org/library/logging.html#logrecord-attributes
 
 Default: ``{}``
 
-This can be used to control logging levels more specificically.  The
+This can be used to control logging levels more specifically.  The
 example sets the main salt library at the 'warning' level, but sets 
 'salt.modules' to log at the 'debug' level:
 

doc/ref/configuration/minion.rst

@@ -180,7 +180,7 @@ executed. By default this feature is disabled, to enable set cache_jobs to
 
 Default: ``/var/run/salt/minion``
 
-The directory where unix sockets will be kept.
+The directory where Unix sockets will be kept.
 
 .. code-block:: yaml
 
@@ -235,7 +235,7 @@ environment, set this value to ``False``.
 
 Default: ``ipc``
 
-Windows platforms lack posix IPC and must rely on slower TCP based inter-
+Windows platforms lack POSIX IPC and must rely on slower TCP based inter-
 process communications. Set ipc_mode to ``tcp`` on such systems.
 
 .. code-block:: yaml
@@ -450,7 +450,7 @@ Default: ``True``
 
 autoload_dynamic_modules Turns on automatic loading of modules found in the
 environments on the master. This is turned on by default, to turn of
-autoloading modules when states run set this value to ``False``
+auto-loading modules when states run set this value to ``False``
 
 .. code-block:: yaml
 
@@ -579,7 +579,7 @@ One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
 
 Default: ``%H:%M:%S``
 
-The date and time format used in console log messages. Allowed date/time formating
+The date and time format used in console log messages. Allowed date/time formatting
 can be seen on http://docs.python.org/library/time.html#time.strftime
 
 .. code-block:: yaml
@@ -593,7 +593,7 @@ can be seen on http://docs.python.org/library/time.html#time.strftime
 
 Default: ``%Y-%m-%d %H:%M:%S``
 
-The date and time format used in log file messages. Allowed date/time formating
+The date and time format used in log file messages. Allowed date/time formatting
 can be seen on http://docs.python.org/library/time.html#time.strftime
 
 .. code-block:: yaml
@@ -635,7 +635,7 @@ be seen on http://docs.python.org/library/logging.html#logrecord-attributes
 
 Default: ``{}``
 
-This can be used to control logging levels more specificically.  This
+This can be used to control logging levels more specifically.  This
 example sets the main salt library at the 'warning' level, but sets 
 'salt.modules' to log at the 'debug' level:
 

doc/ref/file_server/index.rst

@@ -46,7 +46,7 @@ like so:
     # salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja
 
 This example would instruct all Salt minions to download the vimrc from a
-directory with the same name as their os grain and copy it to /etc/vimrc
+directory with the same name as their OS grain and copy it to /etc/vimrc
 
 For larger files, the cp.get_file module also supports gzip compression.
 Because gzip is CPU-intensive, this should only be used in

doc/ref/index.rst

@@ -15,7 +15,7 @@ Client API
 ----------
 
 The primary interface used to extend Salt, is to simply use it. Salt executions
-can be called via the Salt client api, making programming master side solutions
+can be called via the Salt client API, making programming master side solutions
 with Salt is easy.
 
 Adding Loadable Plugins
@@ -70,7 +70,7 @@ Renderers
 `````````
 
 Salt states are controlled by simple data structures, these structures can be
-abstracted in a number of ways. While the default is to be in a yaml file
+abstracted in a number of ways. While the default is to be in a YAML file
 wrapped in a jinja template, any abstraction can be used. This means that any
 format that can be dreamed is possible, so long as a renderer is written for
 it.

doc/ref/modules/all/salt.modules.yumpkg.rst

@@ -4,7 +4,7 @@ salt.modules.yumpkg
 
 .. versionadded:: 0.9.4
     This module replaces the "yum" module in previous releases. It is backward
-    compatibile and uses the native yum Python interface instead of the CLI
+    compatible and uses the native yum Python interface instead of the CLI
     interface.
 
 .. automodule:: salt.modules.yumpkg

doc/ref/modules/index.rst

@@ -171,7 +171,7 @@ documentation for all available modules:
     salt '*' sys.doc
 
 This function simple prints out the docstrings found in the modules, when
-writing Salt modules, please follow the formating conventions for docstrings as
+writing Salt modules, please follow the formatting conventions for docstrings as
 they appear in the other modules.
 
 Adding Documentation to Salt Modules

doc/ref/python-api.rst

@@ -9,7 +9,7 @@ built directly into third party applications as a communication layer. The Salt
 client API is very straightforward.
 
 A number of client command methods are available depending on the exact
-behaviour desired.
+behavior desired.
 
 Using the LocalClient API
 =========================
@@ -38,7 +38,7 @@ same interface used by the ``salt`` command line tool.
 
     The tgt option is the target specification, by default a target is passed
     in as a bash shell glob. The expr_form option allows the tgt to be passed
-    as either a pcre regular expression or as a Python list.
+    as either a PCRE regular expression or as a Python list.
 
 .. cmdoption:: fun
 

doc/ref/renderers/all/salt.renderers.stateconf.rst

@@ -9,7 +9,7 @@ salt.renderers.stateconf
 :platform: all
 
 This module provides a custom renderer that process a salt file with a
-specified templating engine(eg, jinja) and a chosen data renderer(eg, yaml),
+specified templating engine(e.g., Jinja) and a chosen data renderer(e.g., YAML),
 extract arguments for any ``stateconf.set`` state and provide the extracted
 arguments (including salt specific args, such as 'require', etc) as template
 context. The goal is to make writing reusable/configurable/ parameterized
@@ -48,7 +48,7 @@ Here's a list of features enabled by this renderer.
 
   The leading dot trick can be used with extending state ids as well,
   so you can include relatively and extend relatively. For example, when
-  extending a state in `salt://some/other_file.sls`, eg,::
+  extending a state in `salt://some/other_file.sls`, e.g.,::
 
       #!stateconf yaml . jinja
 
@@ -75,7 +75,7 @@ Here's a list of features enabled by this renderer.
   reference templates files used by your salt file.
 
 - Recognizes the special state function, ``stateconf.set``, that configures a
-  default list of named arguments useable within the template context of
+  default list of named arguments usable within the template context of
   the salt file. Example::
 
       #!stateconf yaml . jinja
@@ -174,7 +174,7 @@ Here's a list of features enabled by this renderer.
 
 
 - Optionally(enabled by default, *disable* via the `-G` renderer option,
-  eg, in the shebang line: ``#!stateconf -G``), generates a
+  e.g., in the shebang line: ``#!stateconf -G``), generates a
   ``stateconf.set`` goal state(state id named as ``.goal`` by default,
   configurable via the master/minion config option, ``stateconf_goal_state``)
   that requires all other states in the salt file. Note, the ``.goal``
@@ -186,7 +186,7 @@ Here's a list of features enabled by this renderer.
   all states in the Tomcat sls file will be executed before some state in
   the webapp sls file.
 
-- Optionally(enable via the `-o` renderer option, eg, in the shebang line:
+- Optionally(enable via the `-o` renderer option, e.g., in the shebang line:
   ``#!stateconf -o``), orders the states in a sls file by adding a
   ``require`` requisite to each state such that every state requires the
   state defined just before it. The order of the states here is the order
@@ -202,7 +202,7 @@ Here's a list of features enabled by this renderer.
   there are many states defined in a sls file, then it tends to be easier
   to see the order they will be executed with this feature.
 
-  You are still allowed to use all the requisites, with a few restricitons.
+  You are still allowed to use all the requisites, with a few restrictions.
   You cannot ``require`` or ``watch`` a state defined *after* the current
   state. Similarly, in a state, you cannot ``require_in`` or ``watch_in``
   a state defined *before* it. Breaking any of the two restrictions above

doc/ref/renderers/index.rst

@@ -14,7 +14,7 @@ the SLS files can be any structured format that can be dreamed up.
 Currently there is support for ``Jinja + YAML``, ``Mako + YAML``, 
 ``Wempy + YAML``, ``Jinja + json`` ``Mako + json`` and ``Wempy + json``. But
 renderers can be written to support anything. This means that the Salt states
-could be managed by xml files, html files, puppet files, or any format that
+could be managed by XML files, HTML files, puppet files, or any format that
 can be translated into the data structure used by the state system.
 
 Multiple Renderers
@@ -49,7 +49,7 @@ Composing Renderers
 -------------------
 A renderer can be composed from other renderers by connecting them in a series
 of pipes(``|``). In fact, the default ``Jinja + YAML`` renderer is implemented
-by combining a yaml renderer and a jinja renderer. Such renderer configuration
+by combining a YAML renderer and a Jinja renderer. Such renderer configuration
 is specified as: ``jinja | yaml``.
 
 Other renderer combinations are possible, here's a few examples:
@@ -63,7 +63,7 @@ Other renderer combinations are possible, here's a few examples:
 
   ``jinja | mako | yaml``
       This one allows you to use both jinja and mako templating syntax in the
-      input and then parse the final rendererd output as YAML.
+      input and then parse the final rendered output as YAML.
 
 And here's a contrived example sls file using the ``jinja | mako | yaml`` renderer:
 

doc/ref/returners/index.rst

@@ -59,7 +59,7 @@ A simple returner is implemented here:
         '''
         Return information to a redis server
         '''
-        # Get a redis commection
+        # Get a redis connection
         serv = redis.Redis(
                     host='redis-serv.example.com',
                     port=6379,

doc/ref/states/index.rst

@@ -91,9 +91,9 @@ SLS Files
 
 The Salt state files are simple sets of data. Since the SLS files are just data
 they can be represented in a number of different ways. The default format is
-yaml generated from a jinja template. This allows for the states files to have
+yaml generated from a Jinja template. This allows for the states files to have
 all the language constructs of Python and the simplicity of yaml. State files
-can then be complicated jinja templates that translate down to yaml, or just
+can then be complicated Jinja templates that translate down to yaml, or just
 plain and simple yaml files!
 
 The State files are constructed data structures in a simple format. The format
@@ -179,9 +179,9 @@ source code:
 
 :blob:`salt/renderers`
 
-By default SLS files are rendered using jinja as a templating engine, and yaml
+By default SLS files are rendered using Jinja as a templating engine, and yaml
 as the serialization format. Since the rendering system can be extended simply
 by adding a new renderer to the renderers directory, it is possible that any
 structured file could be used to represent the SLS files.
 
-In the future xml and raw Python will be added, as well as many other formats.
+In the future XML and raw Python will be added, as well as many other formats.

doc/ref/states/requisites.rst

@@ -4,7 +4,7 @@ Requisites
 
 The Salt requisite system is used to create relationships between states. The
 core idea being, that when one state it dependent somehow on another that
-interdependency can be easily defined.
+inter-dependency can be easily defined.
 
 Requisites come in two types. Direct requisites, and requisite_ins. The
 relationships are directional, so a requisite statement makes the requiring
@@ -133,8 +133,8 @@ Using ``require_in``
         - running
 
 The ``require_in`` statement is particularly useful when assigning a require
-in a sperate sls file. For instance it may be common for httpd to require
-components used to set up php or mod_python, but the http state does not need
+in a separate sls file. For instance it may be common for httpd to require
+components used to set up PHP or mod_python, but the HTTP state does not need
 to be aware of the additional components that require it when it is set up:
 
 http.sls

doc/ref/states/writing.rst

@@ -17,7 +17,7 @@ illustrate:
 .. code-block:: yaml
 
     /etc/salt/master: # maps to "name"
-      file: # maps to State module filename eg https://github.com/saltstack/salt/blob/develop/salt/states/file.py
+      file: # maps to State module filename e.g. https://github.com/saltstack/salt/blob/develop/salt/states/file.py
         - managed # maps to the managed function in the file State module
         - user: root # one of many options passed to the manage function
         - group: root

doc/ref/syndic.rst

@@ -19,7 +19,7 @@ Configuring the Syndic
 Since the Syndic only needs to be attached to a higher level master the
 configuration is very simple. On a master that is running a syndic to connect
 to a higher level master the syndic_master option needs to be set in the
-master config file. The syndic_master option contains the hostname or ip
+master config file. The syndic_master option contains the hostname or IP
 address of the master server that can control the master that the syndic is
 running on.
 

doc/ref/topology.rst

@@ -13,7 +13,7 @@ The Salt Master runs 2 network services. First is the ZeroMQ PUB system. This
 service by default runs on port ``4505`` and can be configured via the
 ``publish_port`` option in the master configuration.
 
-Second is the ZeroMQ REP system. This is a seperate interface used for all
+Second is the ZeroMQ REP system. This is a separate interface used for all
 bi-directional communication with minions. By default this system binds to
 port ``4506`` and can be configured via the ``ret_port`` option in the master.
 
@@ -22,8 +22,8 @@ PUB/SUB
 
 The commands sent out via the salt client are broadcast out to the minions via
 ZeroMQ PUB/SUB. This is done by allowing the minions to maintain a connection
-back to the Salt Master and then all connecions are informed to download the
-command data at once. The command data is kept extreamly small (usually less
+back to the Salt Master and then all connections are informed to download the
+command data at once. The command data is kept extremely small (usually less
 than 1K) so it is not a burden on the network.
 
 Return