Child pages
  • TIG Bug Fixing Policy
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Summary

  • Our Support team will help with workarounds and bug reporting
  • We'll generally fix critical bugs in the next maintenance release
  • We schedule non-critical bugs according to a variety of considerations

How we approach bug fixing

Bug fix releases are more frequent than feature releases, and target the most critical bugs affecting customers. The notation for a bug fix release is the final number in the version (the 3 in v1.7.3, for example).

We assess each bug based on the symptom severity (that is, when this bug causes symptoms, how severe are those symptoms). There are three levels of symptom severity:

PriorityDescription
Business critical

Customers can't place orders / Unable to process orders

The moment a bug is given the status "Business critical" it will get the highest priority. Investigation for this kind of bugs will start immediately. The fix will be communicated once it is available and will be implemented in the upcoming release of the extension.

Resolution time will vary depending on the complexity of the problem. We strive to provide a solution within 2 sprint lengths (4 weeks). But of course we will do everything to get it solved as soon as possible.

Internal processes blocked

Our internal processes are blocked due to this issue

Once we determined that this is caused by the extension, we will take appropriate action. The maximum resolution time will be 2 sprints (4 weeks). There will always be exceptions to this rule. When it takes longer than 4 weeks, we will inform you about that.

High priority: Workaround available

Able to continue working but taking longer than usual

This will be planned for the next sprint. Sprints start every 2 weeks at the beginning of the week and last 2 weeks. These kinds of issues can be prioritized by the product owner and client.

Normal/Feature request

Feature requests or issues with minor impact will be prioritized by the product owner and client. When it concerns an improvement, expansion or addition to the extension the client will determine the priority. For this kind of requests there is no maximum time, it all depends on the priority of the client. Once the improvement, expansion or addition is applied to the extension you will receive an update by e-mail.

Assessing bugs using symptom severity makes sure that we prioritize the most impactful fixes. We give high priority to security issues.

  • No labels