Fork me on GitHub

Subject:*
Name/Email:*
Message Icon:*
Message:*
url email imgsrc image php hide code quote
SAMPLE
alignleft aligncenter alignright bold italic underline linethrough   


 [more...]
Options:*
 

 

 
View requirements*
Reply No requirement
Confirmation Code*
  The code is case-insensitive  Click the image for a new code. | Maximum attempts: 8
     
Re: Bug Classification in ImpressCMS

by skenow on 2009/11/29 6:30:58

Once we get this a little more refined, we'll update the Bugs page in the wiki and link to it from Trac.
Re: Bug Classification in ImpressCMS

by david on 2009/11/29 3:53:45

Quote:

Can we store a link or a copy somewhere in trac? Maybe on the start screen?



Good idea
Re: Bug Classification in ImpressCMS

by phoenyx on 2009/11/29 3:02:05

Thank you Steve. This makes it almost very clear.

Maybe it's a good idea to put real examples out of trac to this list. It's always one thing to say it in words but other things to have real examples.

Other than that it's good to have this post now because I was told something else a long time ago and therefore might have done some classifications wrong.

Can we store a link or a copy somewhere in trac? Maybe on the start screen?
Re: Bug Classification in ImpressCMS

by david on 2009/11/29 2:38:00

Thank you Steve - a very clear idea of what's what.

When everyone's in agreement - I think we should link to this from trac somehow.
Bug Classification in ImpressCMS

by skenow on 2009/11/28 19:02:01

I've searched through the forums, wiki and email archives for discussions we may have had about our bug severities and I put together the following. What we'll work through in this post is the severities we use, the generally accepted definitions of those severities outside of ImpressCMS and how we might make specific clarifications to them.

We are using a 5-level severity classification system: Critical (highest), Blocker, Major, MInor, Trivial (lowest). Here are the general definitions of these levels.

Blocker
Defects that could (or did) cause disastrous consequences for the system in question. There is no workaround. Issues of this type will be immediately addressed and a new release will result.

Example - critical loss of data, critical loss of system availability, critical loss of security, etc.

Critical
Defects that could (or did) cause very serious consequences for the system in question. Issues of this type will be immediately addressed and a new release will result

Example - A function is severely broken, cannot be used and there is no workaround.

Major
Defects that could (or did) cause significant consequences for the system in question - A defect that needs to be fixed but there is a workaround. Issues of this type will be addressed in the next or a future regular release.

Example 1 - losing data from a serial device during heavy loads.
Example 2 - Function badly broken but workaround exists

Minor
Defects that could (or did) cause small or negligible consequences for the system in question. Easy to recover or workaround. Issues of this type will be addressed in a future regular release.

Example 1 - Error messages misleading.
Example 2 - Displaying output in a font or format other than what the customer desired.

Trivial
Trivial defects that can cause no negative consequences for the system in question. Such defects normally produce no erroneous outputs. Issues of this type may be addressed in a future regular release.

Example 1 - simple typos in documentation.
Example 2 - bad layout or mis-spelling on screen.