anchor.diff:      </imageobject>
   </figure>
   +++++
  -
  -    1. Total tasks present when each tasks are created or not.
  ++
  +    1. Total tasks present when each task are created or not.
         - Created immediately represent all the task created using the eager task APIs.
  -      - Created during configuration represent all the task that were created using the lazy task APIs, but was realized explicitly (via `TaskProvider#get()`) or implicitly using the eager task query APIs.
  -      - Both "Created immediately" and "Created during configuration" numbers are consider the "bad" numbers that should be minimize as much as possible.
  +      - Created during configuration represent all the tasks that were created using the lazy task APIs, but was realized explicitly (via `TaskProvider#get()`) or implicitly using the eager task query APIs.
  +      - Both "Created immediately" and "Created during configuration" numbers are considered the "bad" numbers that should be minimized as much as possible.
         - Created during task graph calculation number represent all the task created while building the execution task graph.
  -      Normally, this number should be equal to the number of task that will be executed.
  -      - Not created number represent all the tasks that were avoided in this build session.
  -
  -    2. The next section helps answer the question of where a task was realized. For each scripts, plugins and lifecycle callbacks, the last column represent the tasks that were created either immediately or during configuration.
  +      Typically, this number should be equal to the number of tasks that is executed.
  +      - Not created number represents all the tasks that were avoided in this build session.
  +
  +    2. The next section helps answer the question of where a task was realized. For each scripts, plugins and lifecycle callbacks, the last column represents the tasks that were created either immediately or during configuration.
       Ideally, this column should be empty.
       The migration should be focusing on the build logic under your control.
   
  
positive.code: * [[task_configuration_avoidance_troubleshooting_no_improvement]] **The build performance haven’t improved after migrating to lazy API.**
  It is important to note that lazy task configuration is an opt-in feature.
  It means the entire configuration chain needs to be lazy to get the benefit.
  If at any point, an eager API is used for a specific named task, task type or, the worst, the entire task container, all benefit are mitigated.
  The first step is to have a look at the statistics to see how much more the build can be improved.
  If the statistic shows the build is completely lazy (work-avoided) https://discuss.gradle.org/[please contact us] so we can discuss where this feature fall short and improve it for the next version.
  
  [[sec:task_configuration_avoidance_pitfalls]]
  ==== Pitfalls
  * **Lazy task configuration is an opt-in feature.**
  Any eager realization of a task will mitigate the benefit of this new API.
  In the far future, eager realization will become an error, until them, it’s up to the build author to avoid eager realization.
  
  * [[task_configuration_avoidance_pitfalls_hidden_eager_task_realization]] **Beware of the hidden eager task realization.**
  Gradle has lots of ways to configure a task eagerly.
  `TaskContainer#getByName(String, Action)` is an explicit configuration by name.
  Configuring a task as a DSL block is a alias to the previous explicit configuration, meaning a lazy task will be prematurely resolved:
  
  [source,groovy]
  ----
  // Given a task lazily created with
  
negative.code: 
  // Some time later, the task is configured using a DSL block like
  someTask {
      // The task is resolved immediately, and this closure is executed immediately
  }
  ----
  +
  You will have to migrate the DSL task configuration to the following:
  +
  [source,groovy]
  ----
  tasks.named("someTask").configure {
      // ...
      // Beware of the pitfalls here
  }
  ----
  +
  While migrating to the lazy task configuration, you may still have eager task configuration that references a task by name using Groovy’s property to task reference syntactic sugar.
  If this lookup is done from anything other than a lazy configuration action, the lazy task reference by the name will be prematurely realized:
  +
  [source,groovy]
  ----
  tasks.register "someTask"
  
  // Sometime later, an eager task is configured like
  task aEagerTask {
      // The task is resolved immediately as it will be treated as a property of the project and will result in an eager task lookup by name
      dependsOn someTask
  }
  ----
  +
  You can solve the following in three ways:
  
    - **Use `TaskProvider` variable.**
    Useful when the task is referenced multiple time in the same build script.
  +
  [source,groovy]
  ----
  def someTask = tasks.register "someTask"
  