clarify pre-release instuctions

docs/development/release_management.rst

@@ -35,13 +35,19 @@ Pre-Release
 -----------
 
 1. Open a **Release SecureDrop <major>.<minor>.<patch>** issue to track release-related activity.
-   Keep this issue updated as you proceed through the release process for
-   transparency.
+   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. You can compare it with the
+   `Tails release calendar <https://tails.boum.org/contribute/calendar/>`_ if you're not sure. The
+   goal is to make sure we test against the lastest Tails release, including release candidates,
+   so that we can report 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
-   and upgrade Tor following these steps:
+   SecureDrop release. Also check for any new release candidates so that we're aware of any
+   upcoming major bug fixes and communicate them to the team. You can find releases by checking the
+   `Tor blog <https://blog.torproject.org/category/tags/stable-release>`_. If there is a new
+   stable release, file an issue and upgrade Tor following these steps:
 
       a. Bump the version in `fetch-tor-packages
          <https://github.com/freedomofpress/securedrop/blob/develop/molecule/fetch-tor-packages/
@@ -54,19 +60,9 @@ Pre-Release
       c. Copy the downloaded packages into the ``securedrop-dev-packages-lfs`` repo,
          and open a PR so that a reviewer can verify that the checksums match the checksums
          of the packages hosted on the
-         `Tor apt repo <https://deb.torproject.org/torproject.org/pool/main/>`_. Once the PR is merged, the
-         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.
+         `Tor apt repo <https://deb.torproject.org/torproject.org/pool/main/>`_. Once the PR is
+         merged, the packages will be resigned with our an FPF-managed test-only signing key,
+         replacing the Tor signature, and served from ``apt-test.freedom.press``.
 
 #. Create a release branch.
 
@@ -83,10 +79,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
@@ -95,7 +93,7 @@ Pre-Release
       script, you will need to pass it the new version in the format
       ``<major>.<minor>.<patch>~rcN``::
 
-        securedrop/bin/dev-shell ../update_version.sh <major>.<minor>.<patch>~rcN
+        bin/dev-shell ../update_version.sh <major>.<minor>.<patch>~rcN
 
       .. note:: A tilde is used in the version number passed to ``update_version.sh`` to match
                 the format specified in the `Debian docs
@@ -120,6 +118,9 @@ Pre-Release
 
         git push origin <major>.<minor>.<patch>-rcN
 
+   #. Once the tag is pushed, notify the Localization Manager so that the localization team can get
+      started on translations.
+
 #. Build Debian packages:
 
    a. Check out the tag for the release candidate.
@@ -129,18 +130,17 @@ Pre-Release
       <https://github.com/freedomofpress/securedrop/wiki/Build-logs>`_.
    #. Open a PR on `securedrop-dev-packages-lfs
       <https://github.com/freedomofpress/securedrop-dev-packages-lfs>`_ that targets the `main`
-      branch. Changes merged to this branch will be published to ``apt-test.freedom.press``
+      branch with the new deb packages. Do not include tarballs or any debs that would overwrite
+      existing debs. Changes merged to this branch will be published to ``apt-test.freedom.press``
       within 15 minutes.
 
-   .. warning:: Only commit packages with an incremented version number: do not clobber existing
-                packages.  That is, if there is already a deb called e.g.
+   .. warning:: Only commit deb packages with an incremented version number: do not clobber existing
+                packages. That is, if there is already a deb called e.g.
                 ``ossec-agent-3.6.0-amd64.deb`` in ``main``, do not commit a new version of this
                 deb.
 
-   .. note:: If the release contains other packages not created by
-          ``make build-debs``, such as Tor or kernel updates, make
-          sure that they also get pushed to
-          ``apt-test.freedom.press``.
+   .. note:: If the release contains other packages not created by ``make build-debs``, such as Tor
+             or kernel updates, make sure that they also get pushed to ``apt-test.freedom.press``.
 
 #. Write a test plan that focuses on the new functionality introduced in the release. Post for
    feedback and make changes based on suggestions from the community. Once it's ready, publish the
@@ -176,9 +176,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;