explain what syncing is, add example, and modify spacing

Author: sleepyStick

CONTRIBUTING.md

@@ -433,26 +433,34 @@ new feature in PyMongo that has spec tests already implemented, or if
 you are attempting to validate new spec tests in PyMongo.
 
 ### Automated Specification Test Resyncing
-`/.evergreen/scripts/resync-all-specs.sh` is a script that will
-automatically run once a week. This script calls a python script
-`.evergreen/scripts/resync-all-specs.py` that actually does all
-the resyncing. Then, any desired un-syncing will be accomplished
-with the help of patch files through a `git apply -R`. If
-appropriate, the bash script then calls
-`.evergreen/scripts/create-pr.sh` that actually publishes a PR.
+There is a script (`/.evergreen/scripts/resync-all-specs.sh`) that will
+automatically run once a week to resync all the specs with the [specifications
+repo](https://github.com/mongodb/specifications).
+If there are changes, a PR will be generated by mongodb-drivers-pr-bot.
+If any errors occurred, the PR description will display the name of the spec along
+with stderr from the `bash resync-spec.sh <spec>` command.
 
 There are three patch files that contain known test differences between
 PyMongo's tests and the specification:
-`.evergreen/patch/diff.patch`: tests where 
-PyMongo intentionally behaves differently than the specification. This file should rarely be modified, as most of these represent fundamental differences in design or behavior.
-`.evergreen/patch/new.patch`: tests for new features that have not yet been implemented in PyMongo. Tests must be removed from this file as part of the PR that implements their feature. 
-`.evergreen/patch/update.patch`: tests that have been updated in a way that causes them to fail until their associated driver change is implemented. Tests must be removed from this file as part of the PR that implements the fix or behavioral change.
+`.evergreen/patch/diff.patch`: tests where PyMongo intentionally behaves differently than the specification.
+This file should rarely be modified, as most of these represent fundamental differences in design or behavior.
+`.evergreen/patch/new.patch`: tests for new features that have not yet been implemented in PyMongo.
+Tests must be removed from this file as part of the PR that implements their feature.
+`.evergreen/patch/update.patch`: tests that have been updated in a way that causes them to fail until their
+associated driver change is implemented. Tests must be removed from this file as part of the PR that implements
+the fix or behavioral change.
 
 #### Adding to a patch file
 Assuming the changes are committed somewhere, to add to any of the
 patch files, run `git diff` to show the desired changes and paste the
 results into the patch file.
 
+For example, there are new test files on the most recent commit of the current branch that are failing.
+To add those changes to `new.patch`, I would do the following:
+```bash
+git diff HEAD~1 path/to/new/file >> .evergreen/patch/new.patch
+```
+
 ## Making a Release
 
 Follow the [Python Driver Release Process Wiki](https://wiki.corp.mongodb.com/display/DRIVERS/Python+Driver+Release+Process).