DOC: Fix typos and remove trailing whitespace.

Author: Hristo Georgiev

docs/source/bundles.rst

@@ -133,7 +133,7 @@ API key we may run:
 though we may still run ``ingest`` as an anonymous quandl user (with no API
 key). We may also set the ``QUANDL_DOWNLOAD_ATTEMPTS`` environment variable to
 an integer which is the number of attempts that should be made to download data
-from quandls servers. By default ``QUANDL_DOWNLOAD_ATTEMPTS`` will be 5, meaning
+from quandl's servers. By default ``QUANDL_DOWNLOAD_ATTEMPTS`` will be 5, meaning
 that we will retry each attempt 5 times.
 
 .. note::
@@ -180,7 +180,7 @@ The signature of the ingest function should be:
 
 ``environ`` is a mapping representing the environment variables to use. This is
 where any custom arguments needed for the ingestion should be passed, for
-example: the ``quandl`` bundle uses the enviornment to pass the API key and the
+example: the ``quandl`` bundle uses the environment to pass the API key and the
 download retry attempt count.
 
 ``asset_db_writer``
@@ -227,7 +227,7 @@ used to convert data into zipline's internal bcolz format to later be read by a
 provided, users should call
 :meth:`~zipline.data.minute_bars.BcolzDailyBarWriter.write` with an iterable of
 (sid dataframe) tuples. The ``show_progress`` argument should also be forwarded
-to this method. If the data shource does not provide daily data, then there is
+to this method. If the data source does not provide daily data, then there is
 no need to call the write method. It is also acceptable to pass an empty
 iterable to :meth:`~zipline.data.minute_bars.BcolzMinuteBarWriter.write` to
 signal that there is no daily data. If no daily data is provided but minute data
@@ -280,7 +280,7 @@ an ingestion crashes part way through. The idea is that the ingest function
 should check the cache for raw data, if it doesn't exist in the cache, it should
 acquire it and then store it in the cache. Then it can parse and write the
 data. The cache will be cleared only after a successful load, this prevents the
-ingest function from needing to redownload all the data if there is some bug in
+ingest function from needing to re-download all the data if there is some bug in
 the parsing. If it is very fast to get the data, for example if it is coming
 from another local file, then there is no need to use this cache.
 
@@ -331,7 +331,7 @@ Once you have your data in the correct format, you can edit your ``extension.py`
 .. code-block:: python
 
 	 import pandas as pd
-	 
+
 	 from zipline.data.bundles import register
 	 from zipline.data.bundles.csvdir import csvdir_equities
 
@@ -367,8 +367,8 @@ To finally ingest our data, we can run:
 	 Loading custom pricing data:   [########################------------]   66% | FAKE1: sid 1
 	 Loading custom pricing data:   [####################################]  100% | FAKE2: sid 2
 	 Loading custom pricing data:   [####################################]  100%
-	 Merging daily equity files:  [####################################]  
-	 
+	 Merging daily equity files:  [####################################]
+
 	 # optionally, we can pass the location of our csvs via the command line
 	 $ CSVDIR=/path/to/your/csvs zipline ingest -b custom-csvdir-bundle
 

docs/source/release-process.rst

@@ -8,7 +8,7 @@ Updating the Release Notes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When we are ready to ship a new release of zipline, edit the :doc:`releases`
-page. We will have been maintaining a whatsnew file while working on the release
+page. We will have been maintaining a ``whatsnew`` file while working on the release
 with the new version. First, find that file in:
 ``docs/source/whatsnew/<version>.txt``. It will be the highest version number.
 Edit the release date field to be today's date in the format:
@@ -19,7 +19,7 @@ Edit the release date field to be today's date in the format:
 
 
 for example, November 6, 2015.
-Remove the active development warning from the whatsnew, since it will no
+Remove the active development warning from the ``whatsnew``, since it will no
 longer be pending release.
 Update the title of the release from "Development" to "Release x.x.x" and
 update the underline of the title to match the title's width.
@@ -233,13 +233,13 @@ may be specified with the ``--user`` flag.
 Next Commit
 ~~~~~~~~~~~
 
-Push a new commit post-release that adds the whatsnew for the next release,
+Push a new commit post-release that adds the ``whatsnew`` for the next release,
 which should be titled according to a micro version increment. If that next
 release turns out to be a major/minor version increment, the file can be
 renamed when that's decided. You can use ``docs/source/whatsnew/skeleton.txt``
 as a template for the new file.
 
-Include the whatsnew file in ``docs/source/releases.rst``. New releases should
+Include the ``whatsnew`` file in ``docs/source/releases.rst``. New releases should
 appear at the top. The syntax for this is:
 
 ::