Merge "Fix seven typos and one readability on taskflow documentation"

doc/source/arguments_and_results.rst

@@ -87,7 +87,7 @@ Rebinding
 stored with a name other than the corresponding arguments name. That's when the
 ``rebind`` constructor parameter comes in handy. Using it the flow author
 can instruct the engine to fetch a value from storage by one name, but pass it
-to a tasks/retrys ``execute`` method with another name. There are two possible
+to a tasks/retries ``execute`` method with another name. There are two possible
 ways of accomplishing this.
 
 The first is to pass a dictionary that maps the argument name to the name
@@ -303,7 +303,7 @@ Default provides
 ++++++++++++++++
 
 As mentioned above, the default base class provides nothing, which means
-results are not accessible to other tasks/retrys in the flow.
+results are not accessible to other tasks/retries in the flow.
 
 The author can override this and specify default value for provides using
 the ``default_provides`` class/instance variable:
@@ -386,7 +386,7 @@ A |Retry| controller works with arguments in the same way as a |Task|. But it
 has an additional parameter ``'history'`` that is itself a
 :py:class:`~taskflow.retry.History` object that contains what failed over all
 the engines attempts (aka the outcomes). The history object can be
-viewed as a tuple that contains a result of the previous retrys run and a
+viewed as a tuple that contains a result of the previous retries run and a
 table/dict where each key is a failed atoms name and each value is
 a :py:class:`~taskflow.types.failure.Failure` object.
 
@@ -415,7 +415,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
+history and it can then return a value that subsequent tasks can use to alter
 their behavior.
 
 If instead the |retry.execute| method itself raises an exception,

doc/source/engines.rst

@@ -85,7 +85,7 @@ Of course these kind of features can come with some drawbacks:
   away from (and this is likely a mindset change for programmers used to the
   imperative model). We have worked to make this less of a concern by creating
   and encouraging the usage of :doc:`persistence <persistence>`, to help make
-  it possible to have state and tranfer that state via a argument input and
+  it possible to have state and transfer that state via a argument input and
   output mechanism.
 * Depending on how much imperative code exists (and state inside that code)
   there *may* be *significant* rework of that code and converting or

doc/source/jobs.rst

@@ -215,7 +215,7 @@ Redis
 **Board type**: ``'redis'``
 
 Uses `redis`_ to provide the jobboard capabilities and semantics by using
-a redis hash datastructure and individual job ownership keys (that can
+a redis hash data structure and individual job ownership keys (that can
 optionally expire after a given amount of time).
 
 .. note::

doc/source/workers.rst

@@ -286,10 +286,10 @@ but not *yet* consumed.
 **PENDING** - Worker accepted request and is pending to run using its
 executor (threads, processes, or other).
 
-**FAILURE** - Worker failed after running request (due to task exeception) or
+**FAILURE** - Worker failed after running request (due to task exception) or
 no worker moved/started executing (by placing the request into ``RUNNING``
 state) with-in specified time span (this defaults to 60 seconds unless
-overriden).
+overridden).
 
 **RUNNING** - Workers executor (using threads, processes...) has started to
 run requested task (once this state is transitioned to any request timeout no