Doc improvements on user guide

This change:

  * fixes some spelling issues
  * externally links to a document describing what a 'git ref' is
  * links to executor document at the first reference to it
  * links to independent pipeline at the first reference to it

Change-Id: I3f2247deac15fd15c9dead6cba537d7b17e8491f
diff --git a/doc/source/admin/components.rst b/doc/source/admin/components.rst
index e30966b..dcaa7b4 100644
--- a/doc/source/admin/components.rst
+++ b/doc/source/admin/components.rst
@@ -229,6 +229,8 @@
 To start the merger, run ``zuul-merger``.  To stop it, kill the
 PID which was saved in the pidfile specified in the configuration.
 
+.. _executor:
+
 Executor
 --------
 
diff --git a/doc/source/user/concepts.rst b/doc/source/user/concepts.rst
index 6197396..318de09 100644
--- a/doc/source/user/concepts.rst
+++ b/doc/source/user/concepts.rst
@@ -40,7 +40,8 @@
 configured with any number of reporters.  See :ref:`drivers` for a
 full list of available reporters.
 
-The items enqueued into a pipeline are each associated with a git ref.
+The items enqueued into a pipeline are each associated with a
+`git ref <https://git-scm.com/book/en/v2/Git-Internals-Git-References>`_.
 That ref may point to a proposed change, or it may be the tip of a
 branch or a tag.  The triggering event determines the ref, and whether
 it represents a proposed or merged commit.  Zuul prepares the ref for
@@ -67,7 +68,7 @@
 change appears.
 
 Jobs specify the type and quantity of nodes which they require.
-Before executing each job, Zuul will contact it's companion program,
+Before executing each job, Zuul will contact its companion program,
 Nodepool, to supply them.  Nodepool may be configured to supply static
 nodes or contact cloud providers to create or delete nodes as
 necessary.  The types of nodes available to Zuul are determined by the
@@ -80,6 +81,6 @@
 script) or sophisticated deployment scenarios.  When Zuul runs
 Ansible, it attempts to do so in a manner most similar to the way that
 Ansible might be used to orchestrate remote systems.  Ansible itself
-is run on the executor and acts remotely upon the test nodes supplied
-to a job.  This facilitates continuous delivery by making it possible
-to use the same Ansible playbooks in testing and production.
+is run on the :ref:`executor <executor>` and acts remotely upon the test
+nodes supplied to a job.  This facilitates continuous delivery by making it
+possible to use the same Ansible playbooks in testing and production.
diff --git a/doc/source/user/gating.rst b/doc/source/user/gating.rst
index c1d04a7..795df72 100644
--- a/doc/source/user/gating.rst
+++ b/doc/source/user/gating.rst
@@ -227,7 +227,8 @@
 
 A given dependent pipeline may have as many shared change queues as
 necessary, so groups of related projects may share a change queue
-without interfering with unrelated projects.  Independent pipelines do
+without interfering with unrelated projects.
+:value:`Independent pipelines <pipeline.manager.independent>` do
 not use shared change queues, however, they may still be used to test
 changes across projects using cross-project dependencies.
 
diff --git a/doc/source/user/index.rst b/doc/source/user/index.rst
index 3eca04b..8c7308b 100644
--- a/doc/source/user/index.rst
+++ b/doc/source/user/index.rst
@@ -4,7 +4,7 @@
 This guide is for all users of Zuul.  If you work on a project where
 Zuul is used to drive automation (whether that's testing proposed
 changes, building artifacts, or deploying builds), this guide will
-help you understand the concepts that underly Zuul, and how to
+help you understand the concepts that underlie Zuul, and how to
 configure it to meet your needs.