Skip to content

Commit 8ebc8ff

Browse files
masc2023masc2023
committed
resolve audit findings for problem resolution
Add examples using the new issue template Resolves Deviation_1, _2 and _3 Resolves: #86
1 parent 45209da commit 8ebc8ff

3 files changed

Lines changed: 216 additions & 73 deletions

File tree

‎process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst‎

Lines changed: 146 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -30,8 +30,13 @@ The detailed implementation of the Problem Resolution for the project shall be d
3030
Templates
3131
---------
3232

33-
To create problem reports, the project shall provide the following template: :need:`[[title]]<gd_temp__problem__template>`.
34-
An example template for the issue trackings system GitHub can be found here: (to be updated later)
33+
To create problem reports, the project shall provide the content of the following template
34+
in project's selected Issue Tracking System: :need:`[[title]]<gd_temp__problem__template>`.
35+
36+
.. note::
37+
An example template for the Issue Tracking System in GitHub (`GitHub Issues <https://github.com/features/issues>`_)
38+
can be found here:
39+
`Issue Template Bugfix <https://github.com/eclipse-score/process_description/blob/main/.github/ISSUE_TEMPLATE/1-bugfix.yml>`_
3540

3641
Attributes
3742
----------
@@ -85,18 +90,71 @@ This section describes in detail which steps need to be performed for a Problem
8590
Create Problem Report
8691
---------------------
8792

88-
:need:`[[title]] <rl__contributor>` (as author) creates the Problem Report in the defined Issue
89-
Tracking System based on the provided template.
90-
It is expected, that the UID will be provided by the Issue Tracking System.
93+
:need:`[[title]] <rl__contributor>` (as author, submitter, reporter) creates the Problem
94+
Report in the defined Issue Tracking System of the project based on the content of the
95+
provided template:
96+
:need:`[[title]]<gd_temp__problem__template>`.
97+
98+
It is expected that the select Issue Tracking system supports template definition. Best
99+
practice is to define a template with the required content, so that it can be copied
100+
from the different users.
101+
102+
.. note::
103+
For the Issue Tracking System in GitHub, there is a template created, which can be
104+
be found here:
105+
`Issue Template Bugfix <https://github.com/eclipse-score/process_description/blob/main/.github/ISSUE_TEMPLATE/1-bugfix.yml>`_
106+
107+
.. note::
108+
A Problem Report Example based on that template is here:
109+
`Example Problem Report <https://github.com/eclipse-score/process_description/issues/124>`_
110+
111+
.. note::
112+
A Problem Report Example 2 based on that template is here:
113+
`Example Problem Report 2 <https://github.com/eclipse-score/process_description/issues/126>`_
114+
115+
It is expected, that the UID will be provided automatically by the Issue Tracking System.
116+
117+
It is expected, that the status of the problem report is set to "open" automatically.
118+
As long as the content is updated, the status of the Problem is kept "open".
119+
120+
It is expected, that the problem submitter will be set automatically by the Issue
121+
Tracking System.
91122

92123
The title of the Problem Report should reflect the topic accordingly.
93124

94125
The description should reflect the problem root cause and impact in detail.
95126

96-
Copy therefore the :need:`Problem Template <gd_temp__problem__template>` into the created Problem
97-
Report (Issue Tracking System).
127+
If applicable affected parties should be notified.
98128

