Merge "Fix a couple of spelling and grammar errors"0.8.1

7 files changed, 16 insertions, 16 deletions

diff --git a/doc/source/arguments_and_results.rst b/doc/source/arguments_and_results.rst
index e4f7999..009086b 100644
--- a/doc/source/arguments_and_results.rst
+++ b/doc/source/arguments_and_results.rst
@@ -416,7 +416,7 @@ the following history (printed as a list)::
 At this point (since the implementation returned ``RETRY``) the
 |retry.execute| method will be called again and it will receive the same
 history and it can then return a value that subseqent tasks can use to alter
-there behavior.
+their behavior.
 
 If instead the |retry.execute| method itself raises an exception,
 the |retry.revert| method of the implementation will be called and
diff --git a/doc/source/atoms.rst b/doc/source/atoms.rst
index c54eb57..9c2827b 100644
--- a/doc/source/atoms.rst
+++ b/doc/source/atoms.rst
@@ -91,7 +91,7 @@ subclasses are provided:
 .. note::
 
     They are *similar* to exception handlers but are made to be *more* capable
-    due to there ability to *dynamically* choose a reconciliation strategy,
+    due to their ability to *dynamically* choose a reconciliation strategy,
     which allows for these atoms to influence subsequent execution(s) and the
     inputs any associated atoms require.
 
diff --git a/doc/source/engines.rst b/doc/source/engines.rst
index 988d111..3c3d757 100644
--- a/doc/source/engines.rst
+++ b/doc/source/engines.rst
@@ -29,7 +29,7 @@ Why they exist
 An engine being *the* core component which actually makes your flows progress
 is likely a new concept for many programmers so let's describe how it operates
 in more depth and some of the reasoning behind why it exists. This will
-hopefully make it more clear on there value add to the TaskFlow library user.
+hopefully make it more clear on their value add to the TaskFlow library user.
 
 First though let us discuss something most are familiar already with; the
 difference between `declarative`_ and `imperative`_ programming models. The
@@ -57,7 +57,7 @@ declarative model) allows for the following functionality to become possible:
   accomplished allows for a *natural* way of resuming by allowing the engine to
   track the current state and know at which point a workflow is in and how to
   get back into that state when resumption occurs.
-* Enhancing scalability: When a engine is responsible for executing your
+* Enhancing scalability: When an engine is responsible for executing your
   desired work it becomes possible to alter the *how* in the future by creating
   new types of execution backends (for example the `worker`_ model which does
   not execute locally). Without the decoupling of the *what* and the *how* it
@@ -203,7 +203,7 @@ For further information, please refer to the the following:
 How they run
 ============
 
-To provide a peek into the general process that a engine goes through when
+To provide a peek into the general process that an engine goes through when
 running lets break it apart a little and describe what one of the engine types
 does while executing (for this we will look into the
 :py:class:`~taskflow.engines.action_engine.engine.ActionEngine` engine type).
@@ -299,7 +299,7 @@ Scheduling
 
 This stage selects which atoms are eligible to run by using a
 :py:class:`~taskflow.engines.action_engine.scheduler.Scheduler` implementation
-(the default implementation looks at there intention, checking if predecessor
+(the default implementation looks at their intention, checking if predecessor
 atoms have ran and so-on, using a
 :py:class:`~taskflow.engines.action_engine.analyzer.Analyzer` helper
 object as needed) and submits those atoms to a previously provided compatible
@@ -335,7 +335,7 @@ above stages will be restarted and resuming will occur).
 
     If the engine is suspended while the engine is going through the above
     stages this will stop any further scheduling stages from occurring and
