Consistent task name in examples

[hjoliver]

We should be consistent, obviously. Let's agree on the strategy and do a quick pass through the documentation to clean it up.

IMO tasks in examples should be named as follows:

• concrete names in examples that pretend to be real workflows with tasks that do specific things
  • e.g., tutorial examples; task names should reflect what the task does
• generic names in graph snippets used to illustrate triggering and optional outputs etc.
  • it doesn't matter what the task does in these examples
  • generic names immediately indicate that, with no mental effort required from the user

---

Motivated by #772 (comment) - in addition to concrete and generic examples, we now have a bunch with both generic and concrete-but-not-what-the-task-does names in the same line:

one:fail? & two:fail? => run_if_both_fail

IMO run_if_both_fail is not a great task name because (a) if restates its own triggering condition rather than reflecting what the task does, which is both redundant and not how real tasks ever get named; (b) it doesn't matter what the task does in this example, so a generic name would be perfectly fine; and (c) consistency with the other names in the example.

As such, this might seem puzzling to some users and they might even wonder if the name has functional meaning. "Might" is sufficient to disqualify it because the alternative (generic name, with the usual discussion of the example below if needed) has zero potential for confusion.

Reductio ad absurdum: if we wanted to use this naming scheme we should be consistent, something like this 🤯 :

can_fail_one:fail? can_fail_two:fail? => run_if_both_fail