From 233db1a0e8f13b869e8054be60069a8050f23b97 Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Sat, 21 Mar 2026 06:44:50 +0100 Subject: [PATCH 1/2] 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 e28a8a0525b2886c19955a540bf7917d7abce4f7 Mon Sep 17 00:00:00 2001 From: "markus.schu" Date: Mon, 30 Mar 2026 12:09:55 +0200 Subject: [PATCH 2/2] fix audit findings for prm Action_66: Elaborate, what is a topic and what happens if a critical topic is not accepted. Resolves partly: https://github.com/eclipse-score/process_description/issues/557 --- .../guidance/problem_resolution_guideline.rst | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst b/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst index 9229a17969..2e8a3aa88f 100644 --- a/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst +++ b/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst @@ -177,6 +177,26 @@ If applicable, the features affected should be identified too. The description shall reflect the result of the analysis. +Topics to checked (critical topics are marked with *): + +- [*] Is the problem description clear and detailed enough to understand the problem and its impact? +- [*] Is the problem root cause clearly described? +- [*] Is the problem impact clearly described? +- [ ] Is notification of affected parties required? If yes, are the affected parties notified? +- [ ] Are there any proposed solutions provided? +- [ ] Are there any further linked issues or pull requests provided? +- [*] Is the error occurrence rate provided? If yes, is it high enough to accept the problem? +- [*] Is the problem reproducible? +- [ ] Are there any further supporting information provided? +- [*] Is the problem classification correct? +- [*] Is information for the affected version of the release provided? If yes, is it correct? +- [ ] Is the information for the expected closure version provided? If yes, is it correct? +- [*] Is the problem affecting safety or security? If yes, is the classification correct? + +The analysis phase can not be closed, until all critical topics are +clarified and provided in the description. If not, the problem report should be rejected +and closed with the reason "Closed as not planned". + .. note:: | For the Problem Report Example: | * The descriptions has a section for the analysis results: **Accepted**