diff --git a/README.md b/README.md
index 5ab1aa354ddccb805d978c33ded66b63ee6d6b84..4ad1afa562893bd5b88ae4b915f30a5f0d4cfdea 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ Read The Docs project. You can inspect the `latest` version
 [online](https://docs.oniroproject.org/en/latest/) or download it as
 [PDF](https://docs.oniroproject.org/_/downloads/en/latest/pdf/).
 
-## Building the docs
+## Building the Docs
 
 As per the current implementation for satisfying aggregation of multiple
 `sphinx` projects, the repository takes advantage of symlinks which assume a
diff --git a/building-project-documentation.rst b/building-project-documentation.rst
index ad1693650671368c4ff53c8d49cfbd85a3228bfd..3d6c2ecc33f464394bab9bf2063c23ccf1d1d34e 100644
--- a/building-project-documentation.rst
+++ b/building-project-documentation.rst
@@ -4,7 +4,7 @@
 
 .. include:: definitions.rst
 
-Building |main_project_name| documentation
+Building |main_project_name| Documentation
 ##########################################
 
 This topic outlines the standard way of generating the |main_project_name|
@@ -43,7 +43,7 @@ packages pre-installed in your system:
 
 * Make (to build the documentation using the provided Makefile)
 
-Building the documentation
+Building the Documentation
 **************************
 
 To generate a local copy of |main_project_name| documentation, perform the
diff --git a/ci/device-testing.rst b/ci/device-testing.rst
index 557a6f64671b8582771873ba7faaa1fd64e15d02..3976a13a1ff234c400cb7374232c4b568d99c372 100644
--- a/ci/device-testing.rst
+++ b/ci/device-testing.rst
@@ -17,7 +17,7 @@ testing development on real devices, like operating system boot-loader and
 kernel development, while sharing access to a project-specific software
 infrastructure used in the public cloud.
 
-How does the CI system work?
+How does the CI System Work?
 ----------------------------
 
 The system automatically performs a set of test jobs upon a new or
diff --git a/contributing/bug_policy.rst b/contributing/bug_policy.rst
index 5013cae7b1319dc0b7368856731576bba7fcccc4..cdf3ea2cf30688f22227d28f0f39eb6f812a1a54 100644
--- a/contributing/bug_policy.rst
+++ b/contributing/bug_policy.rst
@@ -4,7 +4,7 @@
 
 .. include:: ../definitions.rst
 
-Bug handling process
+Bug Handling Process
 ####################
 
 Overview
@@ -15,7 +15,7 @@ applying the best industry practices in terms of development quality. However,
 as in every software projects, bugs do happen. This process explains how we
 handle bugs.
 
-How to report a bug?
+How to Report a Bug?
 ********************
 
 If you think you have found a bug in our distribution, please file a bug report
@@ -34,7 +34,7 @@ issue. Use the provided template:
 Developers review the reported issues and perform triage (see below). When a fix
 is available, the ticket is updated with the details of the solution.
 
-Which modules do we support?
+Which Modules do We Support?
 ****************************
 
 We do support all layers included in our reference images and blueprints. It means
@@ -42,7 +42,7 @@ we accept bug reports in those layers. If the issue affects the upstream part of
 the layer, we are going to redirect the report to the upstream project and work
 with upstream on a solution.
 
-Bug triage
+Bug Triage
 **********
 
 The bug triage is a process where developers asses the bug and set its
@@ -79,13 +79,13 @@ The bug can originate in a package developed by the project, or from one we use
 from an upstream source. The process of handling a bug report will change
 between those two cases:
 
-When the issue is in the code developed by the project
+When the Issue is in the Code Developed by the Project
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In the case where the bug originates in the code directly maintained by the
 Project, the bug is handled directly in the bug tracker.
 
-When the issue originates from upstream code
+When the Issue Originates from Upstream Code
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 If the issue was identified in upstream code, we report an upstream issue in
@@ -99,10 +99,10 @@ Please note also that we periodically update maintained packages from upstream
 sources, regardless of the bugs filled in our system. Our goal is to update to
 the latest stable version of the package.
 
-Detailed workflow
+Detailed Workflow
 *****************
 
-Bug sources
+Bug Sources
 ^^^^^^^^^^^
 
 Bugs might be reported by different sources, including Project's own findings
@@ -112,7 +112,7 @@ Mattermost channels, discussion forums etc. Issues coming from different sources
 are centralized in the bug tracker, which also provides an unified
 identification of all issues.
 
-Acknowledgement and bug triage
+Acknowledgement and Bug Triage
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 After the bug is entered, a developer will perform triage. The process starts
@@ -133,7 +133,7 @@ questions to the reporter) in three working days for critical bugs and seven day
 for other bugs. In case of a critical bug, the person performing triage informs
 the maintainers of the affected subsystem.
 
-Prioritizing and fixing
+Prioritizing and Fixing
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Bugs with the severity attached enter the prioritization process. It includes a weekly
diff --git a/contributing/gitlab.rst b/contributing/gitlab.rst
index 6adb468a3bb1d209dab22be9cccb80c236746262..584cd4886388171c81c4f3a7563a628348ad32e6 100644
--- a/contributing/gitlab.rst
+++ b/contributing/gitlab.rst
@@ -4,7 +4,7 @@
 
 .. include:: ../definitions.rst
 
-Gitlab contributions
+Gitlab Contributions
 ####################
 
 .. contents:: 
diff --git a/contributing/reuse.rst b/contributing/reuse.rst
index 6546d581339e868b74be0390444cc56fbe90af88..ba567f72f0be23e74f2dfc968444f49b25f20092 100644
--- a/contributing/reuse.rst
+++ b/contributing/reuse.rst
@@ -4,13 +4,13 @@
 
 .. include:: ../definitions.rst
 
-REUSE compliance
+REUSE Compliance
 ################
 
 .. contents::
    :depth: 3
 
-SPDX information and REUSE standard
+SPDX Information and REUSE Standard
 ***********************************
 
 All projects and files for an hosted project **MUST** be `REUSE <https://reuse.software/>`_
@@ -29,7 +29,7 @@ Some files will make an exception to the above rules as described below:
 * Files for which copyright is not claimed and for which this information was not trivial to fetch (for example backporting patches, importing build recipes etc. when upstream doesn't provide the SPDX information in the first place)
 * license files (for example ``common-licenses`` in bitbake layers)
 
-SPDX header example
+SPDX Header Example
 -------------------
 
 Make sure all of your submitted new files have a licensing statement in the headers. Please make sure that the license for your file is consistent with the licensing choice at project level and that you select the correct SPDX identifier, as in the following example for Apache 2.0 license:
@@ -42,7 +42,7 @@ Make sure all of your submitted new files have a licensing statement in the head
      * SPDX-License-Identifier: Apache-2.0
      */
 
-Substantial contributions
+Substantial Contributions
 -------------------------
 
 Therefore, if your contribution is only a patch directly applied to an existing file, then you are not required to do anything. If your contribution is an entire new project, or a substantial, copyrighted contribution, you **MUST** make sure that you do that following the `IP Policy <https://booting.oniroproject.org/distro/governance/ip-policy>`_ and that you comply with REUSE standard to include the licensing information where they are required.
diff --git a/contributing/upstream_contribution_process.rst b/contributing/upstream_contribution_process.rst
index 7d9c866d15fa069b369cc83571c9398fc6ba04a6..881e5e37c9e3ff524cbe91fc258a2fdc60e765bb 100644
--- a/contributing/upstream_contribution_process.rst
+++ b/contributing/upstream_contribution_process.rst
@@ -6,7 +6,7 @@
 
 .. _sec_upstream_contrib:
 
-Contributing to projects not maintained by |main_project_name| team
+Contributing to Projects not Maintained by |main_project_name| Team
 ###################################################################
 
 .. _sec_upstream_contrib_overview:
@@ -18,7 +18,7 @@ In order to comply with :ref:`Upstream first<sec-upstream>` rule and Open Source
 
 .. _sec_upstream_contrib_signoff:
 
-Signing off contribution
+Signing-off Contribution
 ************************
 
 All contributions must be signed off by the |main_project_name| developer using their email account associated with the copyright owner of the work (in most cases it will be the corporate email address). This does not apply if the upstream project policy says otherwise or signing off of the contribution is not possible due to upstream project's limitation. It is recommended to use corporate email address as a sender address in case of email communication.
@@ -38,14 +38,14 @@ It is |main_project_name| developer's responsibility to check license compatibil
 
 .. _sec_upstream_contrib_cla:
 
-Contribution agreement
+Contribution Agreement
 **********************
 
 In case the upstream project requires signing of contribution agreement of any kind, the  |main_project_name| developer must review it carefully before submitting the contribution. In case of any doubt they must contact their manager or legal team for further guidance.
 
 .. _sec_upstream_contrib_security:
 
-Security-related contribution and sensitive data
+Security-related Contribution and Sensitive Data
 ************************************************
 
 It is the |main_project_name| developer's responsibility to verify the data they share with upstream counterpart to prevent leak of sensitive information.
diff --git a/overview/oniroproject-vision.rst b/overview/oniroproject-vision.rst
index c8252f6080333a7edf4ad53ec81fe1f235fbbcdf..b96ca60994249a1059737bdf0ff39b524c2d4816 100644
--- a/overview/oniroproject-vision.rst
+++ b/overview/oniroproject-vision.rst
@@ -4,7 +4,7 @@
 
 .. include:: ../definitions.rst
 
-|main_project_name| vision and aims
+|main_project_name| Vision and Aims
 ===================================
 
 System Positioning
diff --git a/releases/aladeen/0.1.0/release_notes.rst b/releases/aladeen/0.1.0/release_notes.rst
index d75ff5d27cf5df765fad5b0f607be56c0f3d2a40..54497c797008ba749fbc69a7547886542eacb345 100644
--- a/releases/aladeen/0.1.0/release_notes.rst
+++ b/releases/aladeen/0.1.0/release_notes.rst
@@ -27,7 +27,7 @@ Scope
 
 **Release timeframe**: 2020/11/15 .. 2021/04/12
 
-The objectives of the release
+The Objectives of the Release
 -----------------------------
 
 The purpose of this release is to provide the European |main_project_name|
@@ -38,7 +38,7 @@ which we can share the entire 2021 roadmap of the project.
 More details on the |main_project_name| goals can be found in the
 :doc:`/overview/oniroproject-vision` document.
 
-The list of software features included
+The List of Software Features Included
 --------------------------------------
 
 +------------------------------------------------------------------+--------------------------+
@@ -77,7 +77,7 @@ The list of software features included
 | Automated sphinx-based documentation pipeline                    | Documentation            |
 +------------------------------------------------------------------+--------------------------+
 
-Supported hardware platforms
+Supported Hardware Platforms
 ----------------------------
 
 +--------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+
@@ -93,7 +93,7 @@ Supported hardware platforms
 +--------------------------------------------------------------------------------------------------------------------------------------+---------------------+----------------------------------+
 
 
-Test report
+Test Report
 -----------
 
 Not available for this release.
@@ -114,14 +114,14 @@ repo tool. Entire workspace is archived into sources tarball and can be prepared
    $ tar -xvf asos-0.1.0.tar.xz
    $ cd asos-0.1.0
 
-Known issues
+Known Issues
 ------------
 
 The Avenger96 target (stm32mp1-av96) does not ship with firmware files for Bluetooth,
 Wifi and the image processor by default. We are working on a solution to re-distribute
 them during the normal image builds for this board.
 
-Source code available
+Source Code Available
 ---------------------
 
 Source code and GPG signatures:
@@ -153,7 +153,7 @@ The release is signed with the key:
    =lKOe
    -----END PGP PUBLIC KEY BLOCK-----
 
-Devops infrastructure
+Devops Infrastructure
 *********************
 
 To learn more about our approach to CI (Continuous Integration) strategy used for this release, please see:
diff --git a/security/cve_policy.rst b/security/cve_policy.rst
index 3f81fd59d409ad4f7a376a7a75387ab644e01cf9..136c6635f9af096c1b09697db34fda09e31325b7 100644
--- a/security/cve_policy.rst
+++ b/security/cve_policy.rst
@@ -19,7 +19,7 @@ protect deployed products, sometimes we need to delay releasing information
 related to security issues, following the industry best practices. However, all
 information about vulnerabilities is becoming publicly available at the end.
 
-How to report a vulnerability?
+How to Report a Vulnerability?
 ******************************
 
 If you think you have found a security issue in our distribution, please contact
@@ -83,7 +83,7 @@ information becomes available.
 The SRT meets weekly on a status meeting and participates in the general
 Bug triage/prioritization meeting.
 
-Classification of issues
+Classification of Issues
 ************************
 
 Security issues are classified as high, medium, and low severity. As a rule of
@@ -95,7 +95,7 @@ thumb, we map the Base CVSS score from v3.1 in the following way:
 
 - 7.0 and above - high severity
 
-When the issue is in the code maintained by the project
+When the Issue is in the Code Maintained by the Project
 *******************************************************
 
 When the source code where the issue comes from is maintained by the Project,
@@ -123,7 +123,7 @@ severity, the fix waits until the next regular bugfix release. In the case of a
 critical issue, the security team together with the release team may decide in
 distributing patches to the affected users.
 
-Handling upstream security issues
+Handling Upstream Security Issues
 *********************************
 
 If the issue was identified in upstream code, we do report an upstream security
@@ -135,7 +135,7 @@ If the upstream project does not respond, or does respond very slowly, we may
 decide to develop a patch on our own. In this case, the vulnerability is using
 the process for issues where we are upstream.
 
-Detailed workflow
+Detailed Workflow
 *****************
 
 Our process contains four phases: monitoring, assessment, remedy, and