diff --git a/docs/development/release_management.rst b/docs/development/release_management.rst
index fc42627db..7be276820 100644
--- a/docs/development/release_management.rst
+++ b/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
+ `_ 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
`_. 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
- `_. 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
- `_ 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 `_ 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;