Headings changed to Title Case

All headings changed to title case to maintain consistency

Closes: https://booting.oniroproject.org/distro/docs/-/issues/94



Signed-off-by: Gururaj Shetty <gururaj.shetty@huawei.com>

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

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

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

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

contributing/gitlab.rst

@@ -4,7 +4,7 @@
 
 .. include:: ../definitions.rst
 
-Gitlab contributions
+Gitlab Contributions
 ####################
 
 .. contents:: 

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.

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.

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

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:

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