resolves warnings building documentation

process/general_concepts/score_review_concept.rst

@@ -60,7 +60,7 @@ In this project there are inspections on the following work products, which are
         * - :need:`wp__sw_implementation`
           - :need:`gd_chklst__impl_inspection_checklist`
 
-Note that for testcases on unit, component and feature level (as defined in :need:`doc__verification_plan`)
+Note that for testcases on unit, component and feature level (as defined in :need:`SCORE_doc__verification_plan`)
 also a review checklist is provided for guidance, but no formal inspection is required. The same is true for Safety Analysis and DFA.
 The independence of testing respectively of test case review is covered by the use of GitHub also for the review of test cases.
 Which means that at least the test case definition or the test case review is performed by
@@ -83,7 +83,7 @@ based on the CODEOWNER(s) definition of the modified files. In case the fixing o
 between reviewer(s) and author, the safety manager or quality manager can be added to the review to moderate a solution.
 
 The initial step for requirements and architecture is the (informal) GitHub review on every Pull-Request
-(resp. Change Request, see :need:`doc__contr_guideline`)
+(resp. Change Request, see :need:`SCORE_doc__contr_guideline`)
 which creates or modifies one of these work products (subject to inspection).
 After this review the work products are in status "valid", which means they can be used for further development and verification steps.
 In this review the checklist entries shall be considered which are tagged as "incremental".

process/index.rst

@@ -90,7 +90,7 @@ How To Contribute
 
 How to contribute to the S-CORE project (e.g. naming convention, folder structure, IDE setup) can be found here:
 
-:ref:`contribute`
+:ref:`SCORE_contribute`
 
 Standards
 ---------

process/introduction/index.rst

@@ -42,7 +42,7 @@ Approach
 3. We aim to develop the process in conformance to the targeted standards (compare figure below).
 4. We aim to establish traceability from the begin (compare figure below, :ref:`wp_traceability_model`).
 5. We aim to verify conformity and traceability by tool automation as much as possible (compare figure below).
-6. We aim for an iterative collaboration model initiated by change requests (compare :need:`doc__contr_guideline`)
+6. We aim for an iterative collaboration model initiated by change requests (compare :need:`SCORE_doc__contr_guideline`)
 
 
 .. figure:: _assets/score_process_model.drawio.svg

process/process_areas/architecture_design/guidance/architecture_guideline.rst

@@ -33,7 +33,7 @@ Attributes
 For all architectural need elements following mandatory attributes are defined:
 
 .. needtable:: Overview of mandatory attributes
-   :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req"
+   :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False
    :style: table
    :columns: title; id
    :colwidths: 30,70
@@ -45,7 +45,7 @@ Checks
 For architectural elements following checks are defined:
 
 .. needtable:: Overview of checks on architectural elements
-   :filter: "check" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req"
+   :filter: "check" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False
    :style: table
    :columns: title; id
    :colwidths: 30,70
@@ -106,8 +106,8 @@ Based on this template the feature architecture shall describe the concept of th
 
 For this step following guidances are available:
 
-* :ref:`Branch Naming Conventions <branch_naming>`
-* :ref:`Git Guidelines <git_guidelines>`
+* :ref:`Branch Naming Conventions <SCORE_branch_naming>`
+* :ref:`Git Guidelines <SCORE_git_guidelines>`
 * :need:`[[title]] Feature Architecture <gd_temp__arch__feature>`
 
 .. _model_feature_architecture:
@@ -178,8 +178,8 @@ Based on the *feature architecture* the concept for the *component architecture*
 
 For this step following guidances are available:
 
-* :ref:`Branch Naming Conventions <branch_naming>`
-* :ref:`Git Guidelines <git_guidelines>`
+* :ref:`Branch Naming Conventions <SCORE_branch_naming>`
+* :ref:`Git Guidelines <SCORE_git_guidelines>`
 * :need:`[[title]] <gd_temp__arch__comp>`
 
 .. _allocate_component_requirements:

process/process_areas/architecture_design/guidance/architecture_process_reqs.rst

@@ -105,7 +105,7 @@ Attributes of Architectural Elements
       * last part of the feature tree
       * keyword describing the content of the requirement.
 
-   The naming convention is defined here: :ref:`naming_convention_needs`
+   The naming convention is defined here: :ref:`SCORE_naming_convention_needs`
 
 .. gd_req:: Architecture attribute: security
    :id: gd_req__arch_attr_security
@@ -179,7 +179,7 @@ Checks for Architectural Design
    It shall be checked if all mandatory attributes for each architectural element is provided by the user. For all elements following attributes shall be mandatory:
 
    .. needtable:: Overview mandatory requirement attributes
-      :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req"
+      :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False
       :style: table
       :columns: title
       :colwidths: 30

process/process_areas/architecture_design/index.rst

