Apply suggestions from code review

Co-authored-by: Ethan Paul <24588726+enpaul@users.noreply.github.com>

docs/continuous_integration.rst

@@ -5,7 +5,7 @@ Continuous Integration
 
 The SecureDrop project uses `GitHub Actions <https://docs.github.com/en/actions>`_ for
 running automated continuous integration on code changes. You can get an overview of what
-each project does by reviewing the ``Makefile`` and files in the ``.github/workflows`` folder.
+each project does by reviewing the ``Makefile`` and files in the ``.github/workflows`` folder of the project's repository.
 
 Basics
 ------
@@ -26,7 +26,7 @@ which can also be used to reproduce CI results locally. Some projects, like ``se
 Pull requests
 -------------
 
-Most CI jobs are triggered by both ``push`` and ``pull_request`` events. The former is run against
+Most CI jobs are `triggered <https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows>`_ by both ``push`` and ``pull_request`` events. The former is run against
 your branch, while the latter is run against your branch merged into ``main`` (or ``develop``).
 
 
@@ -36,14 +36,14 @@ Special branch prefixes
 In the ``securedrop`` repository, some slower jobs are only triggered if a specific branch prefix
 is used when creating the pull request. Currently these are:
 
-* ``stg-*``: runs a staging build in GCE, see :ref:`Configuration Tests<config_tests>`
+* ``stg-*``: runs a staging build in Google Cloud, see :ref:`Configuration Tests<config_tests>`
 * ``l10n-*``: runs localization tests across all 20+ supported languages
 
 Nightlies
 ---------
 
-For ``securedrop-workstation`` and ``securedrop-client``, we build packages on every merged
-commit and every night and publish them to our test yum and apt repositories respectively.
+For ``securedrop-workstation`` and ``securedrop-client``, packages are built for every merged
+commit as well as every night. These packages are published to the test yum and apt repositories.
 
 A "nightlies" workflow runs in each repository that builds the respective packages. The workflow
 uses an authenticated token for the ``sdcibot`` GitHub account to push the packages and build metadata

docs/testing_configuration_tests.rst

@@ -94,13 +94,13 @@ layout of config tests is therefore subject to change.
 Running the CI Staging Environment
 ----------------------------------
 
-The staging environment can also run via CI, running in GCE. These tests are
-run every night or if you push to a branch that starts with ``stg-``. Currently
-this can only be done by members of the ``freedomofpress`` GitHub organization,
-please ask if you'd like someone to run the tests for you.
+The staging environment can also run via CI in Google Cloud (GCE). These tests are
+run every night or if a member of the ``freedomofpress`` Github Organization
+pushes to a branch that starts with ``stg-``. Please ask in your PR if you'd like
+someone to run the tests for you.
 
-You can also run them yourself if you have a Google Cloud Platform account and Docker
-installed locally.
+The tests can also be run manually with a Google Cloud Platform account and Docker
+installed locally:
 
 Source the setup script using the following command:
 
@@ -110,9 +110,9 @@ Source the setup script using the following command:
 
 You will be prompted for the values of the required environment variables. There
 are some defaults set that you may want to change. You will need to export
-``GOOGLE_CREDENTIALS`` with authentication details for your GCP account,
-which is outside the scope of this guide. Some parameters are specific to FPF's
-GCE setup and may need adjusting if you are running elsewhere.
+``GOOGLE_CREDENTIALS`` with `authentication details <https://cloud.google.com/docs/authentication/use-cases>`_
+for your GCP account, which is outside the scope of this guide. Some parameters
+are specific to FPF's GCE setup and may need adjusting if you are running elsewhere.
 
 Then to run the tests locally: