Program Error Classification

Abstract

This article outlines C2C's policies related to Program Errors, their classification, diagnosis, and resolution.  Unless otherwise stated, these policies apply to all C2C software products and the services related to them.


This article and its contents may be updated, modified, or replaced, at any time, by C2C at its sole discretion, with or without notice to its customers.


Selected Definitions

Program Error - n.  A Program Error refers to software, or its supporting hardware, that does not operate substantially in accordance with its written specifications; or Documentation that is not accurate or up-to-date.

Classification

C2C classifies "Program Errors" (also known as "Bugs" or "Defects") based on their "severity" so that issues can be prioritized in a way that maximizes positive user experiences.


Although Customer's feedback is one of the most important factors that C2C considers when classifying Program Errors, Program Error classification is the sole responsibility of C2C and its staff.  All customers must accept C2C's classification of a given Program Error as correct and final, without limitation.

Available Classifications

The following classifications may be applied to Program Errors.


Classification NameSummary
"Critical""Critical Program Errors" are considered to be the highest severity and highest priority; they require (and should receive) the fastest possible response and resolution.
"High Priority""High Priority Program Errors" are considered to be severe and should receive a relatively fast response and resolution.
"Medium Priority""Medium Priority" is the default classification for Program Errors; they are considered to be moderately severe and should receive a reasonably prompt response.
"Low Priority""Low Priority" is reserved for Program Errors that have a minimal impact on the user experience and for Program Errors that cannot be reproduced, despite multiple attempts to do so.

Classification Factors

The classification of Program Errors is a subjective process that requires C2C staff to consider a large number of factors.  Some factors considered may be unique to the specific Program Error being classified or factors that only apply to a subset of Program Errors.


In consideration of the dynamic nature of Program Errors, there is not a strict formula for Program Error Classification and it is not possible to predict what classification any given Program Error will receive prior to C2C analyzing the details of that, specific, Program Error.  However, the following "factors" are almost always considered and usually have a major influence on the classification decision:

User Feedback

Program Errors usually affect users more than anyone else and our sterile development environments can often shield our developers from the real-world conditions that expose Program Errors in our software products.


Because of that, user feedback is often (but not always) the most important factor that C2C considers when classifying Program Errors.


In many cases (but not all), if a user reports that a Program Error should be considered as "Critical", C2C will accept the user's classification until the issue can be analyzed by a support technician. Even after analysis, C2C is usually reluctant to make decisions that contradict the information provided by the reporting user or users.

Impact Level

The approximate impact of any given Program Error is referred to as its "Impact Level". 


In general, Program Errors with a higher impact level will be considered as more severe than those with a lower impact level.


The available impact levels are described below.


Impact LevelNameSummary
4"Outage"Program Errors that prevent a majority percentage of all users, or all users of a "User Type" to completely lose service.
3"Partial Outage"Program Errors that prevent a minority subset of all users to completely lose service.
2"Unknown Impact"When the impact of a Program Error cannot be approximated, this impact level is used as the default.
1"Performance Degradation"Program Errors that cause the Product to run slowly for one or more users.

Affected User Type

When classifying Program Errors, C2C considers Program errors that affect lower-level users to be more severe than those that affect higher-level users. This is because lower-level users are assumed to be ...


  • ... the least informed about the Product and its usage.
  • ... the least capable of finding creative, technical, solutions and work-arounds.
  • ... the most vulnerable to problems and errors.
  • ... the most numerous.
  • ... the most expensive to support.


Within the context of Program Error classification, the following "User Types" (a.k.a "User Levels") are considered:


Level User Type Summary
1"End Users"Users with zero-to-minimal administrative privileges.
2"Privileged Users"Users with some administrative privileges but who are not directly employed by one of C2C's customers.
3"Administrators"Users employed, or contracted, directly, by one of C2C's customers.
4"Developers"Users employed, or contracted, by C2C.

Component Level

The severity of an issue may also depend on the affected component and its domain ("location" or "layer") within the system or source code.


In general, the more prolific that a component is, the lower its level and the higher severity its respective Program Errors are considered to be. This is because more prolific (lower level) components are ...


  • ... more mature and thought to be more stable.
  • ... more likely to cause broad, cascading, issues throughout the software.
  • ... more difficult to diagnose and repair.


Within the context of Program Error classification, the following "Component Levels" are considered:


Level Name Summary
1"Third Party"Low-level software or infrastructure components that were developed by a third party.
2"Low Level"Proprietary components that are generic and highly prolific.
3"Mid Level"Proprietary components that are moderately generic and prolific.
4"High Level"Proprietary components that are used within a very narrow context and for a limited number of purposes.
5"Supporting"Components that exist in support of the software but exist outside of the primary code base.

Classification Updates

Throughout the life cycle of a Program Error and its resolution, C2C may, at its sole discretion, change the classification of any given Program Error, without notice.


Classification changes are not uncommon and occur in a significant percentage of all Program Error reports. Often, the classification for any given Program Error will change multiple times throughout its life cycle as C2C learns more about its cause and effects.

Resolution

Precedence

C2C will attempt to resolve all known Program Errors in order of first, their severity, and second, the order in which they were reported/received.


In most cases, C2C will not work on the resolution of any Program Error if another Program Error of higher severity is known and its resolution can be progressed.


This rule applies across all of C2C's products; it is possible for a Program Error in one product to affect the resolution timeline for all other Program Errors in all other C2C products.

Resource Commitment

C2C will commit its support resources and staff to receiving, confirming, and researching reported Program Errors during standard business hours (Mon-Fri 9am-4pm EST, excluding holidays).


As soon as a Program Error has been confirmed and its replication steps fully resolved, C2C will commit technical resources proportionate to the severity of Program Error.


In general, it is C2C's policy to suspend progress on all development, company-wide, while any "Critical" or "High Priority" Program Errors are known to exist, to the extent that doing so is likely to expedite the resolution of those Program Errors.


Deployment Policies

C2C deploys updates to its software products in batches known as a "releases" at predetermined dates and times in what is known as C2C's "Release Schedule".


C2C's release schedule is produced by C2C, at its sole discretion, and it varies dependent on multiple factors that are beyond the scope of this article. In general, however, releases are published at the first available "off-peak" (low traffic) opportunity after C2C becomes confident that the release is complete and does not create new Program Errors (it is thought to be "stable").


In most cases, fixes for Program Errors (especially "Low Priority" and "Medium Priority") will be deployed as part of C2C's "Release Schedule".

Hot Fixes

Unscheduled deployments that occur outside of C2C's release schedule are known as "Hot Fixes" and may occur at any time of the day, regardless of the consequences and number of users that are likely to be negatively affected by the release. Stability confidence for "Hot Fixes" is substantially lower and releases of this type are considered to be very risky.


In general, C2C will only use "Hot Fixes" to deploy fixes for "Critical" Program Errors.

Expedited Releases

Fixes for "High Priority" Program Errors will typically be released at the next available off-peak opportunity, even if it is the only source update being deployed. This type of release is known as an "Expedited Release". Stability confidence for Expedited Releases is somewhat lower and releases of this type are considered to be risky.






Is this article helpful for you?