Fix grammar and typos in contributing guide (#4545)

* Fix grammar and typos in contributing guide

* Add whats-new entry

Author: sahidvelji

doc/contributing.rst

@@ -40,8 +40,8 @@ report will allow others to reproduce the bug and provide insight into fixing. S
 `this stackoverflow article <https://stackoverflow.com/help/mcve>`_ for tips on
 writing a good bug report.
 
-Trying the bug-producing code out on the *master* branch is often a worthwhile exercise
-to confirm the bug still exists. It is also worth searching existing bug reports and
+Trying out the bug-producing code on the *master* branch is often a worthwhile exercise
+to confirm that the bug still exists. It is also worth searching existing bug reports and
 pull requests to see if the issue has already been reported and/or fixed.
 
 Bug reports must:
@@ -189,7 +189,7 @@ Creating a branch
 -----------------
 
 You want your master branch to reflect only production-ready code, so create a
-feature branch for making your changes. For example::
+feature branch before making your changes. For example::
 
     git branch shiny-new-feature
     git checkout shiny-new-feature
@@ -211,7 +211,7 @@ To update this branch, you need to retrieve the changes from the master branch::
 This will combine your commits with the latest *xarray* git master.  If this
 leads to merge conflicts, you must resolve these before submitting your pull
 request.  If you have uncommitted changes, you will need to ``git stash`` them
-prior to updating.  This will effectively store your changes and they can be
+prior to updating.  This will effectively store your changes, which can be
 reapplied after updating.
 
 .. _contributing.documentation:
@@ -277,7 +277,7 @@ Some other important things to know about the docs:
 
   Almost all code examples in the docs are run (and the output saved) during the
   doc build. This approach means that code examples will always be up to date,
-  but it does make the doc building a bit more complex.
+  but it does make building the docs a bit more complex.
 
 - Our API documentation in ``doc/api.rst`` houses the auto-generated
   documentation from the docstrings. For classes, there are a few subtleties
@@ -318,7 +318,7 @@ Then you can find the HTML output in the folder ``xarray/doc/_build/html/``.
 
 The first time you build the docs, it will take quite a while because it has to run
 all the code examples and build all the generated docstring pages. In subsequent
-evocations, sphinx will try to only build the pages that have been modified.
+evocations, Sphinx will try to only build the pages that have been modified.
 
 If you want to do a full clean build, do::
 
@@ -366,7 +366,7 @@ xarray uses several tools to ensure a consistent code format throughout the proj
 
    pip install black flake8 isort mypy blackdoc
 
-and then run from the root of the Xarray repository::
+and then run from the root of the xarray repository::
 
    isort .
    black -t py36 .
@@ -440,7 +440,7 @@ taken from the original GitHub issue.  However, it is always worth considering a
 use cases and writing corresponding tests.
 
 Adding tests is one of the most common requests after code is pushed to *xarray*.  Therefore,
-it is worth getting in the habit of writing tests ahead of time so this is never an issue.
+it is worth getting in the habit of writing tests ahead of time so that this is never an issue.
 
 Like many packages, *xarray* uses `pytest
 <http://doc.pytest.org/en/latest/>`_ and the convenient
@@ -625,7 +625,7 @@ need to install `pytest-xdist` via::
     pip install pytest-xdist
 
 
-Then, run pytest with the optional -n argument:
+Then, run pytest with the optional -n argument::
 
     pytest xarray -n 4
 
@@ -812,7 +812,7 @@ release.  To submit a pull request:
 This request then goes to the repository maintainers, and they will review
 the code. If you need to make more changes, you can make them in
 your branch, add them to a new commit, push them to GitHub, and the pull request
-will be automatically updated.  Pushing them to GitHub again is done by::
+will automatically be updated.  Pushing them to GitHub again is done by::
 
     git push origin shiny-new-feature
 
@@ -836,9 +836,9 @@ Then you can do::
 
 You need to use a upper-case ``-D`` because the branch was squashed into a
 single commit before merging. Be careful with this because ``git`` won't warn
-you if you accidentally delete a unmerged branch.
+you if you accidentally delete an unmerged branch.
 
-If you didn't delete it using GitHub's interface, the branch will still exist on
+If you didn't delete your branch using GitHub's interface, then it will still exist on
 GitHub. To delete it there do::
 
     git push origin --delete shiny-new-feature
@@ -860,4 +860,4 @@ PR checklist
     - Run ``flake8`` in the root directory. If this fails, it will log an error message.
 
 - **Push your code and** `create a PR on GitHub <https://help.github.com/en/articles/creating-a-pull-request>`_.
-- **Use a helpful title for your pull request** by summarizing the main contributions rather than using the latest commit message. If this addresses an `issue <https://github.com/pydata/xarray/issues>`_, please `reference it <https://help.github.com/en/articles/autolinked-references-and-urls>`_.
+- **Use a helpful title for your pull request** by summarizing the main contributions rather than using the latest commit message. If the PR addresses an `issue <https://github.com/pydata/xarray/issues>`_, please `reference it <https://help.github.com/en/articles/autolinked-references-and-urls>`_.

doc/whats-new.rst

@@ -68,7 +68,8 @@ Documentation
 - Raise a more informative error when :py:meth:`DataArray.to_dataframe` is
   is called on a scalar, (:issue:`4228`); 
   By `Pieter Gijsbers <https://github.com/pgijsbers>`_.
-
+- Fix grammar and typos in the :doc:`contributing` guide (:pull:`4545`).
+  By `Sahid Velji <https://github.com/sahidvelji>`_.
 
 Internal Changes
 ~~~~~~~~~~~~~~~~