fix audit findings action_78, action_66, action_68

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

@@ -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 <rl__delivery_team>` must check the
-   correctness.
 
-   The :need:`Delivery Team <rl__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 <rl__platform_team>` must
+   check the correctness.
+
+   For component:
+   Before closing the Change Request, :need:`Delivery Team <rl__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 <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:`Delivery Team <rl__delivery_team>` finally, especially the selected
    codeowners of the team must approve.
 
-   Otherwise the :need:`Delivery Team <rl__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

process/process_areas/change_management/guidance/change_management_guideline.rst

@@ -91,19 +91,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:
@@ -136,7 +136,7 @@ automatically included or copied by the different users.
 
 .. note::
   A Change Request Example based on that template is here:
-  `Example Change Request <https://github.com/eclipse-score/process_description/issues/168>`_
+  `Example Change Request <https://github.com/eclipse-score/process_description/issues/629>`_
 
 It is expected, that
 
@@ -177,8 +177,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
@@ -198,6 +198,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".
 
@@ -212,8 +215,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.
 
@@ -246,28 +250,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:
@@ -276,8 +282,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/process_areas/problem_resolution/guidance/problem_resolution_checklist.rst

@@ -48,45 +48,49 @@ Problem Checklist
         -
 
       * - 3
-        - Does the Problem report has a UID as specified?
+        - Does the Problem report have a UID as specified?
         -
 
       * - 4
-        - Does the Problem report has a title as specified?
+        - Does the Problem report have a title as specified?
         -
 
       * - 5
-        - Does the Problem report has a status as specified?
+        - Does the Problem report have a status as specified?
         -
 
       * - 6
-        - Does the Problem report has a submitter as specified?
+        - Does the Problem report have a submitter as specified?
         -
 
       * - 7
-        - Does the Problem report has a description as specified?
+        - Does the Problem report have a description as specified?
         -
 
       * - 8
-        - Does the Problem report has stakeholder as specified?
+        - Does the Problem report have a stakeholder as specified?
         -
 
       * - 9
-        - Does the Problem report has a category as specified?
+        - Does the Problem report have a category as specified?
         -
 
       * - 10
-        - Does the Problem report has a classification as specified?
+        - Does the Problem report have a classification as specified?
         -
 
       * - 11
-        - Does the Problem report has a expected closure date as specified?
+        - Does the Problem report have the affected release versions as specified?
         -
 
       * - 12
-        - Does the Problem report has the solution measures specified, verified and reported?
+        - Does the Problem report have an expected closure date as specified?
         -
 
       * - 13
+        - Does the Problem report have the solution measures specified, verified and reported?
+        -
+
+      * - 14
         - If the Problem report is not closed and pending solution measures are open, escalated to the :need:`rl__safety_manager` or :need:`rl__security_manager`?
         -

process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst

@@ -106,10 +106,10 @@ from the different users.
 
 .. note::
   A Problem Report Example based on that template is here:
-  `Example Problem Report <https://github.com/eclipse-score/process_description/issues/124>`_
+  `Example Problem Report <https://github.com/eclipse-score/process_description/issues/631>`_
 
 .. note::
-  A Problem Report Example 2 based on that template is here:
+  A Problem Report Example 2 based on an older version template is here:
   `Example Problem Report 2 <https://github.com/eclipse-score/process_description/issues/126>`_
 
 It is expected, that the UID will be provided automatically by the Issue Tracking System.
@@ -134,11 +134,13 @@ If safety is affected, the ASIL classification should be added, if applicable.
 
 The problem should be classified according minor, major, critical or blocker.
 
-The affected version of the release should be documented, where the problem was detected.
+The affected versions of the release should be documented. After detection of the
+problem, checking the affected versions is critical to understand the impact of the
+problem. Thus document the first affected version and the last affected version.
 
 .. note::
   | For the Problem Report Example:
-  | * The UID is provided by the Issue Tracking System as: **#124**
+  | * The UID is provided by the Issue Tracking System as: **#631**
   | * The status of the issue is provided by the Issue Tracking System as: **Open**
   | * The submitter is provided by the Issue Tracking System as: **masc2023**
   | * The title contains the main root cause, missing safety/security attribute
@@ -147,7 +149,8 @@ The affected version of the release should be documented, where the problem was
   | * Further supporting information is added as the link to the official feature request template which makes it reproducible
   | * Checkboxes are selected to highlight, that Safety and Security is affected, no further classification, as the project is defined as ASIL B
   | * The problem classification is provided as minor
-  | * The affected version is provided: *pre-0.5*
+  | * The first affected version is provided: *pre-0.5*
+  | * The last affected version is provided: *0.5*
 
 When ready to review and to analyze, the author sets the status to "in review" manually.
 
@@ -177,12 +180,32 @@ 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 x):
+
+- [x] Is the problem description clear and detailed enough to understand the problem and its impact?
+- [x] Is the problem root cause clearly described?
+- [x] 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?
+- [x] Is the error occurrence rate provided? If yes, is it high enough to accept the problem?
+- [x] Is the problem reproducible?
+- [ ] Are there any further supporting information provided?
+- [x] Is the problem classification correct?
+- [x] 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?
+- [x] 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**
   | * The stakeholder are provided using Assignees field: **masc2023**
-  | * The expected closure version is provided: *0.5*
-  | * The "Milestone" is provided: **Release 2.0.0 - Maturity Level 2**
+  | * The expected fix version is provided: *0.6*
+  | * The "Milestone" is provided: **Release v0.6 - Maturity Level 2**
   | * Feature identification is not applicable for this example, so no label is set, beside **bug**
 
 If accepted, :need:`[[title]] <rl__contributor>` can start with the initiation of the