Add examples for some scenarios in the code review docs.

docs/code_reviews.md

 # Code Reviews
 
 Code reviews are a central part of developing high-quality code for Chromium.
 All changes must be reviewed.
 
 The bigger patch-upload-and-land process is covered in more detail the
 [contributing code](https://www.chromium.org/developers/contributing-code)
 page.
 
 # Code review policies
@@ skipping 25 matching lines @@
     includes writing a blanket ("slow") after your name in the review tool.
 
 ## OWNERS files
 
 In various directories there are files named `OWNERS` that list the email
 addresses of people qualified to review changes in that directory. You must
 get a positive review from an owner of each directory your change touches.
 
 Owners files are recursive, so each file also applies to its subdirectories.
 It's generally best to pick more specific owners. People listed in higher-level
-directories may have less experience with the code in question. More detail on
-the owners file format is provided in the "More information" section below.
+directories may have less experience with the code in question. For example,
+the reviewers in the `//chrome/browser/component_name/OWNERS` file will likely
+be more familiar with code in `//chrome/browser/component_name/sub_component`
+than reviewers in the higher-level `//chrome/OWNERS` file.
+
+More detail on the owners file format is provided in the "More information"
+section below.
 
 *Tip:* The `git cl owners` command can help find owners.
 
 While owners must approve all patches, any committer can contribute to the
 review. In some directories the owners can be overloaded or there might be
 people not listed as owners who are more familiar with the low-level code in
 question. In these cases it's common to request a low-level review from an
 appropriate person, and then request a high-level owner review once that's
 complete. As always, be clear what you expect of each reviewer to avoid
 duplicated work.
@@ skipping 44 matching lines @@
 Do not use TBR just because a change is urgent or the reviewer is being slow.
 Contact the reviewer directly or find somebody.
 
 To send a change TBR, annotate the description and send email like normal.
 Otherwise the reviewer won't know to review the patch.
 
   * Add the reviewer's email address in the code review tool's reviewer field
     like normal.
 
   * Add a line "TBR=<reviewer's email>" to the bottom of the change list
-    description.
+    description. e.g. `TBR=reviewer1@chromium.org,reviewer2@chromium.org`
+
+  * Type a message so that the owners in the TBR list can understand who is
+    responsible for reviewing what, as part of their post-commit review
+    responsibility. e.g.
+    ```

[brettw, 2017/06/09 15:31:17]

I'm not sure gitiles will do what you want here, but we can try!

Pro tip: gerrit can preview markdown and I've been using it for all of my .md
code reviews now (even though I still use Reitveld for everything else).

[Lei Zhang, 2017/06/09 21:52:50]

Seems to work:
https://chromium.googlesource.com/chromium/src/+/9d3cdcb070e41affee3d7bc13aef...

+    TBRing reviewers:
+    reviewer1: Please review changes to foo/
+    reviewer2: Please review changes to bar/
+    ```
 
   * Push the "send mail" button.
 
 ### TBR-ing certain types of mechanical changes
 
 Sometimes you might do something that affects many callers in different
-directories. For example, adding a parameter to a common function in //base.
-If the updates to the callers is mechanical, you can:
+directories. For example, adding a parameter to a common function in
+`//base`, with callers in `//chrome/browser/foo`, `//net/bar`, and many other
+directories. If the updates to the callers is mechanical, you can:
 
-  * Get a normal owner of the lower-level directory you're changing (in this
-    example, `//base`) to do a proper review of those changes.
+  * Get a normal owner of the lower-level code you're changing (in this
+    example, the function in `//base`) to do a proper review of those changes.
 
-  * Get _somebody_ to review the downstream changes. This is often the same
-    person from the previous step but could be somebody else.
+  * Get _somebody_ to review the downstream changes made to the callers as a
+    result of the `//base` change. This is often the same person from the
+    previous step but could be somebody else.
 
-  * Add the owners of the affected downstream directories as TBR.
+  * Add the owners of the affected downstream directories as TBR. (In this
+    example, reviewers from `//chrome/browser/foo/OWNERS`, `//net/bar/OWNERS`,
+    etc.)
 
 This process ensures that all code is reviewed prior to checkin and that the
 concept of the change is reviewed by a qualified person, but you don't have to
-track down many individual owners for trivial changes to their directories.
+wait for many individual owners to review trivial changes to their directories.
 
 ### TBR-ing documentation updates
 
 You can TBR documentation updates. Documentation means markdown files, text
 documents, and high-level comments in code. At finer levels of detail, comments
 in source files become more like code and should be reviewed normally (not
 using TBR). Non-TBR-able stuff includes things like function contracts and most
 comments inside functions.
 
   * Use good judgement. If you're changing something very important, tricky,
     or something you may not be very familiar with, ask for the code review
     up-front.
 
   * Don't TBR changes to policy documents like the style guide or this document.
 
   * Don't mix unrelated documentation updates with code changes.
 
   * Be sure to actually send out the email for the code review. If you get one,
     please actually read the changes.
 
 ## More information
 
 ### OWNERS file details
 
 Refer to the [source code](https://chromium.googlesource.com/chromium/tools/depot_tools/+/master/owners.py)
-for all details on the file format. 
+for all details on the file format.
 
 This example indicates that two people are owners, in addition to any owners
 from the parent directory. `git cl owners` will list the comment after an
 owner address, so this is a good place to include restrictions or special
 instructions.
 ```
 # You can include comments like this.
 a@chromium.org
 b@chromium.org  # Only for the frobinator.
 ```
@@ skipping 23 matching lines @@
 per-file readme.txt=*
 ```
 
 Other `OWNERS` files can be included by reference by listing the path to the
 file with `file://...`. This example indicates that only the people listed in
 `//ipc/SECURITY_OWNERS` can review the messages files:
 ```
 per-file *_messages*.h=set noparent
 per-file *_messages*.h=file://ipc/SECURITY_OWNERS
 ```