diff --git a/MAINTAINERS_GUIDE.md b/MAINTAINERS_GUIDE.md
index 8e96917..188524b 100644
--- a/MAINTAINERS_GUIDE.md
+++ b/MAINTAINERS_GUIDE.md
@@ -25,7 +25,7 @@ It is every maintainer's responsibility to:
 * Expose a clear roadmap for improving their component.
 * Deliver prompt feedback and decisions on pull requests.
 * Be available to anyone with questions, bug reports, criticism etc. on their component.
-  This includes IRC and GitHub issues and pull requests.
+    This includes IRC and GitHub issues and pull requests.
 * Make sure their component respects the philosophy, design and roadmap of the project.
 
 ## How are decisions made?
@@ -44,16 +44,16 @@ a change to the philosophy manifesto. And so on.
 All decisions affecting this project, big and small, follow the same procedure:
 
 1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list).
-   Anyone can do this.
+    Anyone can do this.
 2. Open a pull request.
-   Anyone can do this.
+    Anyone can do this.
 3. Discuss the pull request.
-   Anyone can do this.
+    Anyone can do this.
 4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request.
-   The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
-   Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
+    The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).
+    Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).
 5. Merge or close the pull request.
-   The relevant maintainers do this.
+    The relevant maintainers do this.
 
 ### I'm a maintainer, should I make pull requests too?
 
diff --git a/RELEASES.md b/RELEASES.md
index 028ec26..3fe3574 100644
--- a/RELEASES.md
+++ b/RELEASES.md
@@ -43,9 +43,9 @@ Specifications have a variety of different timelines in their lifecycle.
 
 * Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.
 * Major specification releases MUST release at least three release candidates spaced a minimum of one week apart.
-  This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
-  Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
-  For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
+    This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
+    Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
+    For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
 * Minor and patch releases SHOULD be made on an as-needed basis.
 
 [charter]: https://www.opencontainers.org/about/governance