99-
Set the status of the Problem to "open", when ready to review and analyze set to "in review".
129+
Further supporting information should ge given, especially how to reproduce the problem,
130+
and what is the error occurrence rate?
131+
132+
If the problem affects safety or security it should be stated explicitly.
133+
If safety is affected, the ASIL classification should be added, if applicable.
134+
135+
The problem should be classified according minor, major, critical or blocker.
136+
137+
The affected version of the release should be documented, where the problem was detected.
138+
139+
.. note::
140+
| For the Problem Report Example:
141+
| * The UID is provided by the Issue Tracking System as: **#124**
142+
| * The status of the issue is provided by the Issue Tracking System as: **Open**
143+
| * The submitter is provided by the Issue Tracking System as: **masc2023**
144+
| * The title contains the main root cause, missing safety/security attribute
145+
| * The descriptions has a section for the **Root cause** and **Impact**
146+
| * The description has a section for notification: **Notification required?**
147+
| * Further supporting information is added as the link to the official feature request template which makes it reproducible
148+
| * Checkboxes are selected to highlight, that Safety and Security is affected, no further classification, as the project is defined as ASIL B
149+
| * The problem classification is provided as minor
150+
| * The affected version is provided: *0.5*
151+
152+
When ready to review and to analyze, the author sets the status to "in review" manually.
153+
154+
.. note::
155+
| For the Problem Report Example:
156+
| * The "Process Development Community" dashboard is added and the status must be changed to **Todo**
157+
| * The combination of the issue**Open** and **Todo** defines the status **in review**
100158
101159
.. _prm_analyze_problem_report:
102160

@@ -106,22 +164,88 @@ Analyze Problem Report
106164
The projects :need:`[[title]] <rl__committer>` analyzes the problem together with the
107165
:need:`[[title]] <rl__contributor>` and takes a decision for accepting or rejecting it.
108166

109-
If accepted, the status is set to "in implementation" and :need:`[[title]] <rl__contributor>`
110-
can start with the initiation of the Problem Resolution, otherwise the status is set to "rejected".
167+
The analysis will start by reviewing all the information given during the creation of the
168+
problem report. All topics are revisited and checked for correctness, completeness and
169+
consistency.
170+
171+
If required, the information is updated accordingly.
172+
173+
If accepted, the stakeholder of the problem and the expected release, where the problem
174+
should be closed, shall be defined. In addition the corresponding milestone should be set.
175+
176+
If applicable, the features affected should be identified too.
177+
178+
The description shall reflect the result of the analysis.
179+
180+
.. note::
181+
| For the Problem Report Example:
182+
| * The descriptions has a section for the analysis result: **Accepted**
183+
| * The stakeholder are provided using Assignees field: **masc2023**
184+
| * The expected closure version is provided: *0.5*
185+
| * The "Milestone" is provided: **Release 2.0.0 - Maturity Level 2**
186+
| * Feature identification is not applicable for this example, so no label is set, beside **bug**
187+
188+
If accepted, :need:`[[title]] <rl__contributor>` can start with the initiation of the
189+
Problem Resolution.
111190

112191
The author has the freedom to cancel it at any time by setting the status to "rejected".
113192

193+
.. note::
194+
| For the Problem Report Example:
195+
| * For rejection the status of the issue must be changed to **Closed as not planned**
196+
| * The combination of **Closed as not planned** and any "Process Development Community" status defines the status **rejected**
197+
114198
.. _prm_initiate_problem_resolution:
115199

116200
Initiate and Monitor Problem Resolution
117201
---------------------------------------
118202

119-
:need:`[[title]] <rl__committer>` initiates the resolution of the Problem.
203+
If accepted, The projects :need:`[[title]] <rl__committer>` initiates the resolution of
204+
the Problem together with the :need:`[[title]] <rl__contributor>`.
205+
206+
The description shall reflect the proposed solutions, e.g. measure to resolve the problem.
207+
208+
.. note::
209+
| For the Problem Report Example:
210+
| * The descriptions has a section for the proposed **Solution**
211+
212+
The concrete implementation of the solution may require several additional activities.
213+
In this case additional issues may created and linked to the Problem Report.
120214

