Remove issue templates

process/glossary/index.rst

@@ -81,6 +81,10 @@ Terms
      - A packaging mechanism for delivering Dependable Elements (e.g., executable code or libraries) to users or integrators of the platform.
      - :ref:`Building blocks concept<general_concepts_building_blocks>`
 
+   * - **Delivery Team**
+     - Cross-functional team responsible for all artifacts within a Module, including development, quality, safety, and security activities.
+     - :ref:`Roles<roles>`
+
    * - **Dependable Element**
      - The highest abstraction level in the building blocks model. A Dependable Element consists of one or more Components and can be developed as a Safety Element out of Context (SEooC). It is delivered in a Delivery Container.
      - :ref:`Building blocks concept<general_concepts_building_blocks>`
@@ -117,6 +121,10 @@ Terms
      - Systematic analysis performed on feature architecture to verify compliance with safety and security requirements at the feature level, documenting any violations or potential faults.
      - ::ref:`Building blocks concept<general_concepts_building_blocks>`
 
+   * - **Feature Team**
+     - An synonym term for Delivery Team.
+     - :ref:`Roles<roles>`
+
    * - **Impact Analysis**
      - The process of evaluating the effects and consequences of proposed changes on work products.
      - :ref:`Process change management<change_management>`
@@ -137,10 +145,6 @@ Terms
      - An synonym term for Dependable Element
      - :ref:`Building blocks concept<general_concepts_building_blocks>`
 
-   * - **Module Team**
-     - Cross-functional team responsible for all artifacts within a Module, including development, quality, safety, and security activities.
-     - :ref:`Roles<roles>`
-
    * - **Platform**
      - The complete software platform consisting of features, components, and supporting infrastructure.
      - :ref:`Building blocks concept<general_concepts_building_blocks>`

process/process_areas/change_management/change_management_workflow.rst

@@ -24,8 +24,8 @@ For a detailed explanation of workflows and their role within the process model,
    :status: valid
    :tags: change_management
    :responsible: rl__contributor
-   :approved_by: rl__committer
-   :supported_by: rl__project_lead, rl__safety_manager, rl__security_manager, rl__quality_manager
+   :approved_by: rl__architecture_community
+   :supported_by: rl__platform_team
    :input: wp__policies, wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
@@ -42,9 +42,9 @@ For a detailed explanation of workflows and their role within the process model,
    :id: wf__change_analyze_cr
    :status: valid
    :tags: change_management
-   :responsible: rl__contributor
+   :responsible: rl__architecture_community
    :approved_by: rl__project_lead
-   :supported_by: rl__committer, rl__safety_manager, rl__security_manager, rl__quality_manager
+   :supported_by: rl__platform_team
    :input: wp__policies, wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
@@ -53,20 +53,21 @@ For a detailed explanation of workflows and their role within the process model,
    The Change Request is analyzed.
 
    Until the template is not filled out properly, the Change Request may be set back to
-   “open” from the :need:`Committer <rl__committer>`.
+   “open” from the :need:`Architecture Team <rl__architecture_community>`.
 
    If the Change Request shall be implemented, the Change Request status is set to
    "in implementation", otherwise to "rejected".
 
-   The author of the Change Request may cancel it, thus the status is set to "rejected".
+   If the author, :need:`Contributor <rl__contributor>`. of the Change Request decides to
+   cancel it, thus the status is set to "rejected" too.
 
 .. workflow:: Implement and Monitor Change Request
    :id: wf__change_implement_monitor_cr
    :status: valid
    :tags: change_management
-   :responsible: rl__contributor
-   :approved_by:  rl__committer
-   :supported_by: rl__project_lead, rl__safety_manager, rl__security_manager, rl__quality_manager
+   :responsible: rl__delivery_team, rl__platform_team
+   :approved_by:  rl__delivery_team, rl__platform_team
+   :supported_by: rl__project_lead
    :input: wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
@@ -77,22 +78,21 @@ For a detailed explanation of workflows and their role within the process model,
    This may require additional activities, including creating ISSUEs and PRs.
    These are linked to the Change Request and monitored until closure.
 
-   The Change Request is done, if all linked activities has been closed and confirmed.
-   Before closing the Change Request, :need:`Committer <rl__committer>` must check the
+   The Change Request is done, if all linked activities has been closed and confirmed,
+   which is done by the approval of the selected codeowners.
+   Before closing the Change Request, :need:`Delivery Team <rl__delivery_team>` must check the
    correctness.
 
-   The :need:`Committer <rl__committer>` may still reject it, thus the status is set to
-   "rejected".
-
-   The author of the Change Request may cancel it, thus the status is set to "rejected".
+   The :need:`Delivery Team <rl__delivery_team>` may still reject it, thus the status
+   is set to "rejected".
 
 .. workflow:: Close Change Request
    :id: wf__change_close_cr
    :status: valid
    :tags: change_management
-   :responsible: rl__committer
-   :approved_by: rl__project_lead
-   :supported_by: rl__safety_manager, rl__security_manager, rl__quality_manager
+   :responsible: rl__delivery_team, rl__platform_team
+   :approved_by: rl__delivery_team, rl__platform_team
+   :supported_by: rl__project_lead
    :input: wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
    :contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
@@ -101,9 +101,10 @@ For a detailed explanation of workflows and their role within the process model,
    The Change Request is closed.
 
    The Change Request is closed only, if the implementation is sufficient. That is verified
-   by the :need:`Committer <rl__committer>` finally.
+   by the :need:`Delivery Team <rl__delivery_team>` finally, especially the selected
+   codeowners of the team must approve.
 
-   Otherwise the :need:`Committer <rl__committer>` keeps the status "in implementation".
+   Otherwise the :need:`Delivery Team <rl__delivery_team>` keeps the status "in implementation".
 
 .. needextend:: docname is not None and "process_areas/change_management" in docname
    :+tags: change_management