From a9f3fc11382f8dfd2c3360fb14941d8c94d0b2eb Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Sat, 21 Mar 2026 06:44:50 +0100 Subject: [PATCH 1/3] fix audit findings action_78 Action_78: It shall be defined who evaluates and accepts/ rejects Change Requests for Feature Changes and for Component Changes. Resolves: #567 --- .../change_management_workflow.rst | 41 ++++++++++--------- process/roles/index.rst | 37 +++++++++++++++-- 2 files changed, 54 insertions(+), 24 deletions(-) diff --git a/process/process_areas/change_management/change_management_workflow.rst b/process/process_areas/change_management/change_management_workflow.rst index b715eff60f..25783f01b9 100644 --- a/process/process_areas/change_management/change_management_workflow.rst +++ b/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 `. + “open” from the :need:`Architecture Team `. 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 `. 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 ` 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 ` must check the correctness. - The :need:`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 ` 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 ` finally. + by the :need:`Delivery Team ` finally, especially the selected + codeowners of the team must approve. - Otherwise the :need:`Committer ` keeps the status "in implementation". + Otherwise the :need:`Delivery Team ` keeps the status "in implementation". .. needextend:: docname is not None and "process_areas/change_management" in docname :+tags: change_management diff --git a/process/roles/index.rst b/process/roles/index.rst index ab751b3dc9..c587318086 100644 --- a/process/roles/index.rst +++ b/process/roles/index.rst @@ -108,6 +108,28 @@ 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. + +.. 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. + +About Features + +Feature Request issue template + +Component Request + +A Component Request represents an independent work package used to describe modifications inside a Feature, either adding new components or modifying existing ones. Component Request work packages can be linked to other work packages, but they must not be treated as parent work packages. They shall be discussed with Architecture Community and the issues are owned by a Team and are part of the Team`s main repository.. + + 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 .. role:: Project Security Team @@ -126,9 +148,12 @@ 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 @@ -136,8 +161,12 @@ Project Teams :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 From 7545161dbbd68248a4284c62d1a04fd3882258ca Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Mon, 23 Mar 2026 14:01:12 +0100 Subject: [PATCH 2/3] fix review findings --- .../change_management_workflow.rst | 27 +++++++++++++++---- process/roles/index.rst | 12 --------- 2 files changed, 22 insertions(+), 17 deletions(-) diff --git a/process/process_areas/change_management/change_management_workflow.rst b/process/process_areas/change_management/change_management_workflow.rst index 25783f01b9..1d6bbf9da1 100644 --- a/process/process_areas/change_management/change_management_workflow.rst +++ b/process/process_areas/change_management/change_management_workflow.rst @@ -80,11 +80,19 @@ For a detailed explanation of workflows and their role within the process model, 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 ` must check the - correctness. - The :need:`Delivery Team ` may still reject it, thus the status - is set to "rejected". + 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 ` must + check the correctness. + + For component: + Before closing the Change Request, :need:`Delivery Team ` must + check the correctness. + + The responsible team may still reject it, thus the status is set to "rejected". .. workflow:: Close Change Request :id: wf__change_close_cr @@ -100,11 +108,20 @@ For a detailed explanation of workflows and their role within the process model, 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 ` 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:`Delivery Team ` finally, especially the selected codeowners of the team must approve. - Otherwise the :need:`Delivery Team ` 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 diff --git a/process/roles/index.rst b/process/roles/index.rst index c587318086..c6355f959f 100644 --- a/process/roles/index.rst +++ b/process/roles/index.rst @@ -120,18 +120,6 @@ Project Development Roles the platform. Feature and Components requests, which add new ones or modifications, are in their responsibility. They are aligned with the Project Leads. -About Features - -Feature Request issue template - -Component Request - -A Component Request represents an independent work package used to describe modifications inside a Feature, either adding new components or modifying existing ones. Component Request work packages can be linked to other work packages, but they must not be treated as parent work packages. They shall be discussed with Architecture Community and the issues are owned by a Team and are part of the Team`s main repository.. - - 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 - .. role:: Project Security Team :id: rl__security_team :status: valid From 7abde976f7f04320f8cb0cac50e439c613f960cf Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Thu, 26 Mar 2026 08:20:01 +0100 Subject: [PATCH 3/3] adapted the change requests documents according the new RASIC in the workflows --- .../change_management_concept.rst | 30 +++++++++----- .../change_management_roles.rst | 7 ++-- .../guidance/change_management_guideline.rst | 39 +++++++++++-------- 3 files changed, 45 insertions(+), 31 deletions(-) diff --git a/process/process_areas/change_management/change_management_concept.rst b/process/process_areas/change_management/change_management_concept.rst index 1a2d24c29e..54a957c9ef 100644 --- a/process/process_areas/change_management/change_management_concept.rst +++ b/process/process_areas/change_management/change_management_concept.rst @@ -45,22 +45,30 @@ Stakeholders for the Change Requests #. :need:`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 ` +#. :need:`Architecture Team ` + * 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 ` +#. :need:`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 ` -#. :need:`Safety Manager `, :need:`Security Manager `, :need:`Quality Manager ` + * Is responsible and approves the implementation and the closure of the component change request + +#. :need:`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 `, includes #. :need:`Project Lead ` #. :need:`Safety Manager ` #. :need:`Security Manager ` #. :need:`Quality Manager ` +#. :need:`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 ` until +:need:`Project Lead ` (for feature requests) and the lead of the +:need:`Delivery Team ` (for component requests) until the implementation is completed and confirmed. .. _chm_closing: diff --git a/process/process_areas/change_management/change_management_roles.rst b/process/process_areas/change_management/change_management_roles.rst index 55914f8a7f..1eb37642da 100644 --- a/process/process_areas/change_management/change_management_roles.rst +++ b/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 ` - * :need:`Committer ` + * :need:`Architecture Team ` + * :need:`Platform Team ` * :need:`Project Lead ` - * :need:`Safety Manager ` - * :need:`Security Manager ` - * :need:`Quality Manager ` + * :need:`Delivery Team ` A detailed overview of the responsibility for the steps of the requirement process is listed here: diff --git a/process/process_areas/change_management/guidance/change_management_guideline.rst b/process/process_areas/change_management/guidance/change_management_guideline.rst index 5b63575605..018f6034df 100644 --- a/process/process_areas/change_management/guidance/change_management_guideline.rst +++ b/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. ` - Create Change Request - :need:`[[title]] ` - - :need:`[[title]] ` + - :need:`[[title]] ` * - :ref:`2. ` - Analyze Change Request - - :need:`[[title]] ` + - :need:`[[title]] ` - :need:`[[title]] ` * - :ref:`3. ` - Implement and Monitor Change Request - - :need:`[[title]] ` - - :need:`[[title]] ` + - :need:`[[title]] `, :need:`[[title]] ` + - :need:`[[title]] `, :need:`[[title]] ` * - :ref:`4. ` - Close Change Request - - :need:`[[title]] ` - - :need:`[[title]] ` + - :need:`[[title]] `, :need:`[[title]] ` + - :need:`[[title]] `, :need:`[[title]] ` .. _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]] ` supported by -:need:`[[title]] ` (includes Safety, Security and Quality Manager) analyzes the change -request together with the :need:`[[title]] ` and takes a decision with +:need:`[[title]] ` (includes Safety, Security and Quality Manager) analyzes the change +request together with the :need:`[[title]] ` 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]] ` can start with the implementation of the Change Request. +Depending of feature or component requests, :need:`[[title]] ` or +:need:`Delivery Team ` will be empowered for the implementation, +which will contain the :need:`[[title]] `. 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]] ` initiates the implementation -of the change together with the :need:`[[title]] `. +If accepted, the either the :need:`[[title]] ` (feature) or +:need:`Delivery Team ` (component) initiates the implementation +of the change. The description may reflect details for the implementation. @@ -242,10 +246,12 @@ 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]] ` +or the assigned lead of the :need:`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]] ` as an author has the freedom to cancel the +change request at any time by setting the status to "rejected". .. _chm_close_change_request: @@ -253,17 +259,17 @@ The author has the freedom to cancel the change request at any time by setting t Close Change Request -------------------- -During implementation the :need:`[[title]] ` monitors all activities linked to +During implementation the responsible team (:need:`[[title]] ` +or :need:`Delivery Team `) monitors all activities linked to the change, until they are closed. -:need:`[[title]] ` 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 ` 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]] ` -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]] ` 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 =========