[Docs]: Copy edit Advanced Topics section. (#2799)

* [Docs]: Copy edit Advanced Topics section.

* Minor tweaks addressing Max's comments.

* Add context for Code Coverage

1 files changed, 58 insertions, 47 deletions

diff --git a/docs/advanced-topics/reproducing.md b/docs/advanced-topics/reproducing.md
index a95e1b35..e3f7f707 100644
--- a/docs/advanced-topics/reproducing.md
+++ b/docs/advanced-topics/reproducing.md
@@ -7,10 +7,11 @@ permalink: /advanced-topics/reproducing/
 ---
 
 # Reproducing OSS-Fuzz issues
+{: .no_toc}
 
-You've been CC'ed on an OSS-Fuzz issue
-([examples](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Type%3ABug%2CBug-Security)),
-now what? Before attempting to fix the bug, you should be able to reliably
+You've been CCed on an OSS-Fuzz issue
+([examples](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Type%3ABug%2CBug-Security)).
+Now what? Before attempting to fix the bug, you should be able to reliably
 reproduce it. 
 
 - TOC
@@ -18,75 +19,84 @@ reproduce it.
 ---
 
 ## Fuzz target bugs
-Every issue has a [reproducer]({{ site.baseurl }}/reference/glossary/#reproducer)
-(aka "testcase") file attached.
-Download it. If the issue is not public, you will need to login using your
+
+Every issue has a [reproducer file]({{ site.baseurl
+}}/reference/glossary/#reproducer) (also know as a "testcase" file) attached.
+Download it. This file contains the bytes that were fed to the [fuzz
+target](http://libfuzzer.info/#fuzz-target).
+
+**Note:** If the issue is not public, you will need to login using a
 [Google account](https://support.google.com/accounts/answer/176347?hl=en)
-([why?]({{ site.baseurl }}/faq/#why-do-you-require-a-google-account-for-authentication))
-that the bug report CCs.
-This file contains the bytes that were fed to the [fuzz target](http://libfuzzer.info/#fuzz-target).
+([why?]({{ site.baseurl
+}}/faq/#why-do-you-require-a-google-account-for-authentication)) that the bug
+report CCs.
 
 If you have already
 [integrated]({{ site.baseurl }}/advanced-topics/ideal-integration/)
-the fuzz target with your build and test system, all you do is run:
+the fuzz target with your build and test system, all you have to do is run this command:
 ```bash
 $ ./fuzz_target_binary <testcase_path>
 ```
 
-If this is a timeout bug, add the **-timeout=25** argument.
-If this is an OOM bug, add the **-rss_limit_mb=2048** argument.
-Read more on how timeouts and OOMs are handed
-[here]({{ site.baseurl }}/faq/#how-do-you-handle-timeouts-and-ooms).
+For timeout bugs, add the `-timeout=25` argument. For OOM bugs, add the
+`-rss_limit_mb=2048` argument. Read more on [how timeouts and OOMs are
+handled]({{ site.baseurl }}/faq/#how-do-you-handle-timeouts-and-ooms).
 
 Depending on the nature of the bug, the fuzz target binary needs to be built
 with the appropriate [sanitizer](https://github.com/google/sanitizers)
-(e.g. if this is a buffer overflow, with
+(for example, if it's a buffer overflow, build with
 [AddressSanitizer](http://clang.llvm.org/docs/AddressSanitizer.html)).
 
-If you are not sure how to build the fuzzer using the project's build system,
-you may also use Docker
-([how?]({{ site.baseurl }}/getting-started/new-project-guide/#prerequisites),
-[why?]({{ site.baseurl }}/faq/#why-do-you-use-docker)) commands 
-to replicate the exact build steps used by OSS-Fuzz and then feed the reproducer
-input to the fuzz target.
+If you're not sure how to build the fuzzer using the project's build system,
+you can also use Docker commands to replicate the exact build steps used by
+OSS-Fuzz, then feed the reproducer input to the fuzz target ([how?]({{
+site.baseurl }}/getting-started/new-project-guide/#prerequisites), [why?]({{
+site.baseurl }}/faq/#why-do-you-use-docker)).
 
 ## Building using Docker
 
 ### Pull the latest Docker images
 
+Docker images get regularly updated with a newer version of build tools, build
+configurations, scripts, and other changes. In some cases, a particular issue
+can be reproduced only with a fresh image being used. Pull the latest images
+by running the following command:
+
 ```bash
 $ python infra/helper.py pull_images
 ```
 
-  Docker images get regularly updated with a newer version of build tools, build
-  configurations, scripts, and other changes. In some cases, a particular issue
-  can be reproduced only with a fresh image being used.
-
 ### Build the image and the fuzzers
 
+Run the following commands:
+
 ```bash
 $ python infra/helper.py build_image $PROJECT_NAME
 $ python infra/helper.py build_fuzzers --sanitizer <address/memory/undefined> \
     --architecture <x86_64/i386> $PROJECT_NAME
 ```
 
-The `architecture` argument is only necessary if you want to specify `i386` configuration.
+The `sanitizer` used in the report is the value in the
+**Sanitizer** column. It's one of the following:
+  * **address** for AddressSanitizer
+  * **memory** for MemorySanitizer
+  * **undefined** for UndefinedBehaviorSanitizer
+
+**Note**: The `architecture` argument is only necessary if you want to specify
+`i386` configuration.
 
 ## Reproducing bugs
+
+After you build an image and a fuzzer, you can reproduce a bug by running the following command:
+
 ```bash
 $ python infra/helper.py reproduce $PROJECT_NAME <fuzz_target_name> <testcase_path>
 ```
-  
-Find the type of sanitizer used in the report using the value in the
-**Sanitizer** column. It is one of the following:
-  * **address** for AddressSanitizer
-  * **memory** for MemorySanitizer
-  * **undefined** for UndefinedBehaviorSanitizer
 
-E.g. for building [libxml2](https://github.com/google/oss-fuzz/tree/master/projects/libxml2)
-project with UndefinedBehaviorSanitizer (undefined) instrumentation and
+For example, to build the [libxml2](https://github.com/google/oss-fuzz/tree/master/projects/libxml2)
+project with UndefinedBehaviorSanitizer (`undefined`) instrumentation and
 reproduce a crash testcase for a fuzzer named `libxml2_xml_read_memory_fuzzer`,
-it will be: 
+you would run: 
 
 ```bash
 $ python infra/helper.py build_image libxml2
@@ -96,29 +106,30 @@ $ python infra/helper.py reproduce libxml2 libxml2_xml_read_memory_fuzzer ~/Down
 
 ## Reproduce using local source checkout
 
+You can also mount local sources into the running container by using these commands:
+
 ```bash
 $ python infra/helper.py build_fuzzers \
     --sanitizer <address/memory/undefined> $PROJECT_NAME <source_path>
 $ python infra/helper.py reproduce $PROJECT_NAME <fuzz_target_name> <testcase_path>
 ```
 
-This is essentially the previous command that additionally mounts local sources
-into the running container.
+Once you reproduce the bug, you can do the following:
 
-- *Fix issue*. Write a patch to fix the issue in your local checkout and then
+- **Fix issue:** Write a patch to fix the issue in your local checkout, then
    use the previous command to verify the fix (i.e. no crash occurred). 
    [Use gdb]({{ site.baseurl }}/advanced-topics/debugging/#debugging-fuzzers-with-gdb)
    if needed.
-- *Submit fix*. Submit the fix in the project's repository. ClusterFuzz will
-  automatically pick up the changes, recheck the testcase and will close the
+- **Submit fix:** Submit the fix in the project's repository. ClusterFuzz will
+  automatically pick up the changes, recheck the testcase, and close the
   issue (in &lt; 1 day).
-- *Improve fuzzing support*. Consider
-   [improving fuzzing support]({{ site.baseurl }}/advanced-topics/ideal-integration/)
-   in your project's build and test system.
+- **Improve fuzzing support:** Consider
+   [improving your integration with OSS-Fuzz]({{ site.baseurl }}/advanced-topics/ideal-integration/).
 
 ## Reproducing build failures
+
 Our infrastructure runs some sanity tests to make sure that your build was
-correctly configured, even if it succeeded. To reproduce these locally, run:
+correctly configured, even if it succeeded. To reproduce these locally, run these commands:
 
 ```bash
 $ python infra/helper.py build_image $PROJECT_NAME
@@ -129,9 +140,9 @@ $ python infra/helper.py check_build  --sanitizer <address/memory/undefined> \
     <fuzz_target_name>
 ```
 
-Note that unless you have a reason to think the build is an `i386` build, the build
+**Note:** Unless you have a reason to think the build is an `i386` build, the build
 is probably an `x86_64` build and the `architecture` argument can be omitted.
 
-For reproducing a `coverage` build failure, follow
+If you need to reproduce a `coverage` build failure, follow the
 [Code Coverage page]({{ site.baseurl }}/advanced-topics/code-coverage) to build
-your project and generate a code coverage report.
+your project and generate a code coverage report.
\ No newline at end of file