anchor.diff:  * a copy of the console problem report, or ideally the HTML problem report you got, so the plugin author can easily reason about the problems,
   * ideally a reproducer build, so the plugin author can easily reproduce the problems.
   
  +Roll it out to your team::
  +Once you have your developer workflow working, for example running tests from the IDE, you can consider enabling it for your team.
  +A faster turnaround when changing code and running tests could be worth it.
  +You'll probably want to do this as an opt-in first.
  ++
  +If needed, turn problems into warnings and set the maximum number of allowed problems in your build `gradle.properties` file.
  +Keep the configuration cache disabled by default.
  +Let your team know that they can opt-in by, for example, enabling the configuration cache on their IDE run configurations for the supported workflow.
  ++
  +Later on, when more workflows are working, you can flip this around.
  +Enable the configuration cache by default, configure CI to disable it, and if required communicate the unsupported workflow(s) for which the configuration cache needs to be disabled.
  +
   [[config_cache:testing]]
   == Testing your build logic
   
  
positive.code: 
  [IMPORTANT]
  ====
  This feature is currently *experimental* and not enabled by default.
  
  Not all <<configuration_cache#config_cache:plugins:core, core Gradle plugins>> are supported.
  Your build and the plugins you depend on might require changes to fulfil the <<configuration_cache#config_cache:requirements, requirements>>.
  
negative.code: When working on a plugin, progressively target the contributed or configured tasks.
  
  Explore by turning problems into warnings::
  Don't stop at the first build failure and <<configuration_cache#config_cache:usage:ignore_problems, turn problems into warnings>> to discover how your build and plugins behave.
  If a build fails, use the HTML report to reason about the reported problems related to the failure.
  Continue running more useful tasks.
  +
  This will give you a good overview of the nature of problems your build and plugins are facing.
  Remember that when turning problems into warnings you might need to <<configuration_cache#config_cache:usage:invalidate, manually invalidating the cache>> in case of troubles.
  
  Step back and fix problems iteratively::
  