Merge pull request #1397 from j-t-1/library

Modify using as a library documentation

doc/source/using-as-a-library.rst

@@ -3,7 +3,7 @@ Using Volatility 3 as a Library
 
 This portion of the documentation discusses how to access the Volatility 3 framework from an external application.
 
-The general process of using volatility as a library is to as follows:
+The general process of using volatility as a library is as follows:
 
 1. :ref:`create_context`
 2. (Optional) :ref:`available_plugins`
@@ -21,7 +21,7 @@ Creating a context
 First we make sure the volatility framework works the way we expect it (and is the version we expect).  The
 versioning used is semantic versioning, meaning any version with the same major number and a higher or equal
 minor number will satisfy the requirement.  An example is below since the CLI doesn't need any of the features
-from versions 1.1 or 1.2:
+from version 1.1 or later:
 
 ::
 
@@ -86,7 +86,7 @@ List requirements are a list of simple types (integers, booleans, floats and str
 options, multiple requirements needs all their subrequirements fulfilled and the other types require the names of
 valid translation layers or symbol tables within the context, respectively.  Luckily, each of these requirements can
 tell you whether they've been fulfilled or not later in the process.  For now, they can be used to ask the user to
-fill in any parameters they made need to.  Some requirements are optional, others are not.
+fill in any parameters they may need to.  Some requirements are optional, others are not.
 
 The plugin is essentially a multiple requirement.  It should also be noted that automagic classes can have requirements
 (as can translation layers).
@@ -100,7 +100,7 @@ Once you know what requirements the plugin will need, you can populate them with
 The configuration is essentially a hierarchical tree of values, much like the windows registry.
 Each plugin is instantiated at a particular branch within the hierarchy and will look for its configuration
 options under that hierarchy (if it holds any configurable items, it will likely instantiate those at a point
-underneaths its own branch).  To set the hierarchy, you'll need to know where the configurables will be constructed.
+underneath its own branch).  To set the hierarchy, you'll need to know where the configurables will be constructed.
 
 For this example, we'll assume plugins' base_config_path is set as `plugins`, and that automagics are configured under
 the `automagic` tree.  We'll see later how to ensure this matches up with the plugins and automagic when they're
@@ -139,7 +139,7 @@ A suitable list of automagics for a particular plugin (based on operating system
 
 This will take the plugin module, extract the operating system (first level of the hierarchy) and then return just
 the automagics which apply to the operating system.  Each automagic can exclude itself from being used for specific
-operating systems, so that an automagic designed for linux is not used for windows or mac plugins.
+operating systems, such that an automagic designed for linux is not used for windows or mac plugins.
 
 These automagics can then be run by providing the list, the context, the plugin to be run, the hierarchy name that
 the plugin will be constructed on ('plugins' by default) and a progress_callback.  This is a callable which takes
@@ -157,8 +157,8 @@ Any exceptions that occur during the execution of the automagic will be returned
 Run the plugin
 --------------
 
-Firstly, we should check whether the plugin will be able to run (ie, whether the configuration options it needs
-have been successfully set).  We do this as follow (where plugin_config_path is the base_config_path (which defaults
+Firstly, we should check whether the plugin will be able to run (i.e., whether the configuration options it needs
+have been successfully set).  We do this as follows, where plugin_config_path is the base_config_path (which defaults
 to `plugins` and then the name of the class itself):
 
 ::
@@ -166,7 +166,7 @@ to `plugins` and then the name of the class itself):
     unsatisfied = plugin.unsatisfied(context, plugin_config_path)
 
 If unsatisfied is an empty list, then the plugin has been given everything it requires.  If not, it will be a
-Dictionary of the hierarchy paths and their associated requirements that weren't satisfied.
+dict of the hierarchy paths and their associated requirements that weren't satisfied.
 
 The plugin can then be instantiated with the context (containing the plugin's configuration) and the path that the
 plugin can find its configuration at.  This configuration path only needs to be a unique value to identify where the