eclipse-score · masc2023 · Feb 19, 2026 · Feb 19, 2026
@@ -5,7 +5,7 @@ build --tool_java_runtime_version=remotejdk_17
 
 test --test_output=errors
 
-# stop legacy behavior of creating __init__.py files
+# stop legacy behaviour of creating __init__.py files
 build --incompatible_default_to_explicit_init_py
 
 common --registry=https://raw.githubusercontent.com/eclipse-score/bazel_registry/main/

@@ -42,9 +42,9 @@ To activate this feature, use the following feature flag:
 
 ``experimental_[your_feature_name]``
 
-    .. note::
-     The feature flag must reflect the feature name in snake_case. Further, it is prepended with ``experimental_``, as
-     long as the feature is not yet stable.
+.. note::
+   The feature flag must reflect the feature name in snake_case. Further, it is prepended with ``experimental_``, as
+   long as the feature is not yet stable.
 
 Abstract
 ========
@@ -57,23 +57,21 @@ Motivation
 
 [Clearly explain why the existing platform/project solution is inadequate to address the topic that the CR solves.]
 
-    .. note::
-     The motivation is critical for CRs that want to change the existing features or infrastructure.
-     It should clearly explain why the existing solution is inadequate to address the topic that the CR solves.
-     Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc.
-     CRs submissions without sufficient motivation may be rejected.
-
-
+.. note::
+   The motivation is critical for CRs that want to change the existing features or infrastructure.
+   It should clearly explain why the existing solution is inadequate to address the topic that the CR solves.
+   Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc.
+   CRs submissions without sufficient motivation may be rejected.
 
 Rationale
 =========
 
 [Describe why particular design decisions were made.]
 
 
-   .. note::
-      The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
-      For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
+.. note::
+   The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
+   For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
 
 
 Specification
@@ -82,11 +80,9 @@ Specification
 [Describe the requirements, architecture of any new feature.] or
 [Describe the change to requirements, architecture, implementation, process, documentation, infrastructure of any change request.]
 
-   .. note::
-      A CR shall specify the stakeholder requirements as part of our platform/project.
-      Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR).
-
-
+.. note::
+   A CR shall specify the stakeholder requirements as part of our platform/project.
+   Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR).
 
 Backwards Compatibility
 =======================
@@ -99,38 +95,38 @@ Security Impact
 
 [How could a malicious user take advantage of this new/modified feature?]
 
-   .. note::
-      If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
+.. note::
+   If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
 
 Which security requirements are affected or has to be changed?
 Could the new/modified feature enable new threat scenarios?
 Could the new/modified feature enable new attack paths?
 Could the new/modified feature impact functional safety?
 If applicable, which additional security measures must be implemented to mitigate the risk?
 
-    .. note::
-     Use Trust Boundary, Defense in Depth Analysis and/or Security Software Critically Analysis,
-     Vulnerability Analysis.
-     [Methods will be defined later in Process area Security Analysis]
-     These analyses may not be available at the time of creation of the feature (request) but content will be improved iteratively.
+.. note::
+   Use Trust Boundary, Defense in Depth Analysis and/or Security Software Critically Analysis,
+   Vulnerability Analysis.
+   [Methods will be defined later in Process area Security Analysis]
+   These analyses may not be available at the time of creation of the feature (request) but content will be improved iteratively.
 
 Safety Impact
 =============
 
 [How could the safety be impacted by the new/modified feature?]
 
-   .. note::
-      If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
-      Link here to the filled out :need:`Impact Analysis Template <gd_temp__change_impact_analysis>` or copy the template in this chapter.
+.. note::
+   If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
+   Link here to the filled out :need:`Impact Analysis Template <gd_temp__change_impact_analysis>` or copy the template in this chapter.
 
 Which safety requirements are affected or has to be changed?
 Could the new/modified feature be a potential common cause or cascading failure initiator?
 If applicable, which additional safety measures must be implemented to mitigate the risk?
 
-    .. note::
-     Use Dependency Failure Analysis and/or Safety Software Critically Analysis.
-     [Methods will be defined later in Process area Safety Analysis]
-     These analyses may not be available at the time of creation of the feature (request) but content will be improved iteratively.
+.. note::
+   Use Dependency Failure Analysis and/or Safety Software Critically Analysis.
+   [Methods will be defined later in Process area Safety Analysis]
+   These analyses may not be available at the time of creation of the feature (request) but content will be improved iteratively.
 
 For new feature contributions:
 
