Minor grammatical corrections and improvements (#23886)

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -13,14 +13,14 @@ This section discusses how to develop, debug, review, and test modules.
 Ansible modules are reusable, standalone scripts that can be used by the Ansible API,
 or by the :command:`ansible` or :command:`ansible-playbook` programs.  They
 return information to ansible by printing a JSON string to stdout before
-exiting.  They take arguments in in one of several ways which we'll go into
+exiting.  They take arguments in one of several ways which we'll go into
 as we work through this tutorial.
 
 See :doc:`../modules` for a list of existing modules.
 
 Modules can be written in any language and are found in the path specified
 by :envvar:`ANSIBLE_LIBRARY` or the ``--module-path`` command line option or
-in the `library section of the Ansible configration file <http://docs.ansible.com/ansible/intro_configuration.html#library>`_.
+in the `library section of the Ansible configuration file <http://docs.ansible.com/ansible/intro_configuration.html#library>`_.
 
 .. _module_dev_should_you:
 

docs/docsite/rst/dev_guide/developing_modules_best_practices.rst

@@ -18,7 +18,7 @@ and guidelines:
 
 * If packaging modules in an RPM, they only need to be installed on the control machine and should be dropped into /usr/share/ansible.  This is entirely optional and up to you.
 
-* Modules must output valid JSON only. The toplevel return type must be a hash (dictionary) although they can be nested.  Lists or simple scalar values are not supported, though they can be trivially contained inside a dictionary.
+* Modules must output valid JSON only. The top level return type must be a hash (dictionary) although they can be nested.  Lists or simple scalar values are not supported, though they can be trivially contained inside a dictionary.
 
 * In the event of failure, a key of 'failed' should be included, along with a string explanation in 'msg'.  Modules that raise tracebacks (stacktraces) are generally considered 'poor' modules, though Ansible can deal with these returns and will automatically convert anything unparseable into a failed result.  If you are using the AnsibleModule common Python code, the 'failed' element will be included for you automatically when you call 'fail_json'.
 
@@ -72,7 +72,7 @@ your debugging session will start:
 
 Setting :envvar:`ANSIBLE_KEEP_REMOTE_FILES` to ``1`` tells Ansible to keep the
 remote module files instead of deleting them after the module finishes
-executing.  Giving Ansible the ``-vvv`` optin makes Ansible more verbose.
+executing.  Giving Ansible the ``-vvv`` option makes Ansible more verbose.
 That way it prints the file name of the temporary module file for you to see.
 
 If you want to examine the wrapper file you can.  It will show a small python
@@ -103,13 +103,13 @@ When you look into the debug_dir you'll see a directory structure like this::
 
 * The :file:`args` file contains a JSON string.  The string is a dictionary
   containing the module arguments and other variables that Ansible passes into
-  the module to change it's behaviour.  If you want to modify the parameters
+  the module to change its behaviour.  If you want to modify the parameters
   that are passed to the module, this is the file to do it in.
 
 * The :file:`ansible` directory contains code from
   :mod:`ansible.module_utils` that is used by the module.  Ansible includes
   files for any :`module:`ansible.module_utils` imports in the module but not
-  no files from any other module.  So if your module uses
+  any files from any other module.  So if your module uses
   :mod:`ansible.module_utils.url` Ansible will include it for you, but if
   your module includes :mod:`requests` then you'll have to make sure that
   the python requests library is installed on the system before running the
@@ -183,7 +183,7 @@ how the command module is implemented.
 If a module returns stderr or otherwise fails to produce valid JSON, the actual output
 will still be shown in Ansible, but the command will not succeed.
 
-Don't write to files directly; use a temporary file and then use the `atomic_move` function from `ansibile.module_utils.basic` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept.
+Don't write to files directly; use a temporary file and then use the `atomic_move` function from `ansible.module_utils.basic` to move the updated temporary file into place. This prevents data corruption and ensures that the correct context for the file is kept.
 
 Avoid creating a module that does the work of other modules; this leads to code duplication and divergence, and makes things less uniform, unpredictable and harder to maintain. Modules should be the building blocks. Instead of creating a module that does the work of other modules, use Plays and Roles instead.  
 

docs/docsite/rst/dev_guide/developing_modules_general.rst

@@ -3,7 +3,7 @@
 Building A Simple Module
 ````````````````````````
 
-Let's build a very-basic module to get and set the system time.  For starters, let's build
+Let's build a very basic module to get and set the system time.  For starters, let's build
 a module that just outputs the current time.
 
 We are going to use Python here but any language is possible.  Only File I/O and outputting to standard
@@ -71,7 +71,7 @@ If you did not, you might have a typo in your module, so recheck it and try agai
 Reading Input
 `````````````
 Let's modify the module to allow setting the current time.  We'll do this by seeing
-if a key value pair in the form `time=<string>` is passed in to the module.
+if a key value pair in the form `time=<string>` is passed into the module.
 
 Ansible internally saves arguments to an arguments file.  So we must read the file
 and parse it.  The arguments file is just a string, so any form of arguments are legal.