docs: follow rst standard for subtitles

Author: mariajgrimaldi

docs/decisions/0017-generalized-containers.rst

@@ -7,7 +7,7 @@ Context
 This ADR proposes a model for containers that can hold different types of content and can be used to model other content types with similar behavior, such as units, subsections, sections, or courses. The model defines containers' core structure and purpose, the types of containers, content constraints, container children, version control, publishing, and pruning.
 
 Key Concepts
-============
+~~~~~~~~~~~~~
 
 The following definitions provide context for the terms used in this ADR:
 
@@ -24,7 +24,7 @@ Decisions
 ---------
 
 1. Core Structure and Purpose of Containers
-===========================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This section defines the purpose and structure of containers, explaining how they are designed to hold various types of content through a parent-child setup.
 
@@ -37,7 +37,7 @@ This section defines the purpose and structure of containers, explaining how the
   - Units (units Django application, builds on containers and selectors).
 
 2. Container Types and Content Constraints
-==========================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This section defines container types, content constraints, hierarchy, and extensibility. It introduces the main types of containers and outlines how content limitations and configurations are handled at the application level to support flexible content structures.
 
@@ -49,7 +49,7 @@ This section defines container types, content constraints, hierarchy, and extens
 - Containers will follow extensibility principles in `Content Extensibility Through Model Relations <0003-content-extensibility.rst>`_ for creating new container types or subtypes.
 
 3. Container Children and Relationships
-=======================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This section defines container children, their order, and relationships, covering flexible connections and support for draft and published states of their children.
 
@@ -63,7 +63,7 @@ This section defines container children, their order, and relationships, coverin
 - A single child (publishable entity) can be shared by multiple containers, allowing for reuse of content across different containers. For instance, a component can be shared by multiple units.
 
 4. Container Versioning, Deletions and Structural Changes
-==============================================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This section defines the versioning rules for containers, explaining when a new version is created based on structural or metadata changes. It also clarifies how changes in child elements affect (or do not affect) container versions.
 
@@ -74,7 +74,7 @@ This section defines the versioning rules for containers, explaining when a new
   - Changes to container metadata, such as updating its title or description, will also create a new version.
 
 5. Publishing
-=============
+~~~~~~~~~~~~~
 
 This section explains the publishing process for containers, detailing how containers and their children become accessible, either together or independently, based on their publication state. The publishing process happens on container versions, but throughout this section we'd call them containers for simplicity.
 
@@ -84,7 +84,7 @@ This section explains the publishing process for containers, detailing how conta
 - Containers are not affected by the publishing process of its children. This means that publishing a component won't trigger new publishing processes for a container.
 
 6. Pruning
-==========
+~~~~~~~~~~
 
 This section defines the rules for pruning container versions, explaining when a container version can be pruned and the effects of pruning on the container and its children.
 

docs/decisions/0018-units-as-containers.rst

@@ -12,23 +12,23 @@ Decisions
 All decisions from `0017-generalized-containers.rst <0017-generalized-containers.rst>`_ are still valid but are written here alongside unit-specific decisions for better illustration.
 
 1. Units as Containers
-=======================
+~~~~~~~~~~~~~~~~~~~~~~~
 
 - A unit is a concrete type of container that holds components.
 - A unit is a container, making it also a publishable entity.
 - Units build on the generalized container capability to hold components and selectors for dynamically selecting 0-N PublishableEntities.
 - Units have their own Django application that builds on containers and selectors.
 
 2. Unit Types and Content Constraints
-======================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 - Units can only hold components as their children but will not enforce this restriction at the model level.
 - Units are the first level of nested content types Unit > Components.
 - Content restrictions for units are implemented at the application layer, allowing units to limit their children to only components. None of this is enforced at the model level.
 - Unit subtypes can be created by following the extensibility principles in `Content Extensibility Through Model Relations <0003-content-extensibility.rst>`_.
 
 3. Unit Children and Relationships
-==================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 - The children of a unit can only be components.
 - Components in a unit are referenced as an ordered list. For example, a unit can have a list of components that are ordered by the author.
@@ -37,20 +37,20 @@ All decisions from `0017-generalized-containers.rst <0017-generalized-containers
 - A single component can be reference by multiple units.
 
 4. Next Unit Versions
-======================
+~~~~~~~~~~~~~~~~~~~~~
 
 Only changes to the unit itself (e.g., title, ordering of components, adding or removing a component, or changes to the unit's metadata) will create a new version of the unit. Changes to the components of a unit will not create a new version of the unit.
 
 5. Publishing
-==============
+~~~~~~~~~~~~~
 
 - Units can be published, allowing their content to be accessible from where the unit is being used. Only after a unit is published it can be reused as content for other containers.
 - When a draft unit is published, all its draft components are also published.
 - Components within a unit can be published independently of the unit itself. This could happen for components that are shared by multiple units.
 - Units are not affected by the publishing process of its components.
 
 6. Pruning
-==========
+~~~~~~~~~~
 
 - A unit version can be pruned if it's not being used by any subsections, it's not a published version, and it's not the latest version of the unit.
 - In a top-down approach, start with the unit and work your way down to its component versions.

docs/decisions/0019-selectors.rst

@@ -1,5 +1,5 @@
 19. Selectors for Dynamically Selecting Content
-===========================================
+===============================================
 
 Context
 -------
@@ -12,7 +12,7 @@ This ADR proposes a way to represent dynamic members of a container, where dynam
 And any other custom use case to dynamically select members for a container. This proposal introduces the concepts of selectors and variants to implement this type of dynamic selection.
 
 1. Core Structure
-=================
+~~~~~~~~~~~~~~~~~
 
 This section explains the concepts and behaviors used to build dynamic selection, selectors and variants.
 
@@ -23,7 +23,7 @@ This section explains the concepts and behaviors used to build dynamic selection
 - Variants are build on the parent-child relationship used for containers and their members, storing the dynamically selected content as an ordered list as containers do.
 
 2. Selector Types and Selecting Content
-=======================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This section describes how different types of selectors work and how they handle the selection of dynamic content.
 
@@ -33,7 +33,7 @@ This section describes how different types of selectors work and how they handle
 - A compositor is responsible for populating the variants but will not be implemented as part of the selector application which belongs to the authoring app.
 
 3. Versioning
-=============
+~~~~~~~~~~~~~
 
 A new version of a selector is created whenever the pool of concent changes by adding, removing or reordering existing members.