[AIRFLOW-3977] Fix/Add examples of how trigger rules interacted with skipped tasks
diff --git a/docs/concepts.rst b/docs/concepts.rst
index 9ca1978217739..de2ce228d002b 100644
--- a/docs/concepts.rst
+++ b/docs/concepts.rst
@@ -752,6 +752,67 @@ Note that these can be used in conjunction with ``depends_on_past`` (boolean)
 that, when set to ``True``, keeps a task from getting triggered if the
 previous schedule for the task hasn't succeeded.
 
+One must be aware of the interaction between trigger rules and skipped tasks
+in schedule level. Skipped tasks will cascade through trigger rules 
+``all_success`` and ``all_failed`` but not ``all_done``, ``one_failed``, ``one_success``,
+``none_failed`` and ``dummy``. 
+
+For example, consider the following DAG:
+
+.. code:: python
+
+  #dags/branch_without_trigger.py
+  import datetime as dt  
+  
+  from airflow.models import DAG
+  from airflow.operators.dummy_operator import DummyOperator
+  from airflow.operators.python_operator import BranchPythonOperator  
+  
+  dag = DAG(
+      dag_id='branch_without_trigger',
+      schedule_interval='@once',
+      start_date=dt.datetime(2019, 2, 28)
+  )  
+  
+  run_this_first = DummyOperator(task_id='run_this_first', dag=dag)  
+  branching = BranchPythonOperator(
+      task_id='branching', dag=dag,
+      python_callable=lambda: 'branch_a'
+  )  
+  
+  branch_a = DummyOperator(task_id='branch_a', dag=dag)
+  follow_branch_a = DummyOperator(task_id='follow_branch_a', dag=dag)  
+  
+  branch_false = DummyOperator(task_id='branch_false', dag=dag)  
+  
+  join = DummyOperator(task_id='join', dag=dag)  
+  
+  run_this_first >> branching
+  branching >> branch_a >> follow_branch_a >> join
+  branching >> branch_false >> join
+
+In the case of this DAG, ``join`` is downstream of ``follow_branch_a`` 
+and ``branch_false``. The ``join`` task will show up as skipped 
+because its ``trigger_rule`` is set to ``all_success`` by default and 
+skipped tasks will cascade through ``all_success``. 
+
+.. image:: img/branch_without_trigger.png
+
+By setting ``trigger_rule`` to ``none_failed`` in ``join`` task, 
+
+.. code:: python
+  
+  #dags/branch_with_trigger.py
+  ...
+  join = DummyOperator(task_id='join', dag=dag, trigger_rule='none_failed')
+  ...
+
+The ``join`` task will be triggered as soon as 
+``branch_false`` has been skipped (a valid completion state) and 
+``follow_branch_a`` has succeeded. Because skipped tasks **will not** 
+cascade through ``none_failed``. 
+
+.. image:: img/branch_with_trigger.png
 
 Latest Run Only
 ===============
@@ -764,21 +825,9 @@ a pause just wastes CPU cycles.
 
 For situations like this, you can use the ``LatestOnlyOperator`` to skip
 tasks that are not being run during the most recent scheduled run for a
-DAG. The ``LatestOnlyOperator`` skips all immediate downstream tasks, and
-itself, if the time right now is not between its ``execution_time`` and the
-next scheduled ``execution_time``.
-
-One must be aware of the interaction between skipped tasks and trigger
-rules. Skipped tasks will cascade through trigger rules ``all_success``
-and ``all_failed`` but not ``all_done``, ``one_failed``, ``one_success``,
-and ``dummy``. If you would like to use the ``LatestOnlyOperator`` with
-trigger rules that do not cascade skips, you will need to ensure that the
-``LatestOnlyOperator`` is **directly** upstream of the task you would like
-to skip.
-
-It is possible, through use of trigger rules to mix tasks that should run
-in the typical date/time dependent mode and those using the
-``LatestOnlyOperator``.
+DAG. The ``LatestOnlyOperator`` skips all downstream tasks, if the time 
+right now is not between its ``execution_time`` and the next scheduled 
+``execution_time``.
 
 For example, consider the following DAG:
 
@@ -795,8 +844,8 @@ For example, consider the following DAG:
 
   dag = DAG(
       dag_id='latest_only_with_trigger',
-      schedule_interval=dt.timedelta(hours=4),
-      start_date=dt.datetime(2016, 9, 20),
+      schedule_interval=dt.timedelta(hours=1),
+      start_date=dt.datetime(2019, 2, 28),
   )
 
   latest_only = LatestOnlyOperator(task_id='latest_only', dag=dag)
@@ -820,9 +869,8 @@ for all runs except the latest run. ``task1`` is directly downstream of
 scheduled periods. ``task3`` is downstream of ``task1`` and ``task2`` and
 because of the default ``trigger_rule`` being ``all_success`` will receive
 a cascaded skip from ``task1``. ``task4`` is downstream of ``task1`` and
-``task2`` but since its ``trigger_rule`` is set to ``all_done`` it will
-trigger as soon as ``task1`` has been skipped (a valid completion state)
-and ``task2`` has succeeded.
+``task2``. It will be first skipped directly by ``LatestOnlyOperator``, 
+even its ``trigger_rule`` is set to ``all_done``.
 
 .. image:: img/latest_only_with_trigger.png
 
diff --git a/docs/img/branch_with_trigger.png b/docs/img/branch_with_trigger.png
new file mode 100644
index 0000000000000..0aab8a1b3a5c8
Binary files /dev/null and b/docs/img/branch_with_trigger.png differ
diff --git a/docs/img/branch_without_trigger.png b/docs/img/branch_without_trigger.png
new file mode 100644
index 0000000000000..748c796a4981f
Binary files /dev/null and b/docs/img/branch_without_trigger.png differ
diff --git a/docs/img/latest_only_with_trigger.png b/docs/img/latest_only_with_trigger.png
index 629adfa907964..623f8ee177ff0 100644
Binary files a/docs/img/latest_only_with_trigger.png and b/docs/img/latest_only_with_trigger.png differ

### Jira

- [x] My PR addresses the following [Airflow Jira](https://issues.apache.org/jira/browse/AIRFLOW/) issues and references them in the PR title. 
  - https://issues.apache.org/jira/browse/AIRFLOW-3977
  - https://issues.apache.org/jira/browse/AIRFLOW-1784

### Description

- [x] Here are some details about my PR, including screenshots of any UI changes:
The current LatestOnlyOperator will skip all downstream tasks blindly. However, the doc shows it will respect trigger rules which is a wrong behavior. 
It also shows an incorrect example of the interaction between skipped tasks and trigger rules in schedule level. I replace it with other examplesusing BranchingOperator.

### Tests

- [x] My PR adds the following unit tests __OR__ does not need testing for this extremely good reason:
No test needed because its changes on documentation.

### Commits

- [x] My commits all reference Jira issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "[How to write a good git commit message](http://chris.beams.io/posts/git-commit/)":
  1. Subject is separated from body by a blank line
  1. Subject is limited to 50 characters (not including Jira issue reference)
  1. Subject does not end with a period
  1. Subject uses the imperative mood ("add", not "adding")
  1. Body wraps at 72 characters
  1. Body explains "what" and "why", not "how"

### Documentation

- [x] In case of new functionality, my PR adds documentation that describes how to use it.
  - When adding new operators/hooks/sensors, the autoclass documentation generation needs to be added.
  - All the public functions and the classes in the PR contain docstrings that explain what it does

### Code Quality

- [x] Passes `flake8`
