Backport of 67645 docs/docsite/rst/: fix typos (#67649)

8 files changed, 9 insertions, 9 deletions

diff --git a/docs/docsite/rst/community/how_can_I_help.rst b/docs/docsite/rst/community/how_can_I_help.rst
index 9fa8faa863..fc71e0f5d2 100644
--- a/docs/docsite/rst/community/how_can_I_help.rst
+++ b/docs/docsite/rst/community/how_can_I_help.rst
@@ -33,7 +33,7 @@ You can find the official :ref:`Ansible communication channels <communication>`.
 Review, fix, and maintain the documentation
 ===========================================
 
-Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find out-dated examples. We offer easy ways to :ref:`report and/or fix documentation errors <community_documentation_contributions>`.
+Typos are everywhere, even in the Ansible documentation. We work hard to keep the documentation up-to-date, but you may also find outdated examples. We offer easy ways to :ref:`report and/or fix documentation errors <community_documentation_contributions>`.
 
 .. _ansible_community_meetup:
 
diff --git a/docs/docsite/rst/galaxy/dev_guide.rst b/docs/docsite/rst/galaxy/dev_guide.rst
index 0e55046f1a..e94d6ac186 100644
--- a/docs/docsite/rst/galaxy/dev_guide.rst
+++ b/docs/docsite/rst/galaxy/dev_guide.rst
@@ -4,7 +4,7 @@
 Galaxy Developer Guide
 **********************
 
-You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formated in pre-packaged units of work such as `roles <playbooks_reuse_roles>`_, and new in Galaxy 3.2, `collections <collections>`_.
+You can host collections and roles on Galaxy to share with the Ansible community. Galaxy content is formatted in pre-packaged units of work such as `roles <playbooks_reuse_roles>`_, and new in Galaxy 3.2, `collections <collections>`_.
 You can create roles for provisioning infrastructure, deploying applications, and all of the tasks you do everyday. Taking this a step further, you can create collections which provide a comprehensive package of automation that may include multiple playbooks, roles, modules, and plugins.
 
 .. contents::
@@ -237,7 +237,7 @@ Provide the ID of the integration to be disabled. You can find the ID by using t
 
 .. seealso::
   :ref:`collections`
-    Sharable collections of modules, playbooks and roles
+    Shareable collections of modules, playbooks and roles
   :ref:`playbooks_reuse_roles`
     All about ansible roles
   `Mailing List <https://groups.google.com/group/ansible-project>`_
diff --git a/docs/docsite/rst/galaxy/user_guide.rst b/docs/docsite/rst/galaxy/user_guide.rst
index 5ef4744e07..d20f6824e5 100644
--- a/docs/docsite/rst/galaxy/user_guide.rst
+++ b/docs/docsite/rst/galaxy/user_guide.rst
@@ -443,6 +443,6 @@ Use ``remove`` to delete a role from *roles_path*:
 
 .. seealso::
   :ref:`collections`
-    Sharable collections of modules, playbooks and roles
+    Shareable collections of modules, playbooks and roles
   :ref:`playbooks_reuse_roles`
     Reusable tasks, handlers, and other files in a known directory structure
diff --git a/docs/docsite/rst/plugins/cliconf.rst b/docs/docsite/rst/plugins/cliconf.rst
index f6b83d80d6..a0bee4da79 100644
--- a/docs/docsite/rst/plugins/cliconf.rst
+++ b/docs/docsite/rst/plugins/cliconf.rst
@@ -7,7 +7,7 @@ Cliconf Plugins
    :local:
    :depth: 2
 
-Cliconf plugins are abstactions over the CLI interface to network devices. They provide a standard interface
+Cliconf plugins are abstractions over the CLI interface to network devices. They provide a standard interface
 for Ansible to execute tasks on those network devices.
 
 These plugins generally correspond one-to-one to network device platforms. The appropriate cliconf plugin will
diff --git a/docs/docsite/rst/plugins/netconf.rst b/docs/docsite/rst/plugins/netconf.rst
index a884ed86ca..103a6af174 100644
--- a/docs/docsite/rst/plugins/netconf.rst
+++ b/docs/docsite/rst/plugins/netconf.rst
@@ -7,7 +7,7 @@ Netconf Plugins
    :local:
    :depth: 2
 
-Netconf plugins are abstactions over the Netconf interface to network devices. They provide a standard interface
+Netconf plugins are abstractions over the Netconf interface to network devices. They provide a standard interface
 for Ansible to execute tasks on those network devices.
 
 These plugins generally correspond one-to-one to network device platforms. The appropriate netconf plugin will
diff --git a/docs/docsite/rst/reference_appendices/tower.rst b/docs/docsite/rst/reference_appendices/tower.rst
index 151936dd21..04b8f353d4 100644
--- a/docs/docsite/rst/reference_appendices/tower.rst
+++ b/docs/docsite/rst/reference_appendices/tower.rst
@@ -3,7 +3,7 @@
 Red Hat Ansible Tower
 =====================
 
-`Red Hat Ansible Tower <https://www.ansible.com/products/tower>` is a web console and REST API for operationalizing Ansible across your team, organization, and enterpise. It's designed to be the hub for all of your automation tasks.
+`Red Hat Ansible Tower <https://www.ansible.com/products/tower>` is a web console and REST API for operationalizing Ansible across your team, organization, and enterprise. It's designed to be the hub for all of your automation tasks.
 
 Ansible Tower gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your Ansible Tower inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model
 complex processes.
diff --git a/docs/docsite/rst/scenario_guides/guide_packet.rst b/docs/docsite/rst/scenario_guides/guide_packet.rst
index 74a2df5c9e..28e23b9eba 100644
--- a/docs/docsite/rst/scenario_guides/guide_packet.rst
+++ b/docs/docsite/rst/scenario_guides/guide_packet.rst
@@ -183,7 +183,7 @@ The following playbook will create an SSH key, 3 Packet servers, and then wait u
 
 As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect.
 
-The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified via the 'project_id' parameter. The servers are all provisioned with CoresOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter.
+The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified via the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter.
 
 The ``packet_device`` module has a ``wait_for_public_IPv`` that is used to specify the version of the IP address to wait for (valid values are ``4`` or ``6`` for IPv4 or IPv6). If specified, Ansible will wait until the GET API call for a device contains an Internet-routeable IP address of the specified version. When referring to an IP address of a created device in subsequent module calls, it's wise to use the ``wait_for_public_IPv`` parameter, or ``state: active`` in the packet_device module call.
 
diff --git a/docs/docsite/rst/scenario_guides/guide_rax.rst b/docs/docsite/rst/scenario_guides/guide_rax.rst
index ecfc4b0cd2..19a6dba80d 100644
--- a/docs/docsite/rst/scenario_guides/guide_rax.rst
+++ b/docs/docsite/rst/scenario_guides/guide_rax.rst
@@ -554,7 +554,7 @@ Build a complete webserver environment with servers, custom networks and load ba
 RackConnect and Managed Cloud
 +++++++++++++++++++++++++++++
 
-When using RackConnect version 2 or Rackspace Managed Cloud there are Rackspace automation tasks that are executed on the servers you create after they are successfully built. If your automation executes before the RackConnect or Managed Cloud automation, you can cause failures and un-usable servers.
+When using RackConnect version 2 or Rackspace Managed Cloud there are Rackspace automation tasks that are executed on the servers you create after they are successfully built. If your automation executes before the RackConnect or Managed Cloud automation, you can cause failures and unusable servers.
 
 These examples show creating servers, and ensuring that the Rackspace automation has completed before Ansible continues onwards.