diff -rN -u old-smederee/CONTRIBUTING.md new-smederee/CONTRIBUTING.md
--- old-smederee/CONTRIBUTING.md	2025-01-31 02:48:18.709987254 +0000
+++ new-smederee/CONTRIBUTING.md	2025-01-31 02:48:18.709987254 +0000
@@ -42,9 +42,9 @@
 8. A patch fixing a ticket MUST include a trailing `Fixes:` line in the commit message that links to the ticket, for example: `Fixes: https://tickets.smeder.ee/~jan0sch/smederee/123`
 9. A patch fixing a regression of another patch MUST include a trailing `Fixes:` line referencing the other patch by its hash, for example: `Fixes: 0b8e86ad1f6a182433d2f59ebf2d40b9b8931f50`
 10. A patch not related to an issue SHOULD include either `Reported-by: alias/name <email>` or `Suggested-by: alias/name <email>` markers to give proper credit for people reporting bugs and suggesting features that are themselves not providing patches.
-  1. If the aforementioned people did not report/suggest in public form (mailing list, forum) then they MUST be asked for permission before adding the markers.
-  2. `Reported-by:` markers MUST ONLY be used for bugs.
-  3. `Suggested-by:` markers MUST NEVER be used for bugs.
+   1. If the aforementioned people did not report/suggest in public form (mailing list, forum) then they MUST be asked for permission before adding the markers.
+   2. `Reported-by:` markers MUST ONLY be used for bugs.
+   3. `Suggested-by:` markers MUST NOT be used for bugs.
 11. A patch MUST NOT update the [CHANGELOG](CHANGELOG.md) file because that might introduce dependencies between unrelated patches due to modification of related lines within the CHANGELOG.
 12. A "Correct Patch" is one that satisfies the above requirements.
 
@@ -63,8 +63,8 @@
 9. A Contributor SHALL NOT commit changes directly to the project.
 10. A Contributor MAY directly send a patch without logging a separate issue.
 11. To discuss a patch, people MAY comment on the mailing list using markers (trailers) as described below:
-  1. `Tested-by: alias/name <email>` to indicate that the patch has been successfully applied and tested by the person named (in some environment).
-  2. `Reviewed-by: alias/name <email>` to indicate that the patch has been reviewed and found acceptable.
+   1. `Tested-by: alias/name <email>` to indicate that the patch has been successfully applied and tested by the person named (in some environment).
+   2. `Reviewed-by: alias/name <email>` to indicate that the patch has been reviewed and found acceptable.
 12. To accept or reject a patch, a Maintainer SHALL reply on the mailing list and include the `Acked-by: alias/name <email>` marker upon acceptance of the patch into the main branch.
 13. Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
 14. Maintainers SHALL NOT make value judgements on correct patches.