typo fix / small bugs (#2503)

Author: PandaeDo

.vscode/settings.json

@@ -88,8 +88,12 @@
     },
     "cSpell.words": [
         "__getitem__",
+        "baselibs",
         "bazel",
         "buildifier",
+        "Codeowner",
+        "codeowners",
+        "docname",
         "getstrt",
         "metatags",
         "reqs"

docs/platform_management_plan/change_management.rst

@@ -274,7 +274,7 @@ If the information is sufficient and it is decided to implement the change reque
 ISSUE status is kept ``Open`` and the Projects status is set to ``In Progress``.
 
 The decision, if the change request is accepted or rejected must be documented. Safety/Security
-experts must confirm or disconfirm, if safety/security relevance is set correctly.
+experts must confirm or deny, if safety/security relevance is set correctly.
 
 :need:`gd_chklst__change_cr_review` can help to verify whether the information is complete.
 

docs/platform_management_plan/documentation_management.rst

@@ -46,12 +46,12 @@ Others are modelled as general documents (e.g. the plans which are part of the p
 
 This plan deals with these documents, which have the following manually set attributes:
 
-* Title: the name of the document (mandatory)
+* Title: The name of the document (mandatory)
 * Unique Id: Id following the naming pattern of the document Title (mandatory)
-* Safety: which ASIL the document supports (mandatory)
+* Safety: Which ASIL the document supports (mandatory)
 * Author: Who is the main committer to the document (mandatory)
-* Status: describing where in the lifecycle of the document it currently is (mandatory)
-* Tags: can be used to group documents for subsequent filtering (optional)
+* Status: Describing where in the lifecycle of the document it currently is (mandatory)
+* Tags: Can be used to group documents for subsequent filtering (optional)
 
 Also the "Documentation Management" is a document, so an example for a correct document definition
 can be seen in the header section above, see :need:`doc__documentation_mgt_plan`.

docs/platform_management_plan/problem_resolution.rst

@@ -137,7 +137,7 @@ To provide solutions, use the Solution part of the ISSUE.
 
 :need:`[[title]] <gd_req__problem_attr_anaylsis_results>` is provided in the analysis
 results part of the ISSUE. State here, if the problem is accepted or rejected. Safety/Security
-experts must confirm or disconfirm, if safety/security is affected is set correctly
+experts must confirm or deny, if safety/security is affected is set correctly
 
 :need:`[[title]] <gd_req__problem_attr_stakeholder>` are provided in the Assignees part of
 the ISSUE. In addition you can use pre-defined labels for Communities or Feature Teams
@@ -230,7 +230,7 @@ If the information is sufficient and it is decided to initiate the problem resol
 ISSUE status is kept ``Open`` and the Projects status is set to ``In Progress``.
 
 The decision, if the problem is accepted or rejected must be documented. Safety/Security
-experts must confirm or disconfirm, if safety/security is affected is set correctly.
+experts must confirm or deny, if safety/security is affected is set correctly.
 
 :need:`gd_chklst__problem_cr_review` can help to verify whether the information is complete.
 

docs/platform_management_plan/project_management.rst

@@ -98,7 +98,7 @@ Technical committees
 
   Every *Feature Team* should also have a *Feature Team Lead*. The person with this role is responsible for
   organizing the meetings, writing meeting protocols and representing the current status of the *Feature Team*
-  work in various management reporting or plannig calls. *Feature Team Lead* is nominated by *Technical Leads* by election.
+  work in various management reporting or planning calls. *Feature Team Lead* is nominated by *Technical Leads* by election.
   Normally, this is the owner of the original *Feature Request*.
 
 
@@ -107,8 +107,8 @@ Creation of a new Feature Team
 Decision to create a new *Feature Team* is normally done in *Technical Lead Circle* in case a particular,
 already *accepted* *Feature Request* can not be assigned to any of already existing *Feature Teams*.
 
-As a first step, the decision to create a new Feature Team is protocolled in the `Tech Lead Circle meeeting minutes <https://github.com/orgs/eclipse-score/discussions/categories/technical-lead-circle>`_.
-Afterwards a GitHub Issue is created in the `Technical Lead Cirle LOP project <https://github.com/orgs/eclipse-score/projects/3>`_
+As a first step, the decision to create a new Feature Team is recorded in the `Tech Lead Circle meeting minutes <https://github.com/orgs/eclipse-score/discussions/categories/technical-lead-circle>`_.
+Afterwards a GitHub Issue is created in the `Technical Lead Circle LOP project <https://github.com/orgs/eclipse-score/projects/3>`_
 using the special *Feature Team Creation* GitHub Issue template and is assigned to one of the Technical Leads.
 
 **ToDo**: create such a template.
@@ -182,10 +182,10 @@ technical competence of the software developers, e.g. in case during the :ref:`F
 it was decided to take over already existing source code, then persons who were actively participating in the
 development of that code are always good candidates to be part of *Codeowner GitHub team*.
 The decision who should be initially part of the *Codeowner GitHub team* and the reasoning for this
-should be protocolled in the GitHub Issue, that is used for creation of the *Feature Team*.
+should be recorded in the GitHub Issue, that is used for creation of the *Feature Team*.
 
-In case further software developers should be added to the *Codeowener GitHub team* in the future,
-that decision and its reasoning should be protocolled in one of the *Feature Team* GitHub discussions.
+In case further software developers should be added to the *Codeowner GitHub team* in the future,
+that decision and its reasoning should be recorded in one of the *Feature Team* GitHub discussions.
 
 Members of the *Codeowner GitHub team* should also be authorized to merge pull requests (PRs) into the corresponding repository.
 Therefore, once the *Codeowner GitHub team* has been created, the Technical Lead assigned to the ticket for the *Feature

docs/platform_management_plan/quality_management.rst

@@ -182,11 +182,11 @@ The metric for the work products is ensured by the process that contains the wor
 
 3.5 Quality Management Scope
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-There is no deviation from the scope defined in the :need:`doc__project_mgt_plan`. The platform and its
+There is no deviation from the scope defined in the :need:`doc__project_mgt_plan`. The platform and it's
 components are developed, and integrated for an assumed technical system, for functional safety purposes as
 Safety Element out of Context (SEooC).
 
-The development of the platform and its components follows the defined processes. Responsibilities for management,
+The development of the platform and it's components follows the defined processes. Responsibilities for management,
 development, implementation, integration, and verification are also defined in the processes.
 
 The SW platform consists of features, which are based on a set of requirements and are developed in parallel.

docs/platform_management_plan/release_management.rst

@@ -20,7 +20,7 @@
    :tags: platform_management
    :realizes: wp__platform_sw_release_plan
 
-Release management Plan
+Release Management Plan
 -----------------------
 
 This document implements parts of the :need:`wp__platform_mgmt`.
@@ -73,7 +73,7 @@ Release Planning and Execution
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Generally release planning and execution is described in :need:`wf__rel_mod_rel_note` process.
-It is part of project planning and therefore also documented with the same means. Generally a Release
+It is part of project planning and therefore also documented with the same means. Generally a release
 is planned as an issue linked to a milestone in the `GitHub Milestone Planning <https://github.com/orgs/eclipse-score/projects/13>`_.
 And this issue is closed by merging a pull request which creates/updates a release note.
 

docs/platform_management_plan/role_assignment/platform_safety_manager.rst

@@ -55,7 +55,7 @@ Education and Skills:
 - Safety related SW development and project management (in aerospace) > 10 years - letters of recommendation from employers
 - Trainer for DO-178B SW safety standard - election certificate
 - Process development CMMI - letters of recommendation from employers
-- Safety trainings by Exida (Iso 26262) - part of Safety Case Safe Posix SW platform
+- Safety trainings by Exida (ISO 26262) - part of Safety Case Safe Posix SW platform
 
 S-CORE Committs:
 

docs/platform_management_plan/safety_management.rst

@@ -60,7 +60,7 @@ Functional Safety Management Scope
 There is no deviation from the scope presented in the `S-CORE project page <https://eclipse-score.github.io/>`_ .
 The platform and its components are developed, and integrated for an assumed technical system as Safety Element out of Context (SEooC).
 The development of the platform and its components follows the defined processes.
-Responsibilities for development, implementation, integration and verification are also defined int the processes.
+Responsibilities for development, implementation, integration and verification are also defined in the processes.
 
 Regarding the platform specifics:
 
@@ -202,7 +202,7 @@ For the :need:`rl__project_lead`, the :need:`rl__safety_manager` and the :need:`
 in these project role definitions. They are also elected in a meritocratic way and this election is documented including the evidences checked to prove the experience.
 
 Committers in the S-CORE project can work on the development of safety related or non-safety related SW modules.
-If they work on safety related modules they have to prove (additionaly to their committer election, which already shows they are skilled developers):
+If they work on safety related modules they have to prove (additionally to their committer election, which already shows they are skilled developers):
 
 * two years practice of safety related SW development (or management) relevant for the section content (includes trainings in safety standards like ISO 26262)
 * training on the S-CORE processes

docs/platform_management_plan/software_verification.rst

@@ -330,7 +330,7 @@ to be reached with every contribution.
 Further quality goals are defined in section :doc:`quality_management`.
 
 The confirmation or any deviation of the coverage percentage value is documented in this section.
-This shall also be part of the module documenation with a reasoning when percentage numbers deviate for an official release.
+This shall also be part of the module documentation with a reasoning when percentage numbers deviate for an official release.
 
 Coverage of detailed design
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^