diff --git a/doc/source/contributing/how_to_release.md b/doc/source/contributing/how_to_release.md
index 95d23f7f3b..6b8d7109e2 100644
--- a/doc/source/contributing/how_to_release.md
+++ b/doc/source/contributing/how_to_release.md
@@ -46,3 +46,26 @@ ArviZ uses the following process to cut a new release of the library.
    ```
 
 9. If the versions were updated in step 3, update also the [conda forge recipe](https://github.com/conda-forge/arviz-feedstock).
+
+   :::{important}
+   There is a bot that opens a PR automatically to update the conda forge recipe.
+   However, **all dependencies must be checked manually** to ensure the ones in
+   the recipe match those in the requirements
+   :::
+
+10. (here for reference but we really want to avoid it) If for some reason there were an issue
+    with a release, there are two tools to fix it in conda forge:
+
+    * repodata patch: If there is a new release for one of the dependencies with breaking changes
+      for example, a repodata patch should be submitted to conda forge to prevent users
+      from installing a broken environment.
+
+      Repodata patches are submitted to [conda-forge/conda-forge-repodata-patches-feedstock](https://github.com/conda-forge/conda-forge-repodata-patches-feedstock)
+    * mark a build as broken: If the dependencies were incorrect in the recipe, then the existing
+      build should be marked as broken and a PR (completely manual) should be submitted
+      to the arviz-feedstock to fix the recipe. Note that if this is being done for a release
+      different than the latest, changes should not be merged into `main` but on a dedicated
+      branch, the conda-forge package build is generated all the same but the history is kept
+      tidier and prevents issues when a new release is published.
+
+      Requests to mark packages as broken are submitted to [conda-forge/admin-requests](https://github.com/conda-forge/admin-requests/)