Add a note to the documentation on assuming your CL not is the culprit.

docs/speed/addressing_performance_regressions.md

 # Addressing Performance Regressions
 
 The bisect bot just picked your CL as the culprit in a performance regression
 and assigned a bug to you! What should you do? Read on...
 
 [TOC]
 
 ## About our performance tests
 
 The [chromium.perf waterfall](perf_waterfall.md) is a continuous build which
@@ skipping 100 matching lines @@
        open a the trace that was recorded during the performance test.
   * **Wait, what's a trace?** See the
     [documentation on tracing](https://www.chromium.org/developers/how-tos/trace-event-profiling-tool)
     to learn how to use traces to debug performance issues.
   * **Are there debugging tips specific to certain benchmarks?**
     * **[Memory](https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md)**
     * **[Android binary size](apk_size_regressions.md)**
 
 ## If you don't believe your CL could be the cause
 
+*** promo

[sullivan, 2017/06/19 16:56:23]

This "promo" block is a gitiles markdown extension:
https://gerrit.googlesource.com/gitiles/+/HEAD/Documentation/markdown.md#Noti...

+Please remember that our performance tests exist to catch unexpected
+regressions. Often, the tests catch performance problems the CL author was
+not aware of. Please look at the data carefully and understand what the test
+is measuring before concluding that your CL is not related.
+***
+
 There are some clear reasons to believe the bisect bot made a mistake:
 
   * Your CL changes a test or some code that isn't compiled on the platform
     that regressed.
   * Your CL is completely unrelated to the metric that regressed.
   * You looked at the numbers the bisect spit out (see example above; the first
     column is the revision, the second column is the value at that revision,
     and the third column is the standard deviation), and:
     * The change attributed to your CL seems well within the noise, or
     * The change at your CL is an improvement (for example, the metric is bytes
@@ skipping 76 matching lines @@
     possible that your change did not regress performance, and only appears to
     be a problem because the test is measuring incorrectly. If this is the
     case, you must explain clearly what the issue with the test is, and why you
     believe your change is performance neutral. Please include data from traces
     or other performance tools to clarify your claim.
 
 **In all cases,** make sure to cc the [benchmark owner](https://docs.google.com/spreadsheets/d/1xaAo0_SU3iDfGdqDJZX_jRV0QtkufwHUKH3kQKF3YQs/edit#gid=0)
 when writing a justification and WontFix-ing a bug. If you cannot come to an
 agreement with the benchmark owner, you can escalate to benhenry@chromium.org,
 the owner of speed releasing.