fixup! fixup! fixed

docs/decisions/0002-mark-fuzzy-entries.rst

@@ -28,17 +28,31 @@ combined into one single workflow with multiple jobs:
 
 #. Run ``python-tests.yml`` to validate the python code
 #. Then, run ``validate-translation-files.yml`` which performs the following:
+
    #. Validate the po-files using ``msgfmt``
    #. Mark the invalid entries as fuzzy (writes to the pofile)
    #. Validate the files again to ensure the files are became valid
    #. Commit the fixes if any
+
 #. Mark invalid entires as fuzzy therefore excluded from .mo files as well as msgfmt
 #. Validate the files again to ensure the files are still valid
 #. Commit the fixes
 #. Run the lint commits
 #. Push to the branch
 #. Trigger auto merge
 
+**Pros**
+
+* There's no need for manual intervention, therefor it's fast and won't
+  create a backlog of pull requests.
+
+
+**Cons**
+
+* The workflow script runs and edits the pull request, which can be
+  confusing for the reviewers.
+* The workflow lacks a notification mechanism to notify the reviewers
+  that their translations are invalid.
 
 Rejected Alternatives
 *********************
@@ -52,12 +66,16 @@ Rejected Alternatives
 
 - **Post errors on Slack:** Post the errors on Slack and ask the translators
   to fix them. Same as the previous option, not all translators are on Slack.
+  Additionally, this option would have a slow feedback loop causing the pull
+  requests backlog to build-up.
 
 - **Mark faulty entries as unreviewed:** Use the Transifex API to mark the
   the invalid entires as unreviewed, then pull only reviewed entries into this
   repository.
   This option would require an extensive use the of the Transifex API,
-  and pull again which can be complex to implement.
+  and pull again which can be complex to implement. Additionally, this option
+  would have a slow feedback loop causing the pull requests backlog to
+  build-up.
 
 
 .. _OEP-58: https://open-edx-proposals.readthedocs.io/en/latest/architectural-decisions/oep-0058-arch-translations-management.html