Add Severity Levels and response time

Signed-off-by: Luca Zizolfi luca.zizolfi@kalpa.it

Closed: oniro#589

contributing/bug_policy.rst

@@ -64,29 +64,39 @@ Please refer to the CVE Process for details.
 If the bug is confirmed as a bug, the developer will assign bug severity:
 critical, normal, minor or low.
 
-.. note::
-
-    *Critical* severity bugs make a feature unusable, cause a major data loss or
-    hardware breakage. There is no workaround, or a complex one.
-    *Normal* severity bugs make a feature hard to use, but there is a workaround
-    (including another feature to use instead of the desired one).
-    *Minor* severity bugs cause a loss of non-critical feature (like missing or
-    incorrect logging).
-    *Low* severity bugs cause minor inconveniences (like a typo in the user
-    interface or in the documentation).
+Severity Levels
+^^^^^^^^^^^^^^^^
+
+| **Critical - Response time: 3 working days.**
+| Severity bugs make a feature unusable, cause a major data loss or
+  hardware breakage. There is no workaround, or a complex one.
+| 
+| **Normal - Response time: 5 working days.**
+| Severity bugs make a feature hard to use, but there is a workaround
+   (including another feature to use instead of the desired one). 
+|
+| **Minor - Response time: 10 working days.** 
+| Severity bugs cause a loss of non-critical feature (like missing or
+    incorrect logging). 
+|
+| **Low - Response time: Best effort.**
+| Severity bugs cause minor inconveniences (like a typo in the user
+   interface or in the documentation). 
+
+For *Response time* we intend the time between the opening and the taking charge of the issue.
 
 The bug can originate in a package developed by the project, or from one we use
 from an upstream source. The process of handling a bug report will change
 between those two cases:
 
 When the Issue is in the Code Developed by the Project
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------------------------------------------
 
 In the case where the bug originates in the code directly maintained by the
 Project, the bug is handled directly in the bug tracker.
 
 When the Issue Originates from Upstream Code
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------------------------
 
 If the issue was identified in upstream code, we report an upstream issue in
 a way appropriate to the upstream project. We store the reference to the upstream

[Pavel Zhukov]

3 working days for critical issue maybe too long from the users point of view. And way to long from the business point of view.

CC @dricci783

[Zygmunt Krynicki]

Do we have any calculations that back any of the numbers here? Can we even offer a 3 day response time on critical bugs?

[Pavel Zhukov]

"Best effort" is slippery slope [1] [2] We should use something like "commercially reasonable effort"

[1] https://definitions.uslegal.com/b/best-efforts/#:~:text=Best%20efforts%20is%20a%20contractual,ability%20to%20meet%20the%20goal. [2] https://www.lexology.com/library/detail.aspx?g=6a4c20dc-594d-4756-b710-7a2dc213e8c0

[Luca Favaretto]

I read the articles and IMHO "reasonable effort" fit better for our cause than "commercially reasonable effort"