Merge pull request #1160 from shapeshed/patch-1

Fix documentation typos

docs/deploy-testnets.rst

@@ -48,7 +48,7 @@ Automated Deployment using Kubernetes
 
 The `mintnet-kubernetes tool <https://github.com/tendermint/tools/tree/master/mintnet-kubernetes>`__
 allows automating the deployment of a Tendermint network on an already
-provisioned kubernetes cluster. For simple provisioning of a kubernetes
+provisioned Kubernetes cluster. For simple provisioning of a Kubernetes
 cluster, check out the `Google Cloud Platform <https://cloud.google.com/>`__.
 
 Automated Deployment using Terraform and Ansible

docs/getting-started.rst

@@ -40,7 +40,7 @@ dependencies:
 Now you should have the ``abci-cli`` installed; you'll see
 a couple of commands (``counter`` and ``dummy``) that are
 example applications written in Go. See below for an application
-written in Javascript.
+written in JavaScript.
 
 Now, let's run some apps!
 
@@ -49,7 +49,7 @@ Dummy - A First Example
 
 The dummy app is a `Merkle
 tree <https://en.wikipedia.org/wiki/Merkle_tree>`__ that just stores all
-transactions. If the transaction contains an ``=``, eg. ``key=value``,
+transactions. If the transaction contains an ``=``, e.g. ``key=value``,
 then the ``value`` is stored under the ``key`` in the Merkle tree.
 Otherwise, the full transaction bytes are stored as the key and the
 value.

docs/install.rst

@@ -9,7 +9,7 @@ To download pre-built binaries, see the `Download page <https://tendermint.com/d
 From Source
 -----------
 
-You'll need ``go``, maybe ``glide``, and the tendermint source code.
+You'll need ``go``, maybe ``glide``, and the Tendermint source code.
 
 Install Go
 ^^^^^^^^^^

docs/introduction.rst

@@ -112,7 +112,7 @@ Motivation
 Thus far, all blockchains "stacks" (such as `Bitcoin <https://github.com/bitcoin/bitcoin>`__) have had a monolithic design. That is, each blockchain stack is a single program that handles all the concerns of a decentralized ledger; this includes P2P connectivity, the "mempool" broadcasting of transactions, consensus on the most recent block, account balances, Turing-complete contracts, user-level permissions, etc.
 
 Using a monolithic architecture is typically bad practice in computer science.
-It makes it difficult to reuse components of the code, and attempts to do so result in complex maintanence procedures for forks of the codebase.
+It makes it difficult to reuse components of the code, and attempts to do so result in complex maintenance procedures for forks of the codebase.
 This is especially true when the codebase is not modular in design and suffers from "spaghetti code".
 
 Another problem with monolithic design is that it limits you to the language of the blockchain stack (or vice versa).  In the case of Ethereum which supports a Turing-complete bytecode virtual-machine, it limits you to languages that compile down to that bytecode; today, those are Serpent and Solidity.

docs/using-tendermint.rst

@@ -34,7 +34,7 @@ tool <https://github.com/tendermint/tools/tree/master/mintnet-kubernetes>`__.
 Run
 ---
 
-To run a tendermint node, use
+To run a Tendermint node, use
 
 ::
 
@@ -42,7 +42,7 @@ To run a tendermint node, use
 
 By default, Tendermint will try to connect to an ABCI application on
 `127.0.0.1:46658 <127.0.0.1:46658>`__. If you have the ``dummy`` ABCI
-app installed, run it in another window. If you don't, kill tendermint
+app installed, run it in another window. If you don't, kill Tendermint
 and run an in-process version with
 
 ::
@@ -55,7 +55,7 @@ blocks are produced regularly, even if there are no transactions. See *No Empty
 Tendermint supports in-process versions of the dummy, counter, and nil
 apps that ship as examples in the `ABCI
 repository <https://github.com/tendermint/abci>`__. It's easy to compile
-your own app in-process with tendermint if it's written in Go. If your
+your own app in-process with Tendermint if it's written in Go. If your
 app is not written in Go, simply run it in another process, and use the
 ``--proxy_app`` flag to specify the address of the socket it is
 listening on, for instance:
@@ -170,8 +170,8 @@ Tendermint uses a ``config.toml`` for configuration. For details, see
 `the config specification <./specification/configuration.html>`__.
 
 Notable options include the socket address of the application
-(``proxy_app``), the listenting address of the tendermint peer
-(``p2p.laddr``), and the listening address of the rpc server
+(``proxy_app``), the listening address of the Tendermint peer
+(``p2p.laddr``), and the listening address of the RPC server
 (``rpc.laddr``).
 
 Some fields from the config file can be overwritten with flags.
@@ -185,8 +185,8 @@ once per second, it is possible to disable empty blocks or set a block creation
 interval. In the former case, blocks will be created when there are new
 transactions or when the AppHash changes.
 
-To configure tendermint to not produce empty blocks unless there are
-transactions or the app hash changes, run tendermint with this additional flag:
+To configure Tendermint to not produce empty blocks unless there are 
+transactions or the app hash changes, run Tendermint with this additional flag:
 
 ::
 
@@ -215,7 +215,7 @@ Broadcast API
 -------------
 
 Earlier, we used the ``broadcast_tx_commit`` endpoint to send a
-transaction. When a transaction is sent to a tendermint node, it will
+transaction. When a transaction is sent to a Tendermint node, it will
 run via ``CheckTx`` against the application. If it passes ``CheckTx``,
 it will be included in the mempool, broadcast to other peers, and
 eventually included in a block.
@@ -242,7 +242,7 @@ value for ``broadcast_tx_commit`` includes two fields, ``check_tx`` and
 through those ABCI messages.
 
 The benefit of using ``broadcast_tx_commit`` is that the request returns
-after the transaction is committed (ie. included in a block), but that
+after the transaction is committed (i.e. included in a block), but that
 can take on the order of a second. For a quick result, use
 ``broadcast_tx_sync``, but the transaction will not be committed until
 later, and by that point its effect on the state may change.
@@ -306,9 +306,9 @@ Note also that the ``pub_key`` (the public key) in the
 
 The genesis file contains the list of public keys which may participate in the
 consensus, and their corresponding voting power. Greater than 2/3 of the voting
-power must be active (ie. the corresponding private keys must be producing
+power must be active (i.e. the corresponding private keys must be producing
 signatures) for the consensus to make progress. In our case, the genesis file
-contains the public key of our ``priv_validator.json``, so a tendermint node
+contains the public key of our ``priv_validator.json``, so a Tendermint node
 started with the default root directory will be able to make progress. Voting
 power uses an `int64` but must be positive, thus the range is: 0 through
 9223372036854775807. Because of how the current proposer selection algorithm works,
@@ -461,7 +461,7 @@ connections to peers with the same IP address.
 Upgrading
 ~~~~~~~~~
 
-The tendermint development cycle includes a lot of breaking changes. Upgrading from
+The Tendermint development cycle includes a lot of breaking changes. Upgrading from
 an old version to a new version usually means throwing away the chain data. Try out
 the `tm-migrate <https://github.com/hxzqlh/tm-tools>`__ tool written by @hxqlh if
 you are keen to preserve the state of your chain when upgrading to newer versions.