@@ -30,5 +30,5 @@ Architecture Design
    _assets/architecture_modeling_example
 
 
-.. needextend:: "process_areas/architecture_design" in docname
+.. needextend:: docname is not None and "process_areas/architecture_design" in docname
    :+tags: architecture_design

process/process_areas/change_management/change_management_concept.rst

@@ -26,7 +26,7 @@ including the requirements of the different stakeholders for the Change Manageme
 
 Key concept
 ***********
-A Change Request is the **ONLY** way to contribute (compare :need:`doc__contr_guideline`)
+A Change Request is the **ONLY** way to contribute (compare :need:`SCORE_doc__contr_guideline`)
 new features or to modify the scope of existing features in the **S-CORE** project.
 As features are built-up by Components a Change Request is also needed to add new Components or
 to modify the scope of existing Components.

process/process_areas/change_management/change_management_getstrt.rst

@@ -25,4 +25,4 @@ In case you want to contribute a change to **S-CORE** consider to:
 * Contact the :need:`Technical Lead <rl__technical_lead>` for your contribution to establish planning and reporting
 * Create your change requests according to :need:`wf__change__cr_an_change_request`
 * Make familiar with the development and supporting process descriptions in :ref:`process_description`
-* Make familiar with the relevant sections of the :ref:`Platform Management Plan <pmp>`, here especially with :need:`Change Management Plan <doc__platform_change_management_plan>`
+* Make familiar with the relevant sections of the :need:`Platform Management Plan <SCORE_doc__platform_mgt_plan>`, here especially with :need:`Change Management Plan <SCORE_doc__platform_change_management_plan>`

process/process_areas/change_management/change_management_workproducts.rst

@@ -62,5 +62,5 @@ Work Products Change Management
    | which changes the scope of the component.
    | Software Modules are also Components (top-level component).
 
-.. needextend:: "docs/process/change_management" in docname
+.. needextend:: docname is not None and "process_areas/change_management" in docname
    :+tags: change_management

process/process_areas/change_management/guidance/change_management_guideline.rst

@@ -25,7 +25,7 @@ This document describes the general guidances for Change Management based on the
 General Hints
 =============
 
