diff --git a/RELEASE.md b/RELEASE.md
index 6df524504..768f139d6 100644
--- a/RELEASE.md
+++ b/RELEASE.md
@@ -7,6 +7,8 @@ This section documents the release process. Unless you're a dangerzone developer
 Before making a release, all of these should be complete:
 
 - [ ] [Add new Linux platforms and remove obsolete ones](#add-new-platforms-and-remove-obsolete-ones)
+- [ ] Bump the Python dependencies using `poetry lock`
+- [ ] [Check for new PySide6 versions](#check-for-new-pyside6-versions)
 - [ ] Update `version` in `pyproject.toml`
 - [ ] Update `share/version.txt`
 - [ ] Update the "Version" field in `install/linux/dangerzone.spec`
@@ -48,6 +50,30 @@ In case of an EOL version:
    * Consult the previous paragraph, but also `grep` your way around.
 2. Add a notice in our `CHANGELOG.md` about the version removal.
 
+## Check for new PySide6 versions
+
+When a new PySide6 version has been released, we will get notified  because the
+nightly CI tests on `freedomofpres/python3-pyside6-rpm` will start failing.
+
+Even if we miss these notifications, we will see failing builds in the
+Dangerzone repo once we update our `poetry.lock` file. More specifically,
+`./dev_scripts/env.py --distro fedora [...]  build` will start failing, because
+it won't be able to find a PySide6 RPM for the new version.
+
+The Dangerzone maintainer should do the following:
+
+1. Check the changelog for the new PySide6 version, and ensure it doesn't
+   introduce a breaking change.
+2. Clone locally the https://github.com/freedomofpress/python3-pyside6-rpm repo.
+3. Bump the PySide6 version and create a new PySide6 RPM for the supported
+   Fedora versions.
+4. Copy it under the `dist/` directory of the Dangerzone repo.
+5. Create an end-user build environment with `./dev_scripts/env.py --distro fedora [...]  build`
+6. Test that the Dangerzone UI works properly.
+7. Ship the new PySide6 RPMs in our Fedora repo
+   (https://github.com/freedomofpress/yum-tools-prod)
+8. Send a PR to the Dangerzone repo, with the new `poetry.lock` file.
+
 ## Large Document Testing
 
 Parallel to the QA process, the release candidate should be put through the large document tests in a dedicated machine to run overnight.
@@ -61,7 +87,6 @@ These tests will identify any regressions or progression in terms of document co
 To ensure that new releases do not introduce regressions, and support existing
 and newer platforms, we have to do the following:
 
-- [ ] Bump the Python dependencies using `poetry lock`
 - [ ] Make sure that the tip of the `main` branch passes the CI tests.
 - [ ] Make sure that the Apple account has a valid application password and has
       agreed to the latest Apple terms (see [macOS release](#macos-release)