diff --git a/.github/ISSUE_TEMPLATE/1-bugfix.yml b/.github/ISSUE_TEMPLATE/1-bugfix.yml index ee16ca0ea4..d95873f781 100644 --- a/.github/ISSUE_TEMPLATE/1-bugfix.yml +++ b/.github/ISSUE_TEMPLATE/1-bugfix.yml @@ -22,7 +22,25 @@ body: - type: textarea attributes: label: Description - description: Short Description of the Bug + description: | + Description of the Bug + Root cause / Impact / Notification required? + validations: + required: true + - type: textarea + attributes: + label: Analysis results + description: | + Documentation of the analysis results + Link to Pull Request containing the results + validations: + required: true + - type: textarea + attributes: + label: Solution + description: | + Documentation of the solution + Link to Pull Request containing the solution validations: required: true - type: dropdown @@ -60,6 +78,7 @@ body: attributes: label: Affected Version options: + - pre-0.5 - 0.5 - 1.0 default: 0 @@ -80,3 +99,9 @@ body: options: - label: Safety Related - label: Security Related + - type: textarea + attributes: + label: ASIL classification + description: Add ASIL classification, e.g. ASIL_B or ASIL_D + validations: + required: false 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 ecf4155543..425d9d736b 100644 --- a/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst +++ b/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst @@ -30,8 +30,13 @@ The detailed implementation of the Problem Resolution for the project shall be d Templates --------- -To create problem reports, the project shall provide the following template: :need:`[[title]]`. -An example template for the issue trackings system GitHub can be found here: (to be updated later) +To create problem reports, the project shall provide the content of the following template +in project's selected Issue Tracking System: :need:`[[title]]`. + +.. note:: + An example template for the Issue Tracking System in GitHub (`GitHub Issues `_) + can be found here: + `Issue Template Bugfix `_ Attributes ---------- @@ -85,18 +90,71 @@ This section describes in detail which steps need to be performed for a Problem Create Problem Report --------------------- -:need:`[[title]] ` (as author) creates the Problem Report in the defined Issue -Tracking System based on the provided template. -It is expected, that the UID will be provided by the Issue Tracking System. +:need:`[[title]] ` (as author, submitter, reporter) creates the Problem +Report in the defined Issue Tracking System of the project based on the content of the +provided template: +:need:`[[title]]`. + +It is expected that the select Issue Tracking system supports template definition. Best +practice is to define a template with the required content, so that it can be copied +from the different users. + +.. note:: + For the Issue Tracking System in GitHub, there is a template created, which can be + be found here: + `Issue Template Bugfix `_ + +.. note:: + A Problem Report Example based on that template is here: + `Example Problem Report `_ + +.. note:: + A Problem Report Example 2 based on that template is here: + `Example Problem Report 2 `_ + +It is expected, that the UID will be provided automatically by the Issue Tracking System. + +It is expected, that the status of the problem report is set to "open" automatically. +As long as the content is updated, the status of the Problem is kept "open". + +It is expected, that the problem submitter will be set automatically by the Issue +Tracking System. The title of the Problem Report should reflect the topic accordingly. The description should reflect the problem root cause and impact in detail. -Copy therefore the :need:`Problem Template ` into the created Problem -Report (Issue Tracking System). +If applicable affected parties should be notified. -Set the status of the Problem to "open", when ready to review and analyze set to "in review". +Further supporting information should ge given, especially how to reproduce the problem, +and what is the error occurrence rate? + +If the problem affects safety or security it should be stated explicitly. +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. + +.. note:: + | For the Problem Report Example: + | * The UID is provided by the Issue Tracking System as: **#124** + | * 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 + | * The descriptions has a section for the **Root cause** and **Impact** + | * The description has a section for notification: **Notification required?** + | * 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* + +When ready to review and to analyze, the author sets the status to "in review" manually. + +.. note:: + | For the Problem Report Example: + | * The "Process Development Community" dashboard is added and the status must be changed to **Todo** + | * The combination of the issue**Open** and **Todo** defines the status **in review** .. _prm_analyze_problem_report: @@ -106,22 +164,88 @@ Analyze Problem Report The projects :need:`[[title]] ` analyzes the problem together with the :need:`[[title]] ` and takes a decision for accepting or rejecting it. -If accepted, the status is set to "in implementation" and :need:`[[title]] ` -can start with the initiation of the Problem Resolution, otherwise the status is set to "rejected". +The analysis will start by reviewing all the information given during the creation of the +problem report. All topics are revisited and checked for correctness, completeness and +consistency. + +If required, the information is updated accordingly. + +If accepted, the stakeholder of the problem and the expected release, where the problem +should be closed, shall be defined. Optionally, the corresponding milestone can be set. + +If applicable, the features affected should be identified too. + +The description shall reflect the result of the analysis. + +.. 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** + | * Feature identification is not applicable for this example, so no label is set, beside **bug** + +If accepted, :need:`[[title]] ` can start with the initiation of the +Problem Resolution. The author has the freedom to cancel it at any time by setting the status to "rejected". +.. note:: + | For the Problem Report Example: + | * For rejection the status of the issue must be changed to **Closed as not planned** + | * The combination of **Closed as not planned** and any "Process Development Community" status defines the status **rejected** + .. _prm_initiate_problem_resolution: Initiate and Monitor Problem Resolution --------------------------------------- -:need:`[[title]] ` initiates the resolution of the Problem. +If accepted, the projects :need:`[[title]] ` initiates the resolution of +the problem together with the :need:`[[title]] `. + +The description shall reflect the proposed solutions, e.g. measure to resolve the problem. + +.. note:: + | For the Problem Report Example: + | * The descriptions has a section for the proposed **Solution** + +The concrete implementation of the solution may require several additional activities. +In this case additional issues may created and linked to the Problem Report. -Therefore further activities needs to be planned and linked to the Problem Report. +.. note:: + | For the Problem Report Example: + | * The **Create sub-issue** should be used to create further linked issues. + +Minimal a Pull Request is sufficient to resolve the problem, which shall be linked +to the Problem Report. It is expected, that the status of the Pull Request is set to +"draft" or "open" automatically. + +When ready to implement, the author sets the status to "in implementation" manually. + +.. note:: + | For the Problem Report Example: + | * The "Process Development Community" status must be changed to **In Progress** + | * The linked Pull Request status is either "Draft" or "Open" + | * The combination of **Open** and any "Process Development Community" status **In Progress** and the Pull Request status **Draft** or **Open** defines the status **in implementation** + +.. note:: + | For the Problem Report Example: + | * The **Development** section should be used to link to an pull request + | * The **Create a branch** action may used to create automatically a linked pull request + | For the Problem Report Example 2: + | * The **Create a branch** action was used to create a automatically linked Pull Request + | * The automatically created branch name reflects the issue UID and the title as + | * **126-bug-stkh_req__archdes_example_req-has-no-content** During the resolution the responsible lead :need:`[[title]] ` or -:need:`[[title]] ` reports regularly the status to the affected projects teams. +:need:`[[title]] ` reports regularly the status to the affected +projects teams. + +Escalations topics should be documented in the description, if possible. + +.. note:: + | For the Problem Report Example and Example 2: + | * Their is no escalation topic documented The author has the freedom to cancel it at any time by setting the status to "rejected". @@ -136,6 +260,15 @@ the problem, until they are closed. :need:`[[title]] ` checks finally if the problem Resolution is sufficient before the status is finally closed. To check, if it is sufficient, :need:`Problem Checklist ` may used. +Further the effectiveness of the implemented measure is confirmed and the availability +of the required reports, as verification results, if applicable. + +When confirmed, the author sets the status to "closed" manually, if not done automatically. + +.. note:: + | For the Problem Report Example 2: + | * The status of the issue is provided by the Issue Tracking System as: **Closed** + | * The combination of **Closed** and any "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". diff --git a/process/process_areas/problem_resolution/guidance/problem_resolution_template.rst b/process/process_areas/problem_resolution/guidance/problem_resolution_template.rst index 5c6fd5a717..606b73e6d7 100644 --- a/process/process_areas/problem_resolution/guidance/problem_resolution_template.rst +++ b/process/process_areas/problem_resolution/guidance/problem_resolution_template.rst @@ -22,31 +22,27 @@ Problem Report Template :status: draft :complies: std_req__aspice_40__SUP-9-BP1, std_req__aspice_40__SUP-9-BP2, std_req__aspice_40__SUP-9-BP3, std_req__aspice_40__SUP-9-BP4, -Will be reworked, after this PR with ISSUE_TEMPLATES is merged +This template defines the content to be implemented in the selected Issue Tracking System +of the project. + Problem status -------------- [“open”, “in review”, “in implementation”, “closed”, “rejected”] -If possible, use for problem status the properties of the selected Issue Tracking System. -(Update here with example from GitHub, after this PR is merged) - | (to be filled out during :need:`wf__problem__create_pr`) | (to be updated during :need:`wf__problem__analyze_pr`) | (to be updated during :need:`wf__problem__initiate_monitor_pr`) +| (to be updated during :need:`wf__problem__close_pr`) Problem submitter ----------------- [Who is the reporter of the problem?] -If possible, use for problem submitter the properties of the selected Issue Tracking System -(for implementation see here: to be update with Example later) - (to be filled out during :need:`wf__problem__create_pr`) Problem description ------------------- - [What is the problem?] | Determine the cause of the problem, if possible. @@ -58,52 +54,36 @@ Problem description Problem supporting information ------------------------------ - [How to reproduce the problem?] -(to be filled out during :need:`wf__problem__create_pr`) - -Problem analysis results ------------------------- - -[What is the problem analysis result?] - -| Especially document rejection Reason -| Determine the safety/security impact, if applicable - -(to be filled out during :need:`wf__problem__analyze_pr`) +| Add additional information, e.g. +| add which operational state the problem occurred? +| observations, screenshots, debug traces, etc. -Problem stakeholder -------------------- +[Error occurrence rate?] -[What are the potential stakeholder to resolve the problem?] +| Select one [None | Single Event | Sporadic | Highly Intermittent | Reproducible] -Add affected feature, if possible - -If possible, use for problem stakeholder the properties of the selected Issue Tracking System -(Update here with example from GitHub, after this PR is merged) - -(to be filled out during :need:`wf__problem__create_pr`) +| (to be filled out during :need:`wf__problem__create_pr`) +| (to be updated during :need:`wf__problem__analyze_pr`) Problem category ---------------- - [Safety affected, Security affected] -* Problems relating to requirements, design, ore code found by user of the platform. -* Problems found by contributor based on component, feature or platform integration tests. -* Problems or gaps found by Quality Management activities as defined in the Quality Management Plan. +Safety, Security: Additional qualifiers to highlight, if safety or security is affected -Safety, Security: Additional qualifier to highlight, if safety or security is affected +They qualifiers have to be filled. If not filled out, a quality problem is assumed as +default category. -If possible, use for problem category the properties of the selected Issue Tracking System -(Update here with example from GitHub, after this PR is merged) +In addition to the category Safety affected, the ASIL classification may be added in the +documentation, if applicable. -(to be filled out during :need:`wf__problem__create_pr`) +| (to be filled out during :need:`wf__problem__create_pr`) +| (to be updated during :need:`wf__problem__analyze_pr`) Problem classification ---------------------- - [minor, major, critical, blocker] Classify the problem severity @@ -141,26 +121,54 @@ Determine if Urgent resolution is required? (yes, no, only valid for critical, b | (to be filled out during :need:`wf__problem__create_pr`) | (to be updated during :need:`wf__problem__analyze_pr`) -Problem expected closure date ------------------------------ +Problem affected version +------------------------ +[What version of the release is affected?] -[Milestone when the problem should be resolved] +Document the version of the release where the problem was detected. -If possible, use for problem closure date the properties of the selected Issue Tracking System -(Update here with example from GitHub, after this PR is merged) +| (to be filled out during :need:`wf__problem__create_pr`) -(to be filled out during :need:`wf__problem__create_pr`) +Problem analysis results +------------------------ +[What is the problem analysis result? Accepted or Rejected?] + +| Especially document rejection reason, if applicable + +In addition the safety/security relevance is confirmed or disconfirmed by safety/Security +Experts. + +| Especially document disconfirming reason, if applicable + +(to be filled out during :need:`wf__problem__analyze_pr`) + +Problem stakeholder +------------------- +[What are the potential stakeholder to resolve the problem?] + +Add affected features, if applicable + +(to be filled out during :need:`wf__problem__analyze_pr`) + +Problem expected closure version +-------------------------------- +[Version when the problem should be resolved] + +Document the version of the release where the problem should be resolved. + +Optionally add a concrete Milestone, if applicable. + +(to be filled out during :need:`wf__problem__analyze_pr`) Problem solutions ----------------- - [What are measures to solve the problem?] Specify the measures to resolve the problem, based on a rationale Verify the effectiveness of the implemented measure -Report the results of the verification +Report the results of the verification, if applicable Are all arguments convincing @@ -169,8 +177,7 @@ Are all arguments convincing Problem escalations ------------------- - -[Document escalation activities?] +[Document escalation activities, if applicable] | (to be filled out during :need:`wf__problem__initiate_monitor_pr`) | (to be updated during :need:`wf__problem__close_pr`) diff --git a/process/process_areas/problem_resolution/problem_resolution_concept.rst b/process/process_areas/problem_resolution/problem_resolution_concept.rst index d862ba5f48..17d8f19a8e 100644 --- a/process/process_areas/problem_resolution/problem_resolution_concept.rst +++ b/process/process_areas/problem_resolution/problem_resolution_concept.rst @@ -44,12 +44,24 @@ Stakeholders for the Problem Report #. :need:`Contributor ` - * Contributes features and components to grow the project content + * In general contributes features and components to grow the project content + * Reports problems, analyze problems, implement problem resolutions #. :need:`Committer ` - * Verifies that the contribution fulfills the project policies - * Approves the contribution + * Verifies that the contribution including problem resolutions fulfills the project policies + * Approves all problem resolution activities besides problem closing + * Is responsible to initiate the the closure of the problem reported + +#. :need:`Technical Lead `, :need:`Module Lead ` + + * Supports all problem resolution activities + * Approves the closing of the problem resolution + +#. :need:`Safety Manager `, :need:`Security Manager `, :need:`Quality Manager ` + + * Supports all problem resolution activities + Standard Requirements ===================== @@ -58,15 +70,7 @@ Also requirements of standards need to be taken into consideration: * ISO 26262 * ASPICE -* ISO SAE 21434 - -Problem Report Categories -************************* - -User: Problems relating to requirements, architecture, implementation, or code found by user of the platform. - -Bug: Problems found by contributor based on component, feature or platform integration tests including verification and quality assurance activities. - +* ISO/SAE 21434 .. _prm_attributes: @@ -83,15 +87,17 @@ Activities for Problem Resolution Creation of the Problem Report ============================== -Use the :ref:`Problem Report Template ` to create the Problem Report. +Use the content :ref:`Problem Report Template ` to create the Problem Report. In case safety or security is affected, in addition the impact analysis template : :ref:`Impact Analysis Template ` can be used to detail out the impact on safety/security as part of the description. +(needs to be updated) + .. _prm_analysis: -Anaylsis of the Problem Report +Analysis of the Problem Report ============================== Based on the analysis results decision about the acceptance or rejection must be taken diff --git a/process/process_areas/problem_resolution/problem_resolution_getstrt.rst b/process/process_areas/problem_resolution/problem_resolution_getstrt.rst index 8194d85851..736a8affd7 100644 --- a/process/process_areas/problem_resolution/problem_resolution_getstrt.rst +++ b/process/process_areas/problem_resolution/problem_resolution_getstrt.rst @@ -24,6 +24,12 @@ This document describes the steps to create a problem report, and further to ana resolve, and to control the problem until closure. Where a problem is defined as a deviation of an expected result. +Examples for problem origins: + +* Deviations relating to requirements, architecture, implementation or code found by user of the platform. +* Deviations found by contributor based on component, feature or platform integration tests. +* Deviations found by Quality Management activities as defined in the Quality Management Plan. + Therefore guidelines :need:`gd_temp__problem__template`, :need:`gd_guidl__problem__problem` and a :need:`doc_concept__problem__process` are available.