-    all currently executing atoms will be allowed to finish (and there results
+    all currently executing atoms will be allowed to finish (and their results
     will be saved).
 
 Finishing
@@ -366,7 +366,7 @@ be selected?
 Default strategy
 ----------------
 
-When a engine is executing it internally interacts with the
+When an engine is executing it internally interacts with the
 :py:class:`~taskflow.storage.Storage` class
 and that class interacts with the a
 :py:class:`~taskflow.engines.action_engine.scopes.ScopeWalker` instance
diff --git a/doc/source/jobs.rst b/doc/source/jobs.rst
index 06f1123..d25436c 100644
--- a/doc/source/jobs.rst
+++ b/doc/source/jobs.rst
@@ -43,7 +43,7 @@ Jobboards
   jobboards implement the same interface and semantics so that the backend
   usage is as transparent as possible. This allows deployers or developers of a
   service that uses TaskFlow to select a jobboard implementation that fits
-  their setup (and there intended usage) best.
+  their setup (and their intended usage) best.
 
 High level architecture
 =======================
@@ -218,7 +218,7 @@ Dual-engine jobs
 ----------------
 
 **What:** Since atoms and engines are not currently `preemptable`_ we can not
-force a engine (or the threads/remote workers... it is using to run) to stop
+force an engine (or the threads/remote workers... it is using to run) to stop
 working on an atom (it is general bad behavior to force code to stop without
 its consent anyway) if it has already started working on an atom (short of
 doing a ``kill -9`` on the running interpreter).  This could cause problems
diff --git a/doc/source/persistence.rst b/doc/source/persistence.rst
index 53b01aa..a0731a3 100644
--- a/doc/source/persistence.rst
+++ b/doc/source/persistence.rst
@@ -70,7 +70,7 @@ from a previous run) they will begin executing only after any dependent inputs
 are ready. This is done by analyzing the execution graph and looking at
 predecessor :py:class:`~taskflow.persistence.logbook.AtomDetail` outputs and
 states (which may have been persisted in a past run). This will result in
-either using there previous information or by running those predecessors and
+either using their previous information or by running those predecessors and
 saving their output to the :py:class:`~taskflow.persistence.logbook.FlowDetail`
 and :py:class:`~taskflow.persistence.base.Backend` objects. This
 execution, analysis and interaction with the storage objects continues (what is
@@ -81,7 +81,7 @@ will have succeeded or failed in its attempt to run the workflow).
 **Post-execution:** Typically when an engine is done running the logbook would
 be discarded (to avoid creating a stockpile of useless data) and the backend
 storage would be told to delete any contents for a given execution. For certain
-use-cases though it may be advantageous to retain logbooks and there contents.
+use-cases though it may be advantageous to retain logbooks and their contents.
 
 A few scenarios come to mind:
 
diff --git a/doc/source/states.rst b/doc/source/states.rst
index bba8d20..9cc7a50 100644
--- a/doc/source/states.rst
+++ b/doc/source/states.rst
@@ -121,7 +121,7 @@ or if needed will wait for all of the atoms it depends on to complete.
 
 .. note::
 
-  A engine running a task also transitions the task to the ``PENDING`` state
+  An engine running a task also transitions the task to the ``PENDING`` state
   after it was reverted and its containing flow was restarted or retried.
 
 **RUNNING** - When an engine running the task starts to execute the task, the
@@ -168,10 +168,10 @@ flow that the retry is associated with by consulting its
 
 .. note::
 
-  A engine running a retry also transitions the retry to the ``PENDING`` state
+  An engine running a retry also transitions the retry to the ``PENDING`` state
   after it was reverted and its associated flow was restarted or retried.
 
-**RUNNING** - When a engine starts to execute the retry, the engine
+**RUNNING** - When an engine starts to execute the retry, the engine
 transitions the retry to the ``RUNNING`` state, and the retry stays in this
 state until its :py:meth:`~taskflow.retry.Retry.execute` method returns.
 
diff --git a/doc/source/workers.rst b/doc/source/workers.rst
index 01058b7..3821240 100644
--- a/doc/source/workers.rst
+++ b/doc/source/workers.rst
@@ -409,7 +409,7 @@ Limitations
 * Fault detection, currently when a worker acknowledges a task the engine will
   wait for the task result indefinitely (a task may take an indeterminate
   amount of time to finish). In the future there needs to be a way to limit
-  the duration of a remote workers execution (and track there liveness) and
+  the duration of a remote workers execution (and track their liveness) and
   possibly spawn the task on a secondary worker if a timeout is reached (aka
   the first worker has died or has stopped responding).