minor edits to docs

.github/CONTRIBUTING.md

@@ -47,13 +47,13 @@ Otherwise, [request a feature](https://github.com/Shopify/polaris-react/issues/n
 
 If you intend to build a new component, change a public API, make design improvements, or any other non-trivial changes, [we recommend filing an issue](https://github.com/Shopify/polaris-react/issues/new?template=FEATURE_REQUEST.md). This lets us all discuss and reach an agreement on the proposal before you put in significant time and effort.
 
-Please use [this template for proposing new components or changes to existing components](https://github.com/Shopify/polaris-react/issues/new?template=NEW_COMPONENT.md).
+Please use this [template for proposing new components or changes to existing components](https://github.com/Shopify/polaris-react/issues/new?template=NEW_COMPONENT.md).
 
 If you’re only fixing a bug, it’s okay to submit a pull request right away but we still recommend you file an issue detailing what you’re fixing. This is helpful in case we don’t accept that specific fix but want to keep track of the issue.
 
 ## Your first pull request
 
-Working on your first Pull Request? You can learn how from this free video series:
+Working on your first pull request? You can learn how from this free video series:
 
 [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github)
 
@@ -102,7 +102,7 @@ After cloning Polaris React, run `yarn` to fetch its dependencies. Then you can
 - `yarn test <pattern>` runs tests with matching filenames
 - `yarn tophat` runs a local development server and mounts all of the component examples
 
-We recommend running `yarn test` (or its variations above) to make sure you don’t introduce any regressions as you work on your change. However it can be handy to try your build of Polaris React in a real project.
+We recommend running `yarn test` (or its variations above), as well as trying your build of Polaris React in a real project, to make sure you don’t introduce any regressions as you work on your change.
 
 Run `yarn run build-consumer <project>` where `<project>` is the directory the build will be copied. **The `<project>` directory must be a sibling of the `polaris-react` directory**.
 

README.md

@@ -176,5 +176,5 @@ Percy is a tool that’s supposed to help you and give you more confidence, not
     ```
     Where `aaaabbbbcccc` is the API key available in the
     [Percy project settings page for polaris-react](https://percy.io/Shopify/polaris-react/settings).
-3.  Check tests results: <https://percy.io/Shopify/polaris-react> (can’t
+3.  Check tests results: <https://percy.io/Shopify/polaris-react> (Can’t
     view the results? [Ask for access on Slack](https://shopify.slack.com/messages/C4Y8N30KD))

documentation/Tophatting.md

@@ -1,6 +1,8 @@
 # Tophatting 🎩
 
-TL;DR This is a collection of lessons learned from breaking things. It’s not enough to rely on automated tests.
+## Summary
+
+This is a collection of lessons learned from breaking things. It’s not enough to rely on automated tests.
 
 As you make changes, non-obvious things can break. Manual testing (we call it “tophatting”, or 🎩 for short) adds that extra degree of certainty that what you’re shipping works and behaves as expected. Both you, as the author of a PR, and someone on your team, should 🎩 before merging.
 
@@ -30,7 +32,7 @@ Spending the extra time to provide clear instructions saves everybody time, and
 - Be explicit about the scope of your changes so that unrelated bugs don’t block the PR
 - Be explicit about your own 🎩, and any areas or interactions you might be unsure about
 - Include a screenshot of the expected result of a successful 🎩
-- Be grateful (e.g. “Thanks for catching that!”) – reviewers are taking time out of their day to help you and that’s a special kind of gift
+- Be grateful (for example, “Thanks for catching that!”) – reviewers are taking time out of their day to help you and that’s a special kind of gift
 
 ## Approach to tophatting someone’s PR
 
@@ -39,7 +41,7 @@ Giving someone a thorough 🎩 builds trust and trains your attention to detail.
 - Make sure you understand the scope and purpose of the author’s PR – if not, don’t hesitate to ask the author to clarify
 - Consider any areas the author’s change may break, and test those
 - Detail what steps you took for 🎩 and your findings
-- Remember that unrelated bugs are better done in a separate PR Don’t block something unless it’s necessary
+- Remember that unrelated bugs are better done in a separate PR. Don’t block something unless it’s necessary
 - Include a screenshot with any issues that arise
 
 ## Cross browser testing