grammar changes in docs

docs/codelab/orderfulfillment4.md

@@ -33,7 +33,7 @@ So, our new plan is to update the order every time widgets are shipped one for o
 
 You ask for the details of the API, and it turns out it is really simple:
 
-You send a post message to the endpont ```appendorder``` with the items and quantity:
+You send a post message to the endpoint ```appendorder``` with the items and quantity:
 
 ```json
 {"item": "widget", "count": "2"}'

docs/codelab/orderfulfillment5.md

@@ -65,7 +65,7 @@ We know that a 'good' response from the API reads: ```Success![number] widgets o
 
 A [Switch task](https://orkes.io/content/docs/reference-docs/switch-task) takes in a value, and can choose which case the workflow should follow.  There is a default case (in this workflow, we'll assume that a order will be placed), and then the alternative case is when the output reads "Order Failed".
 
-The switch case can evaulate the input in several ways (including running JavaScript), but in this case, we can use the ``` "evaluatorType": "value-param"``` meaning the decision will be bsaed completely on the data that comes in the ```switchCaseValue``` parameter. The ```switchCaseValue``` reads the output body from the API, and if it says "Order failed." we'll run a different pathway for the workflow.
+The switch case can evaluate the input in several ways (including running JavaScript), but in this case, we can use the ``` "evaluatorType": "value-param"``` meaning the decision will be based completely on the data that comes in the ```switchCaseValue``` parameter. The ```switchCaseValue``` reads the output body from the API, and if it says "Order failed." we'll run a different pathway for the workflow.
 
 
 ```json
@@ -247,7 +247,7 @@ In the definition below, we've hidden the bot token in the url. The message sent
 }
 ```
 
-Now, we have instrumented our Workflow to tell us when there is a failure- in rder to reduce the number of surprises:
+Now, we have instrumented our Workflow to tell us when there is a failure- inorder to reduce the number of surprises:
 
 <p align="center"><img src="/content/img/codelab/of5_failurebot.png" alt="slack message indicating workflow failure" width="400" style={{paddingBottom: 40, paddingTop: 40}} /></p>
 

docs/example_usecases.md

@@ -17,7 +17,7 @@ Conductor is a general-purpose orchestration engine that is language agnostic an
 7. Orchestrating Microservices ([HTTP](/content/docs/codelab/sequentialHTTPtasks),  background services, etc.)
 8. Orchestrating business logic across various cloud functions (AWS Lambda, GCP functions, etc.)
 9. Infrastructure Provisioning
-10. CICD Pipelines
+10. CI/CD Pipelines
 11. Long running processes and workflows
 12. Monitoring
 13. Distributed Transactions

docs/how-tos/Events/sqs_events.md

@@ -67,7 +67,7 @@ This Event does exactly what the name says, it will start a workflow run. In the
 
 ### Complete Task
 
-Imagine you have a workflow that requires a person to sign a document at Docusign.  There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. The message is sent to the `conductor_docusign_completed` SQS queue at AWS, which will fire this event:
+Imagine you have a workflow that requires a person to sign a document at DocuSign.  There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. The message is sent to the `conductor_docusign_completed` SQS queue at AWS, which will fire this event:
 
 ```json
 {
@@ -90,7 +90,7 @@ Imagine you have a workflow that requires a person to sign a document at Docusig
 
 ### Fail Task
 
-Imagine you have a workflow that requires a person to sign a document at Docusign.  There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. In this case, the human refused to sign the document, and the message is sent to the `conductor_docusign_failed` SQS queue at AWS, which will fire this event:
+Imagine you have a workflow that requires a person to sign a document at DocuSign.  There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. In this case, the human refused to sign the document, and the message is sent to the `conductor_docusign_failed` SQS queue at AWS, which will fire this event:
 
 ```json
 {

docs/how-tos/Tasks/SQS-event-task.md

@@ -5,7 +5,7 @@ Amazon's Simple Queueing Service (SQS) is a handy way to send messages across sy
 In this example, we will:
 
 * Configure Conductor for SQS messaging 
-* Set up an SQS mewssage queue at AWS
+* Set up an SQS message queue at AWS
 * Build a workflow with an EVENT task that sends messages to our SQS queue.
 * Add an EVENT to Conductor that will complete a WAIT event in the same workflow.
 
@@ -54,7 +54,7 @@ export  AWS_REGION = "{the region you are setting up the queue in}"
 
 ## Creating an SQS Queue
 
-In your AWS account, open Amazon SQS (search for it in the search bar), and choose `Create queue`. Create a queue by entering a name, and scrolling to the botttom to `create queue`.  In a minute or so, your new queue will appear in the queue list.
+In your AWS account, open Amazon SQS (search for it in the search bar), and choose `Create queue`. Create a queue by entering a name, and scrolling to the bottom to `create queue`.  In a minute or so, your new queue will appear in the queue list.
 
 <p align="center"><img src="/content/img/sqs_queue_list.jpg" alt="filtered SQS queue list" width="800" style={{paddingBottom: 40, paddingTop: 40}} /></p>
 
@@ -68,7 +68,7 @@ This workflow has two forks:
 
 * On the left fork there is just one task `task_1`.  It is a WAIT task, and it is waiting for a message from the SQS server.
 > Note: for the SQS message to COMPLETE the task, we'll need to create a Conductor EVENT.
-* The right fork has two tasks. `task_2` is also a WAIT task, but it just waits for 10s before completing and moving the workflow ahead.  On the completetion of `task_2`, the EVENT task `send_sqs_messsage` fires.
+* The right fork has two tasks. `task_2` is also a WAIT task, but it just waits for 10s before completing and moving the workflow ahead.  On the completion of `task_2`, the EVENT task `send_sqs_messsage` fires.
 
 The reason for the delay in `task_2` to is to ensure that `task_1` is initialized and waiting for the event to come in before the SQS message is sent out.
 

docs/how-tos/Tasks/reusing-tasks.md

@@ -10,7 +10,7 @@ workflows. Once a task is defined, you can re use multiple times in the same wor
 
 When re-using tasks, it's important to think of situations that a multi-tenant system faces. All the work assigned to
 this worker by default goes to the same task scheduling queue. This could result in your worker not being polled quickly
-if there is a noisy neighbour in the ecosystem. One way you can tackle this situation is by re-using the worker code,
+if there is a noisy neighbor in the ecosystem. One way you can tackle this situation is by re-using the worker code,
 but having different task names registered for different use cases. And for each task name, you can run an appropriate
 number of workers based on expected load.
 

docs/running-workflows/execute-workflow.md

@@ -4,7 +4,7 @@ sidebar_position: 1
 
 # Executing Workflows
 
-A workflow can be exexcuted in three different ways as listed below. In all of these, once the invocation is made, Conductor will return a WorkflowID that you can use to [view the execution status of the invocation](../how-tos/Workflows/view-workflow-executions.md)
+A workflow can be executed in three different ways as listed below. In all of these, once the invocation is made, Conductor will return a WorkflowID that you can use to [view the execution status of the invocation](../how-tos/Workflows/view-workflow-executions.md)
 ## Start a workflow by calling an API
 TODO
 ## Start a workflow by posting an event

docs/what-use-cases-can-conductor-solve.md

@@ -19,7 +19,7 @@ Some common use cases that has been solved by Conductor are:
 8. Orchestrating Microservices (HTTP,  background services, etc.)
 9. Orchestrating Business Logic across various cloud functions (AWS Lambda, GCP functions, etc.)
 10. Infrastructure Provisioning
-11. CI CD Pipelines
+11. CI/CD Pipelines
 12. Long-running Processes and Workflows
 13. Monitoring
 14. Distributed Transactions