fix audit findings action_78

process/process_areas/change_management/change_management_concept.rst

@@ -45,22 +45,30 @@ Stakeholders for the Change Requests
 #. :need:`Contributor <rl__contributor>`
 
    * In general contributes features and components to grow the project content
-   * Creates change requests, analyzes changes, implement changes
+   * Creates change requests
+   * Supports all change request activities
 
-#. :need:`Committer <rl__committer>`
+#. :need:`Architecture Team <rl__architecture_community>`
 
+   * Supports all change request activities
+   * Approves the creation of the change request
    * Verifies that the contribution including change requests fulfills the project policies
-   * Approves all change request activities besides changes closing
-   * Is responsible to initiate the the closure of the change request
 
-#. :need:`Project Lead <rl__project_lead>`
+#. :need:`Platform Team <rl__platform_team>`
 
-   * Supports all change request activities
-   * Approves the closing of the change request
+   * Supports creation and the analysis of change requests
+   * Is responsible and approves the implementation and the closure of the feature change request
+
+#. :need:`Delivery Team <rl__delivery_team>`
 
-#. :need:`Safety Manager <rl__safety_manager>`, :need:`Security Manager <rl__security_manager>`, :need:`Quality Manager <rl__quality_manager>`
+   * Is responsible and approves the implementation and the closure of the component change request
+
+#. :need:`Project Lead <rl__project_lead>`
 
    * Supports all change request activities
+   * Approves the analysis of the change request
+   * Verifies that the contribution including change requests fulfills the project policies
+
 
 Standard Requirements
 =====================
@@ -103,12 +111,13 @@ Analysis of the Change Request
 Based on the analysis results decision about the acceptance or rejection must be taken
 by authorized persons.
 
-Authorized person includes
+Authorized person, as members of the :need:`Platform Team <rl__platform_team>`, includes
 
 #. :need:`Project Lead <rl__project_lead>`
 #. :need:`Safety Manager <rl__safety_manager>`
 #. :need:`Security Manager <rl__security_manager>`
 #. :need:`Quality Manager <rl__quality_manager>`
+#. :need:`Committer <rl__committer>`
 
 Further prioritization must be done, e.g. based on release planning.
 
@@ -122,7 +131,8 @@ monitored.
 The Change Request implementation must be tracked until it is closed.
 
 The status of the Change Request must be communicated by the
-:need:`Project Lead <rl__project_lead>` until
+:need:`Project Lead <rl__project_lead>` (for feature requests) and the lead of the
+:need:`Delivery Team <rl__delivery_team>` (for component requests) until
 the implementation is completed and confirmed.
 
 .. _chm_closing:

process/process_areas/change_management/change_management_roles.rst

@@ -20,11 +20,10 @@ For change management no additional roles need to be defined.
 Contributing Roles:
 
    * :need:`Contributor <rl__contributor>`
-   * :need:`Committer <rl__committer>`
+   * :need:`Architecture Team <rl__architecture_community>`
+   * :need:`Platform Team <rl__platform_team>`
    * :need:`Project Lead <rl__project_lead>`
-   * :need:`Safety Manager <rl__safety_manager>`
-   * :need:`Security Manager <rl__security_manager>`
-   * :need:`Quality Manager <rl__quality_manager>`
+   * :need:`Delivery Team <rl__delivery_team>`
 
 A detailed overview of the responsibility for the steps of the requirement process is listed here:
 

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,33 +78,50 @@ 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
-   correctness.
+   The Change Request is done, if all linked activities has been closed and confirmed,
+   which is done by the approval of the selected codeowners.
+
+   Depending on the type of the Change Request (Feature or Component), different Teams
+   are responsibly for this workflow.
+
+   For feature:
+   Before closing the Change Request, :need:`Platform Team <rl__platform_team>` must
+   check the correctness.
 
-   The :need:`Committer <rl__committer>` may still reject it, thus the status is set to
-   "rejected".
+   For component:
+   Before closing the Change Request, :need:`Delivery Team <rl__delivery_team>` must
+   check the correctness.
 
-   The author of the Change Request may cancel it, thus the status is set to "rejected".
+   The responsible 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
    :has: doc_concept__change_process, doc_getstrt__change_process
 
    The Change Request is closed.
 