-The detailed implementation of the Change Management for **S-CORE** is described in the :need:`[[title]]<doc__platform_change_management_plan>`.
+The detailed implementation of the Change Management for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_change_management_plan>`.
 
 Templates
 ---------
@@ -55,7 +55,7 @@ For all Change Requests following mandatory attributes need to be defined:
 
 .. needtable:: Overview of mandatory change request attributes
    :tags: change_management
-   :filter: "mandatory" in tags and "attribute" in tags and "chm" in tags
+   :filter: "mandatory" in tags and "attribute" in tags and "chm" in tags and is_external == False
    :style: table
    :columns: title
    :colwidths: 30
@@ -80,7 +80,7 @@ Split may required, if
 
 | 2. Affected work products are in different locations.
 
-Refer to the :need:`Change Management Plan <doc__platform_change_management_plan>` for examples
+Refer to the :need:`Change Management Plan <SCORE_doc__platform_change_management_plan>` for examples
 how to create simple or more complex Change Requests.
 
 .. list-table:: Activities for Change Request

process/process_areas/change_management/guidance/change_management_reqs.rst

@@ -138,7 +138,7 @@ Change Request Checks
    is provided by the user. For all requirements following attributes shall be mandatory:
 
    .. needtable:: Overview mandatory change request attributes
-      :filter: "mandatory" in tags and "attribute" in tags and "chm" in tags
+      :filter: "mandatory" in tags and "attribute" in tags and "chm" in tags  and is_external == False
       :style: table
       :columns: title
       :colwidths: 30
@@ -159,5 +159,5 @@ Change Request Traceability Impact Analysis Tool
    It shall be reported, which work products and elements are affected by adding a new
    feature or component or by a modification of an existing feature or component.
 
-.. needextend:: "process_areas/change_management" in docname
+.. needextend:: docname is not None and "process_areas/change_management" in docname
    :+tags: change_management

process/process_areas/configuration_management/index.rst

@@ -56,7 +56,7 @@ needed for the building of the documentation and verification reports (e.g. tool
 Work Products
 ^^^^^^^^^^^^^
 
-:need:`doc__config_mgt_plan` is a document and part of the work product :need:`wp__platform_mgmt`.
+:need:`SCORE_doc__config_mgt_plan` is a document and part of the work product :need:`wp__platform_mgmt`.
 
 
 Configuration Management Tooling
@@ -78,11 +78,11 @@ Getting started
 In case you are appointed as a :need:`Technical Lead <rl__technical_lead>` by the :need:`rl__project_lead` in the S-CORE project:
 
 * On platform level, process community already provided a draft configuration management plan,
-  see :need:`doc__config_mgt_plan`, just set it to "valid"
+  see :need:`SCORE_doc__config_mgt_plan`, just set it to "valid"
 * On module level, create a configuration management plan using the platform one as a template.
   If no configuration management plan on module level is created, the platform one is adopted.
 
-As a normal contributor or committer consult the :need:`doc__config_mgt_plan`, but this should not
+As a normal contributor or committer consult the :need:`SCORE_doc__config_mgt_plan`, but this should not
 differ from normal usage of github as a configuration management tool.
 
 Workflows
@@ -98,7 +98,7 @@ Guidance
 --------
 
 The configuration management guideline is contained within the configuration management plan,
-to have all relevant information in one space, see :need:`gd_guidl__configuration`
+to have all relevant information in one space, see :need:`SCORE_gd_guidl__configuration`
 
 Some process requirements to be automated are available:
 

process/process_areas/documentation_management/documentation_getstrt.rst

@@ -22,6 +22,6 @@ Getting Started
 In case you are appointed as a :need:`Technical Lead <rl__technical_lead>` by the :need:`rl__project_lead` in the S-CORE project:
 
 * On platform level, process community already provided a draft documentation management plan,
-  see :need:`doc__documentation_mgt_plan`, just set it to "valid"
+  see :need:`SCORE_doc__documentation_mgt_plan`, just set it to "valid"
 * On module level, create a documentation management plan using the platform one as a template
 * On both levels: make sure only the documents in your scope appear in the documents list within the plan

process/process_areas/documentation_management/guidance/documentation_guideline.rst

@@ -22,7 +22,7 @@ Guideline
 
 The planning for the documents is part of the Platform Management Plan.
 
-The formal elements for documentations in S-CORE are described here: :need:`doc__documentation_mgt_plan`.
+The formal elements for documentations in S-CORE are described here: :need:`SCORE_doc__documentation_mgt_plan`.
 
 For manual review of the formal elements the
 :need:`Documentation Review Checklist <gd_chklst__documentation__review>` may used.

process/process_areas/documentation_management/index.rst

@@ -27,5 +27,5 @@ Documentation Management
    documentation_workflow
    documentation_workproducts
 
-.. needextend:: "process_areas/documentation_management" in docname
+.. needextend:: docname is not None and "process_areas/documentation_management" in docname
    :+tags: doc_mgt

process/process_areas/implementation/guidance/implementation_guideline.rst

@@ -28,12 +28,12 @@ Workflow for Implementation
 Detailed description which steps are need for implementation.
 
 #. Consult which programming languages, design/coding guidelines and tools are used for Software
-   development within the Software Development Plan :need:`doc__software_development_plan`.
+   development within the Software Development Plan :need:`SCORE_doc__software_development_plan`.
 #. Create a Detailed Design by using the template :need:`gd_temp__detailed_design`.
    In this step, the components are broken down into smaller, independent units that can be tested
    separately during the unit testing phase. The detailed design shall be so exact, that test and
    implementation can be run simultaneously.
-#. Implement the source code, by using the coding guidelines :need:`doc__cpp_coding_guidelines` for C++,
+#. Implement the source code, by using the coding guidelines :need:`SCORE_doc__cpp_coding_guidelines` for C++,
    or <TBD> for Rust.
 #. Create a pull request for your change.
 #. Detail Design and Code Inspection is done to review the code of the software and detect errors in it.

process/process_areas/implementation/guidance/implementation_process_reqs.rst

@@ -33,5 +33,5 @@ Process Requirements
 
    The dynamic diagram represents the unit and their relationships using UML 2.0 notations by using PlantUML.
 
-.. needextend:: "process_areas/implementation" in docname
+.. needextend:: docname is not None and "process_areas/implementation" in docname
    :+tags: implementation

process/process_areas/implementation/implementation_workproducts.rst

@@ -46,5 +46,5 @@ Workproducts Implementation
    - Method selection (e.g. for Architecture Verification)
    - development tools
 
-.. needextend:: "docs/process/implementation" in docname
+.. needextend:: docname is not None and "process_areas/implementation" in docname
    :+tags: implementation

process/process_areas/platform_management/guidance/platform_management_guideline.rst

@@ -25,7 +25,7 @@ This document describes the general guidances for Platform Management based on t
 General Hints
 =============
 
-The detailed implementation of the Platform Management Plan for **S-CORE** is described in the :need:`[[title]]<doc__platform_mgt_plan>`.
+The detailed implementation of the Platform Management Plan for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_mgt_plan>`.
 
 An iterative and incremental development model shall be used.
 

process/process_areas/platform_management/platform_management_getstrt.rst

@@ -24,4 +24,4 @@ In case you want to manage contributions to **S-CORE** consider to:
 
 * Contact the :need:`Technical Lead <rl__technical_lead>` for your contribution to establish planning and reporting
 * Make familiar with the management, development and supporting process descriptions in :ref:`process_description`