@@ -148,35 +144,30 @@ How to Teach This
 
 [How to teach users, new and experienced, how to apply the CR to their work.]
 
-   .. note::
-      For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work.
-
+.. note::
+   For a CR that adds new functionality or changes behaviour, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work.
 
 
 Rejected Ideas
 ==============
 
 [Why certain ideas that were brought while discussing this CR were not ultimately pursued.]
 
-   .. note::
-      Throughout the discussion of a CR, various ideas will be proposed which are not accepted.
-      Those rejected ideas should be recorded along with the reasoning as to why they were rejected.
-      This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions.
-      In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued.
-
-
+.. note::
+   Throughout the discussion of a CR, various ideas will be proposed which are not accepted.
+   Those rejected ideas should be recorded along with the reasoning as to why they were rejected.
+   This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions.
+   In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued.
 
 Open Issues
 ===========
 
 [Any points that are still being decided/discussed.]
 
-   .. note::
-       While a CR is in draft, ideas can come up which warrant further discussion.
-       Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
-       This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
-
-
+.. note::
+   While a CR is in draft, ideas can come up which warrant further discussion.
+   Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
+   This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
 
 Footnotes
 =========

@@ -31,10 +31,10 @@ Type of Change Request
 Dependencies on other Change Requests
 -------------------------------------
 
-[List all dependencies on other Change Request]
+[List all dependencies on other Change Requests]
 
 
-Estimates for realization
+Estimates for Realization
 -------------------------
 
 [List all work products and elements affected by the Change Request]
@@ -67,12 +67,12 @@ Potential Impact on Security
 -----------------------------
 
 Add the potential impact in the chapter Security Impact of the concerned Feature Request
-(compare :need:`Feature Request Template <gd_temp__change_feature_request>`) or Coponent Request
+(compare :need:`Feature Request Template <gd_temp__change_feature_request>`) or Component Request
 (compare :need:`Component Request Template <gd_temp__change_component_request>`).
 
 Potential Impact on Safety
 --------------------------
 
 Add the potential impact in the chapter Safety Impact of the concerned Feature Request
-(compare :need:`Feature Request Template <gd_temp__change_feature_request>`) or Coponent Request
+(compare :need:`Feature Request Template <gd_temp__change_feature_request>`) or Component Request
 (compare :need:`Component Request Template <gd_temp__change_component_request>`).
@@ -96,7 +96,7 @@ During the docs build checks will be performed on the requirements. Those are sp
 Workflow for Creating a Requirement
 ===================================
 
-This section describes in detail which steps need to be performed to create a requirement based on :numref:`requirements_workflow_fig`
+This section describes in detail which steps need to be performed to create a requirement based on :ref:`requirements_workflow_fig`
 
 .. list-table:: Workflow for creating a requirement
    :header-rows: 1
@@ -232,7 +232,7 @@ AoUs can be of different class and shall be handled by tracing those
 
    AoU Traceability
 
-:numref:`aou_traceability` is an extension of the workproduct traceability to show the handling of AoU.
+:ref:`aou_traceability` is an extension of the workproduct traceability to show the handling of AoU.
 Note that the component level displayed in green shows two components - on the right (dark green) the one which is exporting AoU to be fulfilled by others,
 on the left (light green) the component which fulfills and exports AoU.
 Internal component's AoU can also be fulfilled (and linked) by other internal components, this is not depicted here, but would be quite the same with one exception:

@@ -43,7 +43,7 @@ Stakeholders for the requirements
 #. :need:`SW Architect <rl__committer>`
 
    * Break down the platform specification into features (High Level)
-   * Derive component architecture for each feature
+   * Derive feature/component architecture for each feature
    * Allocate requirements to architecture elements for specification of features/components
    * Define AoUs which arise from architecture
 
@@ -101,7 +101,7 @@ Based on the inputs of the previous chapter the types of requirements which need
 Stakeholder Requirements
 ========================
 
-On the platform level the *Stakeholder (=customer) Requirements* are defined. These requirements describe which content (functionality and safety mechanisms) the platform needs to contain, and serve as a project description of the top-level functionality. An example could be e.g.
+On the platform level the *Stakeholder (=customer) Requirements* are defined. These requirements describe which content (functionality and safety mechanisms) the platform needs to contain, and serve as a project description of the top-level functionality. An example could be:
 
 .. code-block:: text
 
@@ -117,23 +117,23 @@ The *Feature Requirements* derived from stakeholder requirements address mainly
 
 .. code-block:: text
 
