Fix case of taskflow in docs

Fix occurrences of the lowercase (or mixed case)
version of taskflow and rename those occurrences
to the cased version to be consistent with usage
elsewhere in the docs.

Change-Id: I31f552daa015724b443b099c2fcfe38d8e04605a

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).