[Starlingx-discuss] bug severity and priority

Saul Wold sgw at linux.intel.com
Wed Jul 10 20:22:32 UTC 2019



On 7/10/19 10:38 AM, Zvonar, Bill wrote:
> Hi Cindy,
> 
> Thanks for sending this, I think this gives us something to start the discussion.
> 
+1, we went through a very similar community process with the Yocto 
Project early on, everyone has their ideas of Priority/Severity and who 
sets what and when.  We will work through this.

> However we decide to align on severity/priority (I'll comment on that more later, need to think about it more), I think we need to be careful before we move all mediums to 3.0, it may be too much of a Gordian knot solution.
> 
> I think we need to assess the mediums (as Yong suggested earlier) to say why they should or should not be in 2.0.  I also think this may help us sort out what our gating criteria are.
> 
I agree, we need to take a measured approach to the existing mediums and 
determine if they are truly 2.0 gating, in which case elevate them, the 
rest could/should be marked for 3.0.

As I mentioned on the phone, having a burn-down chart for the Critical 
(1) and Highs (16) currently might help, as we should be approaching 0 
on these existing ones entering RC1.

Sau!

> Bill...
> 
> -----Original Message-----
> From: Xie, Cindy <cindy.xie at intel.com>
> Sent: Wednesday, July 10, 2019 10:42 AM
> To: starlingx-discuss at lists.starlingx.io; Zvonar, Bill <Bill.Zvonar at windriver.com>; Khalil, Ghada <Ghada.Khalil at windriver.com>
> Subject: bug severity and priority
> 
> Bill/Ghada,
> I am sending out my definition of bug severity and priority:
> 
> Bug Exposure or Severity	Definition
> 1- Critical	Product or key feature is not usable for intended purpose.
> 2- High		Product or key feature is not reliably usable for intended purpose or use is significantly impaired
> 3 - Medium	Product or key feature is usable provided by a workaround
> 4 - Low		Tolerable impact to user experience with minimal service and support costs
> 	
> Bug Priority	Definition
> P1 - Stopper	Resolution of this defect takes precedence over other defects and most other development activities. This level is used to focus maximum development team resources to resolve a defect in the shortest possible timeframe.
> P2 - High	Resolution of the defect has precedence over resolving other defects with lesser classifications of priority.  The urgency to fix a P2 priority  defect is imminent. - P2 priority defects are intended to be resolved by the next planned external release of the software.
> P3 - Medium	Resolution of the defect has precedence over resolving other defects with lesser classifications of priority.  - P3 priority defects must have a planned timeframe for a verified resolution.
> P4 - Low	Resolution of the defect has least urgency to resolve, P4 priority defects may or may not have plans to resolve.
> 
> Let's discuss this and agree how we'd like to use them. My suggestion for current "Medium" is to we can mark them as "stx.3.0" and then in the beginning of stx.3, they can move Priority to "high" due to the fact they want to get them fixed in 3.0.
> 
> But the bug severity should never change because they are standard.
> 
> Thx. - cindy
> 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 



More information about the Starlingx-discuss mailing list