Merge "Fix case of taskflow in docs"

doc/source/arguments_and_results.rst

@@ -7,7 +7,7 @@ Atom Arguments and Results
 .. |retry.execute| replace:: :py:meth:`~taskflow.retry.Retry.execute`
 .. |retry.revert| replace:: :py:meth:`~taskflow.retry.Retry.revert`
 
-In taskflow, all flow and task state goes to (potentially persistent) storage.
+In TaskFlow, all flow and task state goes to (potentially persistent) storage.
 That includes all the information that :doc:`atoms <atoms>` (e.g. tasks) in the
 flow need when they are executed, and all the information task produces (via
 serializable task results). A developer who implements tasks or flows can

doc/source/atoms.rst

@@ -5,7 +5,7 @@ Atoms, Tasks and Retries
 Atom
 ====
 
-An :py:class:`atom <taskflow.atom.Atom>` is the smallest unit in taskflow which
+An :py:class:`atom <taskflow.atom.Atom>` is the smallest unit in TaskFlow which
 acts as the base for other classes (its naming was inspired from the
 similarities between this type and `atoms`_ in the physical world). Atoms
 have a name and may have a version. An atom is expected to name desired input

doc/source/jobs.rst

@@ -5,7 +5,7 @@ Jobs
 Overview
 ========
 
-Jobs and jobboards are a **novel** concept that taskflow provides to allow for
+Jobs and jobboards are a **novel** concept that TaskFlow provides to allow for
 automatic ownership transfer of workflows between capable owners (those owners
 usually then use :doc:`engines <engines>` to complete the workflow). They
 provide the necessary semantics to be able to atomically transfer a job from a

doc/source/notifications.rst

@@ -22,7 +22,7 @@ class that is attached
 to :py:class:`engine <taskflow.engines.base.EngineBase>`
 attributes ``task_notifier`` and ``notifier``.
 
-Taskflow also comes with a set of predefined :ref:`listeners <listeners>`, and
+TaskFlow also comes with a set of predefined :ref:`listeners <listeners>`, and
 provides means to write your own listeners, which can be more convenient than
 using raw callbacks.
 

doc/source/persistence.rst

@@ -8,7 +8,7 @@ Overview
 In order to be able to receive inputs and create outputs from atoms (or other
 engine processes) in a fault-tolerant way, there is a need to be able to place
 what atoms output in some kind of location where it can be re-used by other
-atoms (or used for other purposes). To accommodate this type of usage taskflow
+atoms (or used for other purposes). To accommodate this type of usage TaskFlow
 provides an abstraction (provided by pluggable `stevedore`_ backends) that is
 similar in concept to a running programs *memory*.
 

doc/source/resumption.rst

@@ -13,10 +13,10 @@ atoms we need to create a model and corresponding information that allows us to
 persist the *right* amount of information to preserve, resume, and rollback a
 flow on software or hardware failure.
 
-To allow for resumption taskflow must be able to re-create the flow and
+To allow for resumption TaskFlow must be able to re-create the flow and
 re-connect the links between atom (and between atoms->atom details and so on)
 in order to revert those atoms or resume those atoms in the correct ordering.
-Taskflow provides a pattern that can help in automating this process (it does
+TaskFlow provides a pattern that can help in automating this process (it does
 **not** prohibit the user from creating their own strategies for doing this).
 
 Factories
@@ -129,7 +129,7 @@ some kind of upgrade or to fix a bug in a prior atoms code).
 factory should replace this name where it was being used previously.
 
 **Runtime change:** This will fall under the same runtime adjustments that
-exist when a new atom is added. In the future taskflow could make this easier
+exist when a new atom is added. In the future TaskFlow could make this easier
 by providing a ``upgrade()`` function that can be used to give users the
 ability to upgrade atoms before running (manual introspection & modification of
 a :py:class:`~taskflow.persistence.logbook.LogBook` can be done before engine
@@ -144,7 +144,7 @@ decides that N atoms should be merged in <N atoms (typically occurring during
 refactoring).
 
 **Runtime change:** This will fall under the same runtime adjustments that
-exist when a new atom is added or removed. In the future taskflow could make
+exist when a new atom is added or removed. In the future TaskFlow could make
 this easier by providing a ``migrate()`` function that can be used to give
 users the ability to migrate atoms previous data before running (manual
 introspection & modification of a

doc/source/utils.rst

@@ -2,7 +2,7 @@
 Utils
 -----
 
-There are various helper utils that are part of taskflows internal usage (and
+There are various helper utils that are part of TaskFlows internal usage (and
 external/public usage of these helpers should be kept to a minimum as these
 utility functions may be altered more often in the future).