+   Depending on the type of the Change Request (Feature or Component), different Teams
+   are responsibly for this workflow.
+
+   For feature:
+   The Change Request is closed only, if the implementation is sufficient. That is verified
+   by the :need:`Platform Team <rl__platform_team>` finally, especially the selected
+   codeowners of the team must approve.
+
+   For component:
    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 responsible teams keeps the status "in implementation".
 
 .. 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

@@ -89,19 +89,19 @@ This section describes in detail which steps need to be performed for a Change R
    * - :ref:`1. <chm_create_change_request>`
      - Create Change Request
      - :need:`[[title]] <rl__contributor>`
-     - :need:`[[title]] <rl__committer>`
+     - :need:`[[title]] <rl__architecture_community>`
    * - :ref:`2. <chm_analyze_change_request>`
      - Analyze Change Request
-     - :need:`[[title]] <rl__contributor>`
+     - :need:`[[title]] <rl__architecture_community>`
      - :need:`[[title]] <rl__project_lead>`
    * - :ref:`3. <chm_imp_mon_change_request>`
      - Implement and Monitor Change Request
-     - :need:`[[title]] <rl__contributor>`
-     - :need:`[[title]] <rl__committer>`
+     - :need:`[[title]] <rl__platform_team>`, :need:`[[title]] <rl__delivery_team>`
+     - :need:`[[title]] <rl__platform_team>`, :need:`[[title]] <rl__delivery_team>`
    * - :ref:`4. <chm_close_change_request>`
      - Close Change Request
-     - :need:`[[title]] <rl__committer>`
-     - :need:`[[title]] <rl__project_lead>`
+     - :need:`[[title]] <rl__platform_team>`, :need:`[[title]] <rl__delivery_team>`
+     - :need:`[[title]] <rl__platform_team>`, :need:`[[title]] <rl__delivery_team>`
 
 
 .. _chm_create_change_request:
@@ -173,8 +173,8 @@ When ready to review and to analyze, the author sets the status to "in review" m
 Analyze Change Request
 ----------------------
 The projects :need:`[[title]] <rl__project_lead>` supported by
-:need:`[[title]] <rl__committer>` (includes Safety, Security and Quality Manager) analyzes the change
-request together with the :need:`[[title]] <rl__contributor>` and takes a decision with
+:need:`[[title]] <rl__platform_team>` (includes Safety, Security and Quality Manager) analyzes the change
+request together with the :need:`[[title]] <rl__architecture_community>` and takes a decision with
 the submitting/authoring contributor for accepting or rejecting it.
 
 The analysis will start by reviewing all the information given during the creation of the
@@ -194,6 +194,9 @@ should be closed, shall be defined. Optionally, the corresponding milestone can
 
 If accepted, :need:`[[title]] <rl__contributor>` can start with the implementation of the
 Change Request.
+Depending of feature or component requests, :need:`[[title]] <rl__platform_team>` or
+:need:`Delivery Team <rl__delivery_team>` will be empowered for the implementation,
+which will contain the :need:`[[title]] <rl__contributor>`.
 
 The author has the freedom to cancel the change request at any time by setting the status to "rejected".
 
@@ -208,8 +211,9 @@ The author has the freedom to cancel the change request at any time by setting t
 Implement and Monitor Change Request
 ------------------------------------
 
-If accepted, the projects :need:`[[title]] <rl__committer>` initiates the implementation
-of the change together with the :need:`[[title]] <rl__contributor>`.
+If accepted, the either the :need:`[[title]] <rl__platform_team>` (feature) or
+:need:`Delivery Team <rl__delivery_team>` (component) initiates the implementation
+of the change.
 
 The description may reflect details for the implementation.
 
@@ -242,28 +246,30 @@ When ready to implement, the author sets the status to "in implementation" manua
   | * The **Create a branch** action may used to create automatically a linked pull request
 
 During the implementation of the change the responsible lead :need:`[[title]] <rl__project_lead>`
+or the assigned lead of the :need:`Delivery Team <rl__delivery_team>`
 reports regularly the status to the affected
 projects teams.
 
