Fix typos in documentation.

DEVELOPMENT_GUIDE.md

@@ -1,6 +1,6 @@
 # Development Guide
 
-_Note: If you haven't read the CONTRIBUTING.md instruction, make sure to do so first before continuing._
+_Note: If you haven't read the CONTRIBUTING.md instructions, make sure to do so before continuing._
 
 ## IO Sources / Sinks
 
@@ -18,27 +18,27 @@ _Note: You can also extend the registry in your own modules to enable domain spe
 
 When you wish to add a new language or kernel to papermill, look in the `translators.py` file.
 
-Like with the iorw pattern, there is a `papermill_translators` object at the root of the file which holds all key-value mappins from kernel / language names to translators. Each Translator inherits from `Translator` which gives the basic JSON conversion structures. Then for each JSON type you'll need to add a the relevant translate_type class method. Additionally, you'll want to implement the `comment` function for mapping single line comments. For languages which have a special format for assigning variables you can also override the assign method (see ScalaTranslator for an example).
+Like with the iorw pattern, there is a `papermill_translators` object at the root of the file which holds all key-value mappings from kernel / language names to translators. Each Translator inherits from `Translator` which gives the basic JSON conversion structures. Then for each JSON type you'll need to add the relevant translate_type class method. Additionally, you'll want to implement the `comment` function for mapping single line comments. For languages which have a special format for assigning variables you can also override the assign method (see ScalaTranslator for an example).
 
-Finally, register the new handler to the `papermill_translators` object. The translator name must either match the kernelor language name being processed to be used for your notebook execution. This will enable any notebook using the named kernel to use your new parameter translations.
+Finally, register the new handler to the `papermill_translators` object. The translator name must either match the kernel or language name being processed to be used for your notebook execution. This will enable any notebook using the named kernel to use your new parameter translations.
 
 Test additions are easy to create -- just copy the few language specific pytest methods in `test_translators.py` and swap to your new translator name / expected values.
 
 ## Engines
 
-By default papermill uses nbconvert to process notebook. But it's setup as a plug-n-play system so any function which can process a notebook and return the output nbformat object can be registered into papermill.
+By default papermill uses nbconvert to process notebooks. But it's setup as a plug-n-play system so any function that can process a notebook and return the output nbformat object can be registered into papermill.
 
-To enable a new engine, first look in `engines.py` at the `NBConvertEngine` as a working example. This class inherits from `Engine` and is required to implement the classmethod `execute_managed_notebook`. The first argument to this method is an `NotebookExecutionManager` -- which is built and passed in the Engine `execute_notebook` classmethod -- and is used to provide callback bindings for cell execution signals.
+To enable a new engine, first look in `engines.py` at the `NBConvertEngine` as a working example. This class inherits from `Engine` and is required to implement the classmethod `execute_managed_notebook`. The first argument to this method is a `NotebookExecutionManager` -- which is built and passed in the Engine `execute_notebook` classmethod -- and is used to provide callback bindings for cell execution signals.
 
 The `NotebookExecutionManager` class tracks the notebook object in progress, which is copied from the input notebook to provide functional execution isolation. It also tracks metadata updates and execution timing. In general you don't need to worry about this class except to know it has a `nb` attribute and three callbacks you can call from your engine implementation.
 
 - `cell_start` takes a cell argument and sets the cell metadata up for execution. This triggers a notebook save.
-- `cell_exception` takes a cell argument and flags the cell as failed. This does **not** triggers a notebook save (as the notebook completion after cell failure will save).
+- `cell_exception` takes a cell argument and flags the cell as failed. This does **not** trigger a notebook save (as the notebook completion after cell failure will save).
 - `cell_complete` takes a cell argument and finalizes timing information in the cell metadata. This triggers a notebook save.
 
 These functions can be optionally called to better render and populate notebooks with appropriate metadata attributes to reflect their execution. Manually saving the notebook object is unnecessary as the base class wrapper will save the notebook on notebook start and completion on your behalf. If you wish to disable saving, overwrite the `wrap_and_execute_notebook` and prevent the `output_path` from propagating to the base method call.
 
-`papermill.execute_notebook` allows to pass arbitrary arguments down to the engine. Make sure that engine handles keyword arguments properly. Use utility `merge_kwargs` and `remove_args` to merge and clean arguments
+`papermill.execute_notebook` allows you to pass arbitrary arguments down to the engine. Make sure that engine handles keyword arguments properly. Use utility `merge_kwargs` and `remove_args` to merge and clean arguments.
 
 To update tests you'll need to add a new test class in `test_engines.py`. Copying the `TestNBConvertEngine` class and modifying it is recommended.
 
@@ -50,4 +50,4 @@ In `cli.py` you'll want to add an `@click.option` above the `papermill` method a
 
 Now in `execute.py`'s `execute_notebook` we want to add the appropriate argument and default it to something sane. Add the argument to the docstring as well. Then pass or use that argument where it's needed to achieve the desired effect. Usually these options get passed to `_execute_parameterized_notebook`.
 
-To update the tests you'll need both `test_cli.py` and `test_execute.py` to include the new option. Though the CLI tests need only check that the appropiate values get passed to `execute_notebook`.
+To update the tests you'll need both `test_cli.py` and `test_execute.py` to include the new option. Though the CLI tests need only check that the appropriate values get passed to `execute_notebook`.

docs/_templates/page.html

@@ -3,7 +3,7 @@
 {# Custom template for page.html
 
    Alabaster theme does not provide blocks for prev/next at bottom of each page.
-   This is _in addition_ to the prev/next in the  sidebar. The "Prev/Next" text
+   This is _in addition_ to the prev/next in the sidebar. The "Prev/Next" text
    or symbols are handled by CSS classes in _static/custom.css
 #}
 

docs/extending-developing.rst

@@ -3,9 +3,9 @@
 Extending papermill by contributing to it
 =========================================
 
-If you find that you'd like to not just add I/O and execution handlers, but
+If you find that you'd like to not only add I/O and execution handlers, but
 think a fundamental aspect of the project could use some improvement, then you
-want contribute to it.
+may want to contribute to it.
 
 Development of papermill happens on github, and a
 `detailed guide to contributing`_ to it can be found there. There is also a