-   The feature shall use JSON formatted string according to RFC-8259 for configuration
+   The feature shall use JSON formatted string according to RFC-8259 for configuration.
 
 However the detailed interaction of the underlying components itself which is required to form a feature shall be defined in the feature architecture.
 
 Component Requirements
 ======================
 
-The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behaviour a component itself needs to fulfil in the context of the feature, e.g.
+The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behaviour a component itself needs to fulfil in the context of the feature, for example:
 
 .. code-block:: text
 
-   The component shall provide API calls to read and interpret every field of a JSON body in C++
+   The component shall provide API calls to read and interpret every field of a JSON body in C++.
 
 Assumption of Use Requirements
 ==============================
 
-Last but not least a requirement type is needed which describes e.g. the boundary conditions which need to be fulfilled when using a software element. Those requirements are called *Assumption of Use* (AoUs) and can be defined on every level (stakeholder/SW-platform, feature, component).
+Last but not least a requirement type is needed which describes e.g. the boundary conditions which need to be fulfilled when using a software element. Those requirements are called *Assumption of Use* (AoUs) and can be defined on every level (stakeholder/SW-platform, feature, component). Example:
 
 .. code-block:: text
 
@@ -142,13 +142,12 @@ Last but not least a requirement type is needed which describes e.g. the boundar
 Process Requirements
 ====================
 
-Besides those four types of requirements which describe the contents of the platform also a type, describing the requirements towards the tooling from a process point of view, needs to be specified. These *process requirements* can be derived from a process description. Here it is defined which part of the process need to be performed manually and which parts of the process should be implemented by tooling
+Besides those four types of requirements which describe the contents of the platform also a type, describing the requirements towards the tooling from a process point of view, needs to be specified. These *process requirements* can be derived from a process description. Here it is defined which part of the process need to be performed manually and which parts of the process should be implemented by tooling. Example:
 
 .. code-block:: text
 
    It shall be checked that safety requirements (Safety != QM) can only be linked against safety requirements.
 
-
 .. _attributes of the requirements:
 
 Attributes of the Requirements
@@ -188,7 +187,7 @@ Following attributes need to be filled manually for each requirement:
        - Process: If implemented can be verified by reviewing the process description (sub-type of non-functional)
        - Non-Functional: If implemented can be checked by review/analysis (of e.g. code, documentation)
 
-       Note that the linking to the requirements is affected by these types, see :need:`gd_req__req_linkage_architecture`
+       Note that the linking to the requirements is affected by these types, see :need:`gd_req__req_linkage_architecture`.
 
 Following attributes are automatically generated:
 
@@ -212,7 +211,7 @@ Following attributes are automatically generated:
      - During Build the code files are parsed for a defined tag which includes the requirement id. If this is located a link to the code will be added in the requirement
      - Docs-as-Code
    * - Verified by
-     - During build the junit test files are parsed for a defined marker which includes the requirement id. If the marker is located in the test a link to the test case will be added to the requirement
+     - During build the test files are parsed for a defined marker which includes the requirement id. If the marker is located in the test a link to the test case will be added to the requirement
      - Docs-as-Code
    * - Requirement Covered
      - During build it will be checked if the requirements hashes which are mentioned in the coverage file match the hashes of the linked child requirements. If so then this attribute will be set to yes.
@@ -283,12 +282,12 @@ In the general for the reviews a :ref:`guideline <review_concept>` exists.
 
 .. _coverage_of_requirements:
 
-Coverage of requirements
+Coverage of Requirements
 ************************
 
 According to the standards, requirements shall be derived from top to bottom. This means that at the point in time when the parent requirement is generated the coverage for itself can not be evaluated. In a second step all the parent requirements need to be broken down into child requirements which are linked to the parent requirement again. If during the creation of the child requirements any of the parent requirements would be touched again the hash value of the parent requirement would change and the linkage from the child to the parent requirement would be invalid again.
 
-Therefore the information concerning requirement coverage is stored in a config file located in the same folder as the requirements file. It contains the parent requirements and it´s links to child requirements including hashes to the of the child requirements. If it is merged to the main branch it will specify exactly the coverage of child requirements which are required to fulfil the coverage of the parent requirement.
+Therefore the information concerning requirement coverage is stored in a config file located in the same folder as the requirements file. It contains the parent requirements and its links to child requirements including hashes to the of the child requirements. If it is merged to the main branch it will specify exactly the coverage of child requirements which are required to fulfil the coverage of the parent requirement.
 
 If this file will now be merged to the main branch a review will be triggered again. During this review it will only be checked if the parent requirement is covered by its child requirements.