[TASK] Document commit message conventions for contributors

Documentation/Advanced/ReviewPolicy.rst

@@ -29,7 +29,7 @@ the following:
 *   Please ensure that your Pull Request is **made against the appropriate
     version of the documentation**, usually against the `main` branch. If the
     changes you propose apply to specific versions of the documentation,
-    you can add a line like `Releases: main, 12.4, 11.5` to note any
+    you can add a line like `Releases: main, 14.3, 13.4` to note any
     Git branch that your change would apply to. If you are unsure,
     our maintainers will take care of it - this is just a step to make
     their work easier.

Documentation/Howto/EditLocal.rst

@@ -98,7 +98,29 @@ the ability to experiment and preview your changes locally before submitting the
 
         git commit -a
 
-    Write a short, meaningful commit message describing what changes you have made.
+    Prefix the summary line with the type of change -- `[TASK]`,
+    `[BUGFIX]` or `[FEATURE]` -- followed by a short, imperative summary,
+    for example `[TASK] Document anchor persistence rule`.
+
+    Explain *why* the change is needed in the body. The diff already shows
+    what changed; the body should cover what the diff cannot.
+
+    End with a `Signed-off-by: Your Name` trailer. If you used AI assistance
+    for more than a basic spelling or grammar check, add an
+    `Assisted-by: <tool/model name> <contact>` trailer as well.
+
+    If the change is related to a changelog entry, mention that changelog
+    entry. If it is related to a Gerrit change that had no changelog entry,
+    mention that Gerrit change instead. If it is related to an issue,
+    mention the issue number. See :ref:`howto-update-docs-commit-messages`
+    for an example.
+
+    If the manual has branches per version, add a line like
+    `Releases: main, 14.3` to note which versions your change applies to
+    (see :ref:`review-policy`). Backporting to those branches then happens
+    automatically (see :ref:`backport-changes`) -- manual backporting is
+    only needed if the automatic backport hits a conflict or the content
+    needs to be adjusted per version.
 
 9.  Push changes
 

Documentation/Maintainers/BackportChanges.rst

@@ -13,7 +13,7 @@ commit message (as done in the Core):
 
 ..  code-block:: text
 
-    Releases: main, 12.4
+    Releases: main, 14.3
 
 However, this is not enforced and not always done. In any case, it is
 up to the user merging a PR to decide how far the changes are to be
@@ -33,10 +33,12 @@ Leave a hint about which versions you have tested, for example:
 
 ..  code-block:: text
 
-    Verified this on 12.4 and 11.5, I suspect it will also still be the case on
+    Verified this on 14.3 and 13.4, I suspect it will also still be the case on
     main. Could someone verify this please?
 
-    Releases: main, 12.4, 11.5
+    Releases: main, 14.3, 13.4
+    Assisted-by: Claude Sonnet 5 <noreply@anthropic.com>
+    Signed-off-by: Jane Doe
 
 The backporting itself will be done by the maintainers of the Documentation Team.
 Sometimes automatic backporting is not possible due to changes in the documentation

Documentation/Maintainers/Changelog.rst

@@ -37,6 +37,8 @@ their commit message to the issue, for example
 
     Resolves: https://github.com/TYPO3-Documentation/Changelog-To-Doc/issues/790
     Releases: main
+    Assisted-by: Claude Sonnet 5 <noreply@anthropic.com>
+    Signed-off-by: Jane Doe
 
 ..  index::
     Documentation; Deprecations