diff --git a/accepted/0000-salt-new-maintaining-workflow.md b/accepted/0000-salt-new-maintaining-workflow.md
index e20f5b9c..425268a5 100644
--- a/accepted/0000-salt-new-maintaining-workflow.md
+++ b/accepted/0000-salt-new-maintaining-workflow.md
@@ -63,7 +63,7 @@ pkg/suse/html.tar.bz2
 pkg/suse/salt-tmpfiles.d
 pkg/suse/transactional_update.conf
 pkg/suse/update-documentation.sh
-pkg/suse/mkchlog.sh
+pkg/suse/rpmchangelogs
 pkg/suse/_multibuild
 pkg/suse/salt.spec
 pkg/suse/changelogs/factory/salt.changes
@@ -77,41 +77,19 @@ This is the place now where all those files will be maintained.
 
 #### Tracking upstream and downstream patches
 
-This RFC proposes the usage of "obs_scm" service as the mechanism to pull the sources for the Salt package to build. This service will automatically produce a sources tarball according to a configured GitHub branch.
+This RFC proposes the usage of "obs_scm" service as the mechanism to pull the sources for the Salt package to build. This service generates a sources tarball based on the content of a configured GitHub repository.
 
-For the regular Salt maintenance, this means it won't be needed anymore to manually produce patch files to add them to the spec file, as the tarball now contains the updated sources (with the exception of EMBARGOED bugs, where patches are still needed as we cannot push any fix to public GitHub repositories).
+Except for bugs under embargo, we won't use patches in the spec file. The generated tarball includes the latest changes we merged into our `openSUSE/release/<current release>` branch.
+Bugs under embargo use a different workflow with manually created patches since we cannot push fixes for such bugs to our public Github repository.
 
-To avoid losing the useful labeling of "PATCH-FIX_UPSTREAM" and "PATCH-FIX_OPENSUSE" (with a direct link to the origin PR on the spec file for each new patch we introduced into our Salt package), we will keep adding this information to the spec file on every new PR but this time without adding the patch itself, only the comment.
+We will therefore not track bug fixes in the spec file anymore. The origin of a bug fix, i.e. whether it is backport from upstream or not, will be stored in a Git note attached to the commit of each bug fix. Git notes can be added after bug fixes are merged  without modifying the Git history.
 
 #### Salt RPM changelogs
 
-As mentioned, the changelog files are now maintained in the `openSUSE/salt` GitHub repo, under `pkg/suse/changelogs/` directory.
+As mentioned, the changelog files are now maintained in the `openSUSE/salt` GitHub repo, under `pkg/suse/changelogs/` directory. New changelog are part of pull requests to `openSUSE/salt`.
+Our packaging artifacts will contain a `rpmchangelogs` Python script to easily `add`, `modify` and `remove` changelog entries for all changelogs at once.
 
-Our packaging artifacts will contain a `mkchlog.sh`, which is a helper script to generate a changelog entry to all maintained changelog in one shot. Something like this:
-
-```bash
-echo "Generating changelog entry for Salt package"
-if ! osc vc _temp.changes;
-then
-    exit 1;
-fi
-
-echo "Update changelog files"
-echo >> _temp.changes
-
-for i in $(ls changelogs/*/salt.changes); do
-    echo "$(cat _temp.changes $i)" > $i
-    git add $i
-done
-
-rm _temp.changes
-```
-
-When creating a PR to `openSUSE/salt` the user must also include the corresponding changelog entry for all maintained changelog files.
-
-Similarly to the main Uyuni repository, we should add a GitHub action to warn the user in case no changelog entry is added in the PR.
-
-NOTE: I think it is better to decouple commit messages (focus on developers) from changelog entries (focus on users/customers), so I prefer to not use commit messages from "openSUSE/salt" to autogenerate the changelog entries but rather to manually write a meaningful changelog message to be included in your PR as part of your changes. Similarly to what we do in other Uyuni repositories.
+We will use a Github status check to prevent us from merging pull requests without changelogs, like we already do in `uyuni-project/uyuni`
 
 ### OBS project structure