-* Make familiar with the relevant sections of the :ref:`Platform Management Plan <pmp>`, especially :need:`doc__project_mgt_plan`
+* Make familiar with the relevant sections of the :need:`Platform Management Plan <SCORE_doc__platform_mgt_plan>`, especially :need:`SCORE_doc__project_mgt_plan`

process/process_areas/platform_management/platform_management_workproducts.rst

@@ -47,5 +47,5 @@ Work Products Platform Management
 
    Defines escalation path.
 
-.. needextend:: "docs/process/platform_management" in docname
+.. needextend:: docname is not None and "process_areas/platform_management" in docname
    :+tags: platform_management

process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst

@@ -25,7 +25,7 @@ This document describes the general guidances for Problem Resolution based on th
 General Hints
 =============
 
-The detailed implementation of the Problem Resolution for **S-CORE** is described in the :need:`[[title]]<doc__platform_problem_resolution_plan>`.
+The detailed implementation of the Problem Resolution for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_problem_resolution_plan>`.
 
 Templates
 ---------
@@ -39,7 +39,7 @@ For all Problems following mandatory attributes need to be defined:
 
 .. needtable:: Overview of mandatory problem resolution attributes
    :tags: problem_resolution
-   :filter: "mandatory" in tags and "attribute" and "problem_resolution" in tags
+   :filter: "mandatory" in tags and "attribute" and "problem_resolution" in tags and is_external == False
    :style: table
    :columns: title
    :colwidths: 30
@@ -54,7 +54,7 @@ Activities for Problem Resolution
 
 This section describes in detail which steps need to be performed for a Problem resolution.
 
-Refer to the :need:`Problem Resolution Plan <doc__platform_problem_resolution_plan>` for examples
+Refer to the :need:`Problem Resolution Plan <SCORE_doc__platform_problem_resolution_plan>` for examples
 how to create problem reports.
 
 .. list-table:: Activities for Problem Resolution

process/process_areas/problem_resolution/guidance/problem_resolution_reqs.rst

@@ -174,7 +174,7 @@ Problem Resolution Checks
    is provided by the user. For all requirements following attributes shall be mandatory:
 
    .. needtable:: Overview mandatory problem attributes
-      :filter: "mandatory" in tags and "attribute" and "problem_resolution" in tags
+      :filter: "mandatory" in tags and "attribute" and "problem_resolution" in tags and is_external == False
       :style: table
       :columns: title
       :colwidths: 30

process/process_areas/problem_resolution/guidance/problem_resolution_template.rst

@@ -31,7 +31,7 @@ Problem status
 [“open”, “in review”, “in implementation”, “closed”, “rejected”]
 
 If possible, use for problem status the properties of the selected Issue Tracking System
-(for implementation see here :need:`doc__platform_problem_resolution_plan`)
+(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
 
 | (to be filled out during :need:`wf__problem__create_pr`)
 | (to be updated during :need:`wf__problem__analyse_pr`)
@@ -42,7 +42,7 @@ Problem submitter
 [Who is the reporter of the problem?]
 
 If possible, use for problem submitter the properties of the selected Issue Tracking System
-(for implementation see here :need:`doc__platform_problem_resolution_plan`)
+(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
@@ -83,7 +83,7 @@ Problem stakeholder
 Add affected feature, if possible
 
 If possible, use for problem stakeholder the properties of the selected Issue Tracking System
-(see implementation here :need:`doc__platform_problem_resolution_plan`)
+(see implementation here :need:`SCORE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
@@ -106,7 +106,7 @@ Bug:
 Safety, Security, Quality: Additional qualifier to highlight, if safety, security or quality is affected
 
 If possible, use for problem category the properties of the selected Issue Tracking System
-(for implementation see here :need:`doc__platform_problem_resolution_plan`)
+(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
@@ -145,7 +145,7 @@ Problem expected closure date
 [Milestone when the problem should be resolved]
 
 If possible, use for problem closure date the properties of the selected Issue Tracking System
-(for implementation see here :need:`doc__platform_problem_resolution_plan`)
+(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 

process/process_areas/problem_resolution/problem_resolution_concept.rst

@@ -26,7 +26,7 @@ including the requirements of the different stakeholders for the Problem Resolut
 
 Key concept
 ***********
-A Problem Report is the **ONLY** way to report (compare :need:`doc__contr_guideline`)
+A Problem Report is the **ONLY** way to report (compare :need:`SCORE_doc__contr_guideline`)
 deviations of an expected result for existing features in the **S-CORE** project.
 Deviations include problems found by user, bugs found during verification activites by tester,
 quality issues found by quality checks, safety anomalies, vulnerabilites or any other malfunction.