Add chmod line to the installation instructions (#134)

This PR adds a missing instruction to the installation docs. Moreover, it fixes a couple of awkward sentences in the top-level documents.

This addresses #133

INSTALL.md

@@ -1,6 +1,6 @@
 # Installation
 
-This document covers the installation of Fission Workflows.
+This document covers installing Fission Workflows.
 
 ### Prerequisites
 
@@ -69,7 +69,7 @@ curl ${FISSION_ROUTER}/fortunewhale
 ### wfcli client (optional)
 To use Fission Workflows there is no need to learn any other client other than the one you already use for function invocation - after all, a workflow is just another function.
 However, in many cases it is useful to have more insight in and control over the behaviour of the workflows (for example when developing/debugging workflows).
-To get these additional capabilities and insight, you can use the `wfcli` client.
+To get these more capabilities and insight, you can use the `wfcli` client.
 
 It has the following features:
 - Get insight into workflow and invocations statuses.
@@ -78,10 +78,11 @@ It has the following features:
 - validating workflow definitions locally.
 
 #### Installation
-To install `wfcli` either get a version of the binary from the [releases](https://github.com/fission/fission-workflows/releases).
+To install `wfcli` either download a version of the binary from the [releases](https://github.com/fission/fission-workflows/releases).
 For example, to download and install version 0.2.0,  assuming that you use OS X:
 ```bash
 curl -o wfcli https://github.com/fission/fission-workflows/releases/download/0.2.0/wfcli-osx
+chmod +x ./wfcli
 sudo mv ./wfcli /usr/local/bin
 ```
 
@@ -91,7 +92,7 @@ go get -u github.com/fission/fission-workflows/cmd/wfcli
 ```
 
 The `wfcli` client uses the `FISSION_URL` environment variable to find the Fission controller server to use as a proxy to the workflow apiserver.
-By default `wfcli` uses ttp://localhost:31313 as the location of the Fission controller.
+By default `wfcli` uses ttp://localhost:31313 to locate the Fission controller.
 
 #### Examples
 Get all defined workflows loaded in the workflow engine:

README.md

@@ -34,7 +34,7 @@ There are several ways to compose functions.  A function could invoke
 another function using the Fission API or HTTP.  But this requires the
 calling function to handle serialization, networking, etc.
 
-Functions could also be set up to be invoked via message queue topics.
+You could also set up functions to be invoked using message queue topics.
 This requires less boilerplate within each function, but the structure
 of the application is not explicit; dependencies are buried inside
 mappings of message queue topics to functions.
@@ -44,7 +44,7 @@ terms of error analysis, performance debugging, upgrades, etc.
 
 Workflows have been popular in other domains, such as data processing
 and scientific applications, and recently got introduced into the
-serverless paradigm by AWS Step Functions and Azure Logic Apps.
+serverless model by AWS Step Functions and Azure Logic Apps.
 
 Fission Workflows is an open-source alternative to these workflow
 systems.  It allows users to compose Fission functions in powerful
@@ -71,9 +71,9 @@ triggering parallel execution of two _branches_ with tasks C and D,
 followed by a _synchronizing task_ E collecting the outputs of the
 parallel tasks.
 
-Finally the graph concludes once _final task_ F has been completed.
+Finally the graph concludes once _final task_ F completes.
 
-Although Fission Workflows has additional functionality such as
+Although Fission Workflows has more functionality such as
 conditional branches and advanced control flow options, it
 fundamentally executes a dependency graph.
 
@@ -96,17 +96,16 @@ tasks:
 Currently there are two options of executing tasks.  First, Fission is
 used as the main function execution runtime, using _fission functions_
 as tasks.  Second, for very small tasks, such as flow control
-constructs, _internal functions_ are executed within the workflow
-engine, in order to minimize the network overhead.
+constructs, _internal functions_ execute within the workflow
+engine to minimize the network overhead.
 
-A workflow execution is called a **(Workflow) Invocation**.  An
-invocation is assigned a UID and is stored, persistently, in the data
-store of Fission Workflow.  This allows users to reference the
-invocation during and after the execution, for example to view the
+A workflow execution is called a **(Workflow) Invocation**. The Fission Workflows engine
+assigns an UID invocation and stores it, persistently, in the data-store.  This allows
+users to reference the invocation during and after the execution, such as to view the
 progress so far.
 
 Finally, **selectors** and **data transformations** are _inline
-functions_ which can be used to manipulate data without having to
+functions_ which you can use to manipulate data without having to
 create a task for it.  These _inline functions_ consist of commonly
 used transformations, such as getting the length of an array or
 string.  Additionally, selectors allow users to only pass through
@@ -152,7 +151,7 @@ See the [compilation guide](./compiling.md).
 
 This is an early release for community participation and user
 feedback. It is under active development; none of the interfaces are
-stable yet. It should not be used in production!
+stable yet. It should not yet be used in production!
 
 Contributions are welcome in whatever form, including testing,
 examples, use cases, or adding features. For an overview of current

compiling.md

@@ -10,7 +10,7 @@ images by default.*
 - [glide](http://glide.sh/) package manager
 
 ## Compilation
-Ensure that all requirements are met, and checkout the repo from github.
+Ensure that your environment meets all prerequisite requirements, and checkout the repo from github.
 
 ```bash
 # Install dependencies