fix docs

README.rst

@@ -129,8 +129,8 @@ Reporting Security Issues
 
 Please do not report security issues in public. Please email security@edx.org.
 
-Getting Help
-------------
+Help
+----
 
 If you're having trouble, we have discussion forums at https://discuss.openedx.org where you can connect with others in the community.
 

docs/decisions/0002-content-flexibility.rst

@@ -25,7 +25,7 @@ Unit
   A Unit is an ordered list of one or more Components that is typically displayed together. A common use case might be to display some introductory Text, a Video, and some followup Problem (all separate Components). An individual Component in a Unit may or may not make sense when taken outside of that Unit–e.g. a Video may be reusable elsewhere, but the Problem referencing the video might not be.
 
 Sequence
-  A Sequence is a collection of Units that are presented one after the other, either to assess student understanding or to achieve some learning objective. 
+  A Sequence is a collection of Units that are presented one after the other, either to assess student understanding or to achieve some learning objective.
 
   A Sequence is analogous to a Subsection in a traditional Open edX course.
 

docs/decisions/0004-content-tagging.rst

@@ -13,9 +13,9 @@ Decision
 
 Implement the new tagging service as a pluggable django app, and installed alongside learning-core as a dependency in the edx-platform.
 
-Tagging data models will follow the guidelines for this repository, and focus on extensibility and flexibility. 
+Tagging data models will follow the guidelines for this repository, and focus on extensibility and flexibility.
 
-Since some use cases for content tagging are not considered "kernel" (like providing data for a marketing site), a generic mechanism to differentiate those uses cases will be built, and proper Python and REST APIs will be provided, to different taxonomies/tags for the same content. 
+Since some use cases for content tagging are not considered "kernel" (like providing data for a marketing site), a generic mechanism to differentiate those uses cases will be built, and proper Python and REST APIs will be provided, to different taxonomies/tags for the same content.
 
 
 Rejected Alternatives

docs/decisions/0005-identifier-conventions.rst

@@ -22,7 +22,7 @@ UUID
 
 Key
   The ``key`` field is chosen by apps or users, and is the most likely piece to be human-readable (though it doesn't have to be). These values are only locally unique within a given scope, such as a particular LearningPackage or ComponentVersion.
-  
+
   The correlates most closely to OpaqueKeys, though they are not precisely the same. In particular, we don't want to directly store BlockUsageKeys that have the LearningContextKey baked into them, because that makes it much harder to change the LearningContextKey later, e.g. if we ever want to change a CourseKey for a course. Different models can choose whether the ``key`` value is mutable or not, but outside users should assume that it can change, even if it rarely does in practice.
 
 Implementation Notes

requirements/constraints.txt

@@ -10,3 +10,7 @@
 
 # Common constraints for edx repos
 # -c https://raw.githubusercontent.com/edx/edx-lint/master/edx_lint/files/common_constraints.txt
+
+# tox>4.0.0 isn't yet compatible with many tox plugins, causing CI failures in almost all repos.
+# Details can be found in this discussion: https://github.com/tox-dev/tox/discussions/1810
+tox<4.0.0