121-
Therefore further activities needs to be planned and linked to the Problem Report.
215+
.. note::
216+
| For the Problem Report Example:
217+
| * The **Create sub-issue** should be used to create further linked issues.
218+
219+
Minimal a Pull Request is sufficient to resolve the problem, which shall be linked
220+
to the Problem Report. It is expected, that the status of the Pull Request is set to
221+
"draft" or "open" automatically.
222+
223+
When ready to implement, the author sets the status to "in implementation" manually.
224+
225+
.. note::
226+
| For the Problem Report Example:
227+
| * The "Process Development Community" status must be changed to **In Progress**
228+
| * The linked Pull Request status is either "Draft" or "Open"
229+
| * 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**
230+
231+
.. note::
232+
| For the Problem Report Example:
233+
| * The **Development** section should be used to link to an pull request
234+
| * The **Create a branch** action may used to create automatically a linked pull request
235+
| For the Problem Report Example 2:
236+
| * The **Create a branch** action was used to create a automatically linked Pull Request
237+
| * The automatically created branch name reflects the issue UID and the title as
238+
| * **126-bug-stkh_req__archdes_example_req-has-no-content**
122239
123240
During the resolution the responsible lead :need:`[[title]] <rl__technical_lead>` or
124-
:need:`[[title]] <rl__module_lead>` reports regularly the status to the affected projects teams.
241+
:need:`[[title]] <rl__module_lead>` reports regularly the status to the affected
242+
projects teams.
243+
244+
Escalations topics should be documented in the description, if possible.
245+
246+
.. note::
247+
| For the Problem Report Example and Example 2:
248+
| * Their is no escalation topic documented
125249
126250
The author has the freedom to cancel it at any time by setting the status to "rejected".
127251

@@ -136,6 +260,15 @@ the problem, until they are closed.
136260
:need:`[[title]] <rl__committer>` checks finally if the problem Resolution is sufficient before
137261
the status is finally closed.
138262
To check, if it is sufficient, :need:`Problem Checklist <gd_chklst__problem__cr_review>` may used.
263+
Further the effectiveness of the implemented measure is confirmed and the availability
264+
of the required reports, as verification results, if applicable.
265+
266+
When confirmed, the author sets the status to "closed" manually, if not done automatically.
267+
268+
.. note::
269+
| For the Problem Report Example 2:
270+
| * The status of the issue is provided by the Issue Tracking System as: **Closed**
271+
| * The combination of **Closed** and any "Process Development Community" status **Done** and the Pull Request status **Merged** defines the status **closed**
139272
140273
:need:`[[title]] <rl__committer>` has the freedom to reject it at any time by setting the status
141274
to "reject".

‎process/process_areas/problem_resolution/guidance/problem_resolution_template.rst‎

Lines changed: 50 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -22,31 +22,27 @@ Problem Report Template
2222
:status: draft
2323
: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,
2424

25-
Will be reworked, after this PR with ISSUE_TEMPLATES is merged
25+
This template defines the content to be implemented in the selected Issue Tracking System
26+
of the project.
27+
2628

2729
Problem status
2830
--------------
2931
[“open”, “in review”, “in implementation”, “closed”, “rejected”]
3032

31-
If possible, use for problem status the properties of the selected Issue Tracking System.
32-
(Update here with example from GitHub, after this PR is merged)
33-
3433
| (to be filled out during :need:`wf__problem__create_pr`)
3534
| (to be updated during :need:`wf__problem__analyze_pr`)
3635
| (to be updated during :need:`wf__problem__initiate_monitor_pr`)
36+
| (to be updated during :need:`wf__problem__close_pr`)
3737
3838
Problem submitter
3939
-----------------
4040
[Who is the reporter of the problem?]
4141

42-
If possible, use for problem submitter the properties of the selected Issue Tracking System
43-
(for implementation see here: to be update with Example later)
44-
4542
(to be filled out during :need:`wf__problem__create_pr`)
4643

4744
Problem description
4845
-------------------
49-
5046
[What is the problem?]
5147

5248
| Determine the cause of the problem, if possible.
@@ -58,52 +54,37 @@ Problem description
5854
5955
Problem supporting information
6056
------------------------------
61-
6257
[How to reproduce the problem?]
6358

64-
(to be filled out during :need:`wf__problem__create_pr`)
65-
66-
Problem analysis results
67-
------------------------
68-
69-
[What is the problem analysis result?]
70-
71-
| Especially document rejection Reason
72-
| Determine the safety/security impact, if applicable
73-
74-
(to be filled out during :need:`wf__problem__analyze_pr`)
75-
76-
Problem stakeholder
77-
-------------------
59+
| Add additional information, e.g.
60+
| add which operational state the problem occurred?
61+
| observations, screenshots, debug traces, etc.
7862
79-
[What are the potential stakeholder to resolve the problem?]
63+
[Error occurrence rate?]
8064

