Tweak terminology.

Author: hjoliver

src/7-to-8/major-changes/compatibility-mode.rst

@@ -33,8 +33,8 @@ The ``suite.rc`` filename triggers a backward compatibility mode in which:
   - (Cylc 8 spawns tasks on demand, and suicide triggers are not needed for
     branching)
 
-- only ``succeeded`` task outputs are :ref:`*required* <User Guide Required Outputs>`,
-  so the scheduler will retain all non-succeeded :term:`finished tasks <finished task>`
+- ``succeeded`` task outputs are :ref:`*required* <User Guide Required Outputs>`,
+  so the scheduler will retain all other tasks with :term:`final status`
   in the :term:`n=0 window <n-window>`.
 
   - (in Cylc 8, **all** outputs are *required* unless marked as

src/7-to-8/summary.rst

@@ -121,10 +121,9 @@ Optional and Required Task Outputs
    * User Guide::ref:`User Guide Optional Outputs`
 
 By default, all Cylc 8 tasks are required to succeed - i.e., success is
-a :term:`required output`. Tasks that :term:`finish <finished task>`
-without completing their required outputs get retained in the
-:term:`n=0 window <n-window>` pending user intervention, which
-will :term:`stall` the workflow.
+a :term:`required output`. Tasks with :term:`final status` and incomplete
+outputs get retained in the :term:`n=0 window <n-window>` pending user
+intervention, which will :term:`stall` the workflow.
 
 Alternatively, outputs can be marked as :term:`optional <optional output>`,
 which allows :term:`optional graph branching <graph branching>`.

src/glossary.rst

@@ -86,7 +86,7 @@ Glossary
 
       - ``preparing`` tasks - i.e. tasks in the process of submitting jobs
       - ``submitted`` and ``running`` tasks - i.e. those with active jobs
-      - tasks that finished without completing their
+      - tasks that reached a :term:`final status` without completing their
         :term:`required outputs <required output>`
         (e.g. a task failed where success was required).
 
@@ -570,7 +570,7 @@ Glossary
       Tasks in :term:`datetime cycling` workflows can be configured to *expire*
       if the :term:`wallclock time` exceeds some offset from the cycle point.
 
-      Expired is a :term:`final task status` - an expired task will not run
+      Expired is a :term:`final status` - an expired task will not run
       even if its prerequisites get satisfied.
 
       The associated ``:expire`` :term:`output <task output>` can be used to
@@ -862,9 +862,8 @@ Glossary
 
 
    job
-      Jobs are the real processes that run on a computer to realise
-      :term:`tasks <task>` in a :term:`workflow`. In Cylc, they are
-      implemented by :term:`job scripts
+      Jobs are the real processes that :term:`tasks <task>` represent in
+      a :term:`workflow`. In Cylc, they are implemented by :term:`job scripts
       <job script>` prepared by the :term:`scheduler`.
 
 
@@ -1371,11 +1370,10 @@ Glossary
          * :ref:`Cylc User Guide <FamilyTriggers>`
 
 
-   final task status
-   finished task
-      A finished task has achieved a final task status, i.e., expired,
-      submit-failed, succeeded, or failed. Finished tasks cannot change
-      state again except by manual intervention (e.g. by retriggering).
+   final status
+      A task that has achieved a final status (expired, submit-failed,
+      succeeded, or failed) will not change state in the workflow, except by
+      manual intervention.
 
 
    standard output
@@ -1413,6 +1411,8 @@ Glossary
          foo => bar  # means foo:succeeded => bar
 
 
+   complete
+   incomplete
    output completion
    output completion condition
       A task's outputs are *complete* if its *output completion condition* 
@@ -1428,11 +1428,12 @@ Glossary
         submit-fails.
       - Or, if expiry is optional, then the outputs are complete if it expires.
 
-      Tasks that :term:`finish <finished task>` with
-      :term:`complete outputs <output completion>`
-      have done their job, allowing the workflow to move on.
+      Tasks that achieve a :term:`final status` with
+      :term:`complete outputs <output completion>` have done their job in the
+      workflow, allowing the workflow to move on.
 
-      Tasks that finish with :term:`incomplete outputs <output completion>`
+      Tasks that achieve a final status with
+      :term:`incomplete outputs <output completion>`
       are retained in :term:`n=0 <n-window>` pending user
       intervention, and will :term:`stall` the workflow.
 
@@ -1567,7 +1568,7 @@ Glossary
    expected output
       Task outputs that are not marked as :term:`optional <optional output>`
       in the :term:`graph` must be completed at runtime. If a task
-      :term:`finishes <finished task>` without completing its required
+      achieves a :term:`final status` without completing its required
       outputs, the :term:`scheduler` will keep it in the
       :term:`n=0 window <n-window>` pending user intervention.
 
@@ -1581,8 +1582,9 @@ Glossary
    stalled state
       In a stalled workflow, there is nothing more the scheduler can do,
       but it stays up for a while awaiting manual intervention because
-      the presence of :term:`incomplete <output completion>` tasks in
-      the :term:`n=0 window <n-window>` implies that the workflow has not successfully
+      the presence of :term:`incomplete <output completion>` tasks, or
+      partially satisfied tasks, in the :term:`n=0 window <n-window>`
+      implies that the workflow has not successfully
       run to :term:`completion <workflow completion>`.
 
       Stalls are usually, but not always, caused by unexpected task failures:

src/user-guide/running-workflows/reflow.rst

@@ -128,9 +128,9 @@ Special Case: Triggering ``n=0`` Tasks
 
    - Triggering a task with a submitted or running job has no effect
      (it is already triggered).
-   - Triggering other :term:`active tasks <active task>` (including
-     :term:`incomplete <output completion>`
-     :term:`finished <finished task>` tasks) queues them to run in the same flow.
+   - Triggering other :term:`active tasks <active task>`, including
+     :term:`incomplete <output completion>` tasks with a :term:`final status`,
+     queues them to run in the same flow.
 
 
 .. _flow-merging:
@@ -145,7 +145,7 @@ of itself (same task ID) already there, the two will merge and carry both
 Flow merging is necessary because :term:`active <active task>` task IDs
 must be unique.
 
-If original task instance is :term:`finished <finished task>` but
+If original task instance has a :term:`final status` but is
 :term:`incomplete <output completion>` the merged task will be reset to
 run again without manual intervention.
 

src/user-guide/running-workflows/workflow-completion.rst

@@ -21,9 +21,10 @@ alive for 1 hour (by default) awaiting user intervention
 to allow the workflow to continue.
 
 A stall can be caused by tasks with partially satisfied
-prerequisites or tasks that finished incomplete. However,
-partially satisfied prerequisites normally result from
-upstream tasks finishing incomplete.
+prerequisites or tasks that achieved a :term:`final status`
+with incomplete outputs. Partially satisfied prerequisites
+normally result from incomplete tasks with final status 
+upstream in the graph.
 
 Restarting a stalled workflow resets the stall timer.
 

src/user-guide/writing-workflows/runtime.rst

@@ -538,7 +538,7 @@ In the following example, tasks ``bad`` and ``flaky`` each have 3 retries
 configured, with a 10 second delay between. On the final try, ``bad`` fails
 again and goes to the ``failed`` state, while ``flaky`` succeeds and triggers
 task ``whizz`` downstream. The scheduler will then stall because
-``bad`` finished with incomplete outputs.
+``bad`` failed (which is a :term:`final status`) with incomplete outputs.
 
 .. code-block:: cylc
 

src/user-guide/writing-workflows/scheduling.rst

@@ -1549,22 +1549,20 @@ Required Outputs
 :term:`optional <optional output>` (marked with ``?`` in the graph).
 
 Tasks are expected to complete required outputs at runtime, but
-they can finish without completing optional outputs.
+they don't have to complete optional outputs.
 
 This allows the scheduler to correctly diagnose
 :term:`workflow completion`. [2]_
 
-Tasks that :term:`finish <finished task>` without completing their
+Tasks that achieve a :term:`final status` without completing their
 outputs [3]_ are retained in the :term:`n=0 window <n-window>` pending user
 intervention, e.g. to be retriggered after a bug fix.
 
 .. note::
-   Tasks that finish without completing their outputs will raise a warning
-   and stall the workflow when there is nothing else for the scheduler to
-   run. to do (see
-
-   :ref:`workflow completion`). They also count toward the :term:`runahead
-   limit`, because they may run again once dealt with.
+   Tasks that achieve a final status without completing their outputs will
+   raise a warning and stall the workflow when there is nothing else for
+   the scheduler to run (see :ref:`workflow completion`). They also count
+   toward the :term:`runahead limit`, because they may run again once dealt with.
 
 This graph says task ``bar`` should trigger if ``foo`` succeeds:
 
@@ -1573,7 +1571,7 @@ This graph says task ``bar`` should trigger if ``foo`` succeeds:
    foo => bar  # short for "foo:succeed => bar"
 
 Additionally, ``foo`` is required to succeed, because its success is not marked
-as optional. If ``foo`` :term:`finishes <finished task>` without succeeding the
+as optional. If ``foo`` achieves a :term:`final status` without succeeding the
 scheduler will not run ``bar``, and ``foo`` will be retained
 in :term:`n=0 <n-window>` pending user intervention.
 
@@ -1676,7 +1674,8 @@ following graph, ``foo`` is required to succeed, but it doesn't matter whether
 .. note::
 
    Optional outputs do not affect *triggering*. They just tell the scheduler
-   what to do with the task if it finishes without completing the output.
+   what to do with the task if it reaches a :term:`final status` without
+   completing the output.
 
    This graph triggers ``bar`` if ``foo`` succeeds, and does not trigger
    ``bar`` if ``foo`` fails: