Skip to content

fix audit findings action_78 #617

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
masc2023 wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

fix audit findings action_78 #617

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a9f3fc1
fix audit findings action_78
masc2023 Mar 21, 2026
7545161
fix review findings
masc2023 Mar 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 38 additions & 20 deletions process/process_areas/change_management/change_management_workflow.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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
Copy link
Contributor

@aschemmel-tech aschemmel-tech Mar 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rl__platform_team mentioned in responsible/approved - what do they do?

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
Expand Down
27 changes: 22 additions & 5 deletions process/roles/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down
Loading