81-
Add affected feature, if possible
65+
| Select one [None | Single Event | Sporadic | Highly Intermittent | Reproducible]
8266
83-
If possible, use for problem stakeholder the properties of the selected Issue Tracking System
84-
(Update here with example from GitHub, after this PR is merged)
85-
86-
(to be filled out during :need:`wf__problem__create_pr`)
67+
| (to be filled out during :need:`wf__problem__create_pr`)
68+
| (to be updated during :need:`wf__problem__analyze_pr`)
8769
8870
Problem category
8971
----------------
90-
9172
[Safety affected, Security affected]
9273

93-
* Problems relating to requirements, design, ore code found by user of the platform.
74+
Safety, Security: Additional qualifier to highlight, if safety or security is affected
75+
76+
* Problems relating to requirements, architecture, implementation or code found by user of the platform.
9477
* Problems found by contributor based on component, feature or platform integration tests.
9578
* Problems or gaps found by Quality Management activities as defined in the Quality Management Plan.
9679

97-
Safety, Security: Additional qualifier to highlight, if safety or security is affected
98-
99-
If possible, use for problem category the properties of the selected Issue Tracking System
100-
(Update here with example from GitHub, after this PR is merged)
80+
In addition to the category Safety affected, the ASIL classification may added in the
81+
documentation, if applicable.
10182

102-
(to be filled out during :need:`wf__problem__create_pr`)
83+
| (to be filled out during :need:`wf__problem__create_pr`)
84+
| (to be updated during :need:`wf__problem__analyze_pr`)
10385
10486
Problem classification
10587
----------------------
106-
10788
[minor, major, critical, blocker]
10889

10990
Classify the problem severity
@@ -141,26 +122,50 @@ Determine if Urgent resolution is required? (yes, no, only valid for critical, b
141122
| (to be filled out during :need:`wf__problem__create_pr`)
142123
| (to be updated during :need:`wf__problem__analyze_pr`)
143124
144-
Problem expected closure date
145-
-----------------------------
125+
Problem affected version
126+
------------------------
127+
[What version of the release is affected?]
146128

147-
[Milestone when the problem should be resolved]
129+
Document the version of the release where the problem was detected.
148130

149-
If possible, use for problem closure date the properties of the selected Issue Tracking System
150-
(Update here with example from GitHub, after this PR is merged)
131+
Add further versions, if applicable during analysis activities.
151132

152-
(to be filled out during :need:`wf__problem__create_pr`)
133+
| (to be filled out during :need:`wf__problem__create_pr`)
134+
| (to be updated during :need:`wf__problem__analyze_pr`)
135+
136+
Problem analysis results
137+
------------------------
138+
[What is the problem analysis result? Accepted or Rejected?]
139+
140+
| Especially document rejection Reason, if applicable
141+
142+
(to be filled out during :need:`wf__problem__analyze_pr`)
143+
144+
Problem stakeholder
145+
-------------------
146+
[What are the potential stakeholder to resolve the problem?]
147+
148+
Add affected features, if applicable
149+
150+
(to be filled out during :need:`wf__problem__analyze_pr`)
151+
152+
Problem expected closure version
153+
--------------------------------
154+
[Version when the problem should be resolved]
155+
156+
[Milestone when the problem should be resolved]
157+
158+
(to be filled out during :need:`wf__problem__analyze_pr`)
153159

154160
Problem solutions
155161
-----------------
156-
157162
[What are measures to solve the problem?]
158163

159164
Specify the measures to resolve the problem, based on a rationale
160165

161166
Verify the effectiveness of the implemented measure
162167

163-
Report the results of the verification
168+
Report the results of the verification, if applicable
164169

165170
Are all arguments convincing
166171

@@ -169,7 +174,6 @@ Are all arguments convincing
169174
170175
Problem escalations
171176
-------------------
172-
173177
[Document escalation activities?]
174178

175179
| (to be filled out during :need:`wf__problem__initiate_monitor_pr`)

0 commit comments

Comments
 (0)