clarify pre-release instuctions

docs/development/release_management.rst

@@ -38,6 +38,11 @@ Pre-Release
    Keep this issue updated as you proceed through the release process for
    transparency.
 
+#. Copy a link of the latest release or release candidate from the `Tails apt repo
+   <https://deb.tails.boum.org/dists/>`_ and include it in the issue. This is to ensure QA tests
+   against the latest release/ release candidate and can report any release candidate bugs early to
+   Tails.
+
 #. Check if there is a new stable release of Tor that can be QAed and released as part of the
    SecureDrop release. You can find stable releases by checking the `Tor blog
    <https://blog.torproject.org/category/tags/stable-release>`_. If we can upgrade, file an issue
@@ -58,16 +63,6 @@ Pre-Release
          packages will be resigned with our an FPF-managed test-only signing key, replacing the Tor
          signature, and served from ``apt-test.freedom.press``.
 
-#. Check if a new release or release candidate for Tails has been added to the `Tails apt repo
-   <https://deb.tails.boum.org/dists/>`_. If so, request
-   people participating in QA to use the latest release candidate.
-
-#. Work with the Communications Manager assigned for the release to prepare a pre-release
-   announcement that will be shared on the support.freedom.press support portal, securedrop.org
-   website, and Twitter. Wait until the day of the release before including an announcmement for a
-   SecureDrop security update. For a point release, you may be able to skip the pre-release
-   announcement depending on how small the point release is.
-
 #. Create a release branch.
 
    For a regular release, create a release branch off of ``develop``::
@@ -83,10 +78,12 @@ Pre-Release
 
 #. For each release candidate, update the version and changelog.
 
-   a. Collect a list of important changes from the `SecureDrop milestones
-      <https://github.com/freedomofpress/securedrop/milestones>`_ for the release, including
-      GitHub issues or PR numbers for each change. You will add these changes to the changelog in
-      the next step.
+   a. Collect a list of changes since the last release. For example, if the last release was version
+      1.6.0, you can view changes in Github by running:
+      `https://github.com/freedomofpress/securedrop/compare/release/1.6.0...develop`. Also check
+      `SecureDrop milestones <https://github.com/freedomofpress/securedrop/milestones>`_ to make
+      sure all milestone changes there are included. Include GitHub PR numbers for each change.
+      You will add these changes to the changelog in the next step.
 
    #. Run ``update_version.sh`` in the dev shell to update the version and changelog. The script
       will open both the main repository changelog (``changelog.md``) and the one used for Debian
@@ -176,9 +173,14 @@ Pre-Release
      is done, ensure that no changes involving string changes are
      backported into the release branch.
 
-   * Work with the Communications Manager to ensure that a draft of the release
-     notes are prepared and shared for review, and that a draft PR is prepared
-     into the ``securedrop-docs`` repository which:
+   * Work with the Communications Manager assigned for the release to prepare a pre-release
+     announcement that will be shared on the support.freedom.press support portal, securedrop.org
+     website, and Twitter. Wait until the day of the release before including an announcmement for a
+     SecureDrop security update. For a point release, you may be able to skip the pre-release
+     announcement depending on how small the point release is.
+
+     Make sure a draft of the release notes are prepared and shared for review, and that a draft PR
+     is prepared into the ``securedrop-docs`` repository which:
 
      - bumps the SecureDrop version of the documentation using the ``update_version.sh``
        script in that repository;