-The author has the freedom to cancel the change request at any time by setting the status to "rejected".
+The :need:`[[title]] <rl__contributor>` as an author has the freedom to cancel the
+change request at any time by setting the status to "rejected".
 
 
 .. _chm_close_change_request:
 
 Close Change Request
 --------------------
 
-During implementation the :need:`[[title]] <rl__contributor>` monitors all activities linked to
+During implementation the responsible team (:need:`[[title]] <rl__platform_team>`
+or :need:`Delivery Team <rl__delivery_team>`) monitors all activities linked to
 the change, until they are closed.
 
-:need:`[[title]] <rl__committer>` finally checks if the Change Request implementation
+The team finally checks if the Change Request implementation
 is sufficient before the status is changed to closed. To check, if it is sufficient,
 :need:`Change Request Checklist <gd_chklst__change_cr_review>` can be used.
 Further the effectiveness of the implemented measure is confirmed and the availability
 of the required reports, as well as verification results, if applicable.
 
-When confirmed, the :need:`[[title]] <rl__project_lead>`
-sets the status to "closed" manually, if not done automatically.
+When confirmed, the team sets the status to "closed" manually, if not done automatically.
 
 .. note::
   | For the Change Request Example:
@@ -272,8 +278,7 @@ sets the status to "closed" manually, if not done automatically.
   | * The PR status must be changed to **Merged**
   | * The combination of issue status **Closed** and "Process Development Community" status **Done** and the pull request status **Merged** defines the status **closed**
 
-:need:`[[title]] <rl__committer>` has the freedom to reject it at any time by setting the status
-to "reject".
+The teams has the freedom to reject it at any time by setting the status to "reject".
 
 Tailoring
 =========

process/roles/index.rst

@@ -108,7 +108,17 @@ Project Development Roles
    The testing community members are responsible for the test case development from component to
    platform level. They shall be included in any requirements reviews. They can also improve
    independence argumentation when involved in the development of unit testing on safety critical
-   units. In this way the testing community takes a supportive role for unit testing
+   units. In this way the testing community takes a supportive role for unit testing.
+
+.. role:: Architecture Community Member
+   :id: rl__architecture_community
+   :status: valid
+   :tags: architecture_design
+   :contains: rl__committer
+
+   The architecture community members are responsible for the features and components of
+   the platform. Feature and Components requests, which add new ones or modifications, are
+   in their responsibility. They are aligned with the Project Leads.
 
 .. role:: Project Security Team
    :id: rl__security_team
@@ -126,18 +136,25 @@ Project Teams
    :id: rl__platform_team
    :status: valid
    :tags: cross_functional
-   :contains: rl__project_lead, rl__safety_manager, rl__quality_manager, rl__security_manager, rl__contributor, rl__committer, rl__infrastructure_tooling_community, rl__process_community
+   :contains: rl__project_lead, rl__safety_manager, rl__quality_manager, rl__security_manager, rl__contributor, rl__committer, rl__infrastructure_tooling_community, rl__process_community, rl__architecture_community
 
-   The platform team is responsible for all artifacts within the platform SEooC. Additionally it is also responsible for the overall process including its support by tooling.
+   The platform team is responsible for all artifacts within the platform SEooC.
+   Additionally it is also responsible for the overall process including its support
+   by tooling.
+   Depending on the platform artifacts, some of them are assigned as codeowner.
 
 .. role:: Delivery Team
    :id: rl__delivery_team
    :status: valid
    :tags: cross_functional
    :contains: rl__safety_manager, rl__quality_manager, rl__security_manager, rl__contributor, rl__committer
 
-   The delivery team is responsible for all artifacts within the Delivery Container SEooCs containing the Dependable Elements. Each Delivery Container has only one responsible team.
-   One of the committers in the team acts as the "Project Manager" and is responsible for planning and reporting.
+   The delivery team is responsible for all artifacts within the Delivery Container
+   SEooCs containing the Dependable Elements. Each Delivery Container has only one
+   responsible team.
+   One of the committers in the team acts as the "Project Manager" and is responsible
+   for planning and reporting.
+   Depending on the delivery container artifacts, some of them are assigned as codeowner.
 
 .. role:: Release Team
    :id: rl__release_team