diff -rN -u old-smederee/CONTRIBUTING.md new-smederee/CONTRIBUTING.md
--- old-smederee/CONTRIBUTING.md	2025-01-31 07:47:31.601383036 +0000
+++ new-smederee/CONTRIBUTING.md	2025-01-31 07:47:31.601383036 +0000
@@ -57,20 +57,21 @@
 9. A Contributor SHALL NOT commit changes directly to the project.
 10. **TODO**: If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue. ???
 11. **TODO**: To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere. ???
-12. To accept or reject a patch, a Maintainer SHALL use the Platform interface.
+12. TODO: To accept or reject a patch, a Maintainer SHALL use the Platform interface. ???
 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 judgments on correct patches.
+14. Maintainers SHALL NOT make value judgements on correct patches.
 15. Maintainers SHALL merge correct patches from other Contributors rapidly.
 16. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
 17. The user who created an issue SHOULD close the issue after checking the patch is successful.
-18. Any Contributor who has value judgments on a patch SHOULD express these via their own patches.
+18. Any Contributor who has value judgements on a patch SHOULD express these via their own patches.
 19. Maintainers SHOULD close user issues that are left open without action for an uncomfortable period of time.
 
 ### 3.5 Branches and Releases
 
+In darcs, each repository is a branch. Therefore what you would consider a fork in other systems like git, is considered a branch in darcs.
+
 1. The project SHALL have one main branch that always holds the latest in-progress version and SHOULD always build.
-2. The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
-3. To make a stable release a Maintainer SHALL prepare the CHANGELOG file and tag the repository. Stable releases SHALL always be released from the main branch.
+2. To make a stable release a Maintainer SHALL prepare the CHANGELOG file and tag the repository. Stable releases SHALL always be released from the main branch.
 
 #### 3.5.1 Release guide