diff --git a/doc/source/launchers.rst b/doc/source/executors.rst
similarity index 97%
rename from doc/source/launchers.rst
rename to doc/source/executors.rst
index c9dbd99..5f85f58 100644
--- a/doc/source/launchers.rst
+++ b/doc/source/executors.rst
@@ -1,4 +1,4 @@
-:title: Launchers
+:title: Executors
 
 .. _Gearman: http://gearman.org/
 
@@ -11,27 +11,27 @@
 .. _`Turbo-Hipster Documentation`:
    http://turbo-hipster.rtfd.org/
 
-.. _launchers:
+.. _executors:
 
-Launchers
+Executors
 =========
 
-Zuul has a modular architecture for launching jobs.  Currently, the
+Zuul has a modular architecture for executing jobs.  Currently, the
 only supported module interfaces with Gearman_.  This design allows
 any system to run jobs for Zuul simply by interfacing with a Gearman
 server.  The recommended way of integrating a new job-runner with Zuul
 is via this method.
 
-If Gearman is unsuitable, Zuul may be extended with a new launcher
+If Gearman is unsuitable, Zuul may be extended with a new executor
 module.  Zuul makes very few assumptions about the interface to a
-launcher -- if it can trigger jobs, cancel them, and receive success
+executor -- if it can trigger jobs, cancel them, and receive success
 or failure reports, it should be able to be used with Zuul.  Patches
 to this effect are welcome.
 
 Zuul Parameters
 ---------------
 
-Zuul will pass some parameters with every job it launches.  These are
+Zuul will pass some parameters with every job it executes.  These are
 for workers to be able to get the repositories into the state they are
 intended to be tested in.  Builds can be triggered either by an action
 on a change or by a reference update.  Both events share a common set
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 784fc4d..3f903db 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -21,7 +21,7 @@
    zuul
    merger
    cloner
-   launchers
+   executors
    statsd
    client
    developer
diff --git a/doc/source/merger.rst b/doc/source/merger.rst
index 82e204b..d8de702 100644
--- a/doc/source/merger.rst
+++ b/doc/source/merger.rst
@@ -30,7 +30,7 @@
 Git reference of the form ``refs/zuul/<branch>/Z<random sha1>``.
 Preparing the workspace is then a simple matter of fetching that ref
 and checking it out.  The parameters that provide this information are
-described in :ref:`launchers`.
+described in :ref:`executors`.
 
 These references need to be made available via a Git repository that
 is available to workers (such as Jenkins).  This is accomplished by
diff --git a/doc/source/quick-start.rst b/doc/source/quick-start.rst
index 82779c6..6d16c92 100644
--- a/doc/source/quick-start.rst
+++ b/doc/source/quick-start.rst
@@ -19,7 +19,7 @@
 Zuul provides the following components:
 
     - **zuul-server**: scheduler daemon which communicates with Gerrit and
-      Gearman. Handles receiving events, launching jobs, collecting results
+      Gearman. Handles receiving events, executing jobs, collecting results
       and postingreports.
     - **zuul-merger**: speculative-merger which communicates with Gearman.
       Prepares Git repositories for jobs to test against. This additionally
diff --git a/doc/source/statsd.rst b/doc/source/statsd.rst
index b3bf99f..fb6989e 100644
--- a/doc/source/statsd.rst
+++ b/doc/source/statsd.rst
@@ -17,7 +17,7 @@
 The configuration is done via environment variables STATSD_HOST and
 STATSD_PORT. They are interpreted by the statsd module directly and there is no
 such parameter in zuul.conf yet. Your init script will have to initialize both
-of them before launching Zuul.
+of them before executing Zuul.
 
 Your init script most probably loads a configuration file named
 ``/etc/default/zuul`` which would contain the environment variables::
@@ -61,7 +61,7 @@
       #. **job.<jobname>** subtree detailing per job statistics:
 
         #. **wait_time** counter and timer of the wait time, with the
-                   difference of the job start time and the launch time, in
+                   difference of the job start time and the execute time, in
                    milliseconds.
 
 **zuul.pipeline.**
@@ -88,7 +88,7 @@
       #. **total_changes** counter of the number of change proceeding since
                Zuul started.
       #. **wait_time** counter and timer of the wait time, with the difference
-               of the job start time and the launch time, in milliseconds.
+               of the job start time and the execute time, in milliseconds.
 
   Additionally, the `zuul.pipeline.<pipeline name>` hierarchy contains
   `current_changes` (gauge), `resident_time` (timing) and `total_changes`
diff --git a/doc/source/zuul.rst b/doc/source/zuul.rst
index 4f43596..8b325ba 100644
--- a/doc/source/zuul.rst
+++ b/doc/source/zuul.rst
@@ -635,9 +635,9 @@
 **hold-following-changes (optional)**
   This is a boolean that indicates that changes that follow this
   change in a dependent change pipeline should wait until this job
-  succeeds before launching.  If this is applied to a very short job
+  succeeds before executing.  If this is applied to a very short job
   that can predict whether longer jobs will fail early, this can be
-  used to reduce the number of jobs that Zuul will launch and
+  used to reduce the number of jobs that Zuul will execute and
   ultimately have to cancel.  In that case, a small amount of
   parallelization of jobs is traded for more efficient use of testing
   resources.  On the other hand, to apply this to a long running job
@@ -709,7 +709,7 @@
   a job is voting or not.  Default: ``true``.
 
 **attempts (optional)**
-  Number of attempts zuul will launch a job. Once reached, zuul will report
+  Number of attempts zuul will execute a job. Once reached, zuul will report
   RETRY_LIMIT as the job result.
   Defaults to 3.