| 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:
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. |
ImpressCMS is a multi-language content management system for the web. It is community-built, an open source project and based on the common web technologies of PHP and MySQL.
More information
