Bug Fix Policy

Summary

Our Support team will help with workarounds and bug reporting.
We schedule non-critical bugs according to a variety of considerations.

Important changes to our legacy technology services
We’ve ended new feature development for our legacy systems. Support for Green House is only to extract historic information. Intranet and Supervisor App support is limited to training and troubleshooting existing features. We’re continuing our investment in the Supervisor app, but this will be an entirely new application. Subscribe to our updates blog for more information.

Bug fixes for legacy services

We’ll continue to provide bug fixes for legacy services until December 31, 2021. After this, we’ll only provide security bug fixes for critical vulnerabilities until the end-of-life date for these applications.

Bug reports

Our Support team is eager and happy to help verify bugs—we take pride in it! Create an issue in our support system, providing as much information as you can about how to replicate the problem you’re experiencing. We’ll replicate the bug to verify, then lodge the report for you. We’ll also try to construct workarounds if possible.

Search existing bug reports

Use our public issue tracker to search for existing bugs, add your report, and watch the ones that are important to you. When you watch an issue, we’ll send you an e-mail notification when the issue’s updated.

How we approach bug fixing

Bugfix releases are more frequent than feature releases and target the most critical bugs affecting users. The notation for a bugfix release is the final number in the version (the 1 in 6.0.1, for example).

We seek to target the most critical bugs affecting the widest user set. Bugs are prioritized based on the estimated impact on franchises. Most bugs are initially reported at Medium priority until they are triaged and the true impact is assessed by our team.

The priorities applied to confirmed bugs are:

Priority 1 – Highest

A mission-critical application is degraded. Users aren’t able to perform their job function, and no workarounds are available. Typically the most impactful bugs are treated by our team as an incident and can be tracked on https://status.gjgardner.com, highest priority bugs are the next most impactful variety of bug. Examples include login failures, specific pages that don’t display, microservice communication failures, and administration tool failures. We begin work on the Highest priority bugs as soon as reasonably possible. Our target is to resolve them in 4 hours.

Priority 2 – High

A feature is unavailable, application performance is significantly degraded, or users’ job functions are impaired. Examples include the application performing slowly and failing intermittently, the application is functional but frequently used gadgets or macros don’t work, and specific editing features failing. We generally seek to begin work on these within 1 business day. Typically we will introduce a temporary fix and implement a permanent solution with the next release.

Priority 3 – Medium

The application or specific feature isn’t working as expected, but there is a workaround available. Users’ experience is impacted, but their job function is not impaired. Examples include some searches failing, sections of pages loading slowly, and administrative features failing intermittently, but a workaround is available. Medium priority bugs are typically worked on after all High and Highest priority bugs are resolved and there are no other critical priorities.

Priority 4 – Low

Typically smaller paper cuts such as cosmetic errors, or non-critical functionality do not behave as expected. Examples include visual defects, that don’t affect function, minor translation or localization problems, and keyboard shortcuts not functioning as expected. Low-priority bugs are worked on at our discretion and are typically only fixed if our Developers are already working in that area of the product and are able to easily resolve the problem identified.

About our bug fix workflow

If you watch or mark a bug as affecting your team, it’s useful to understand how we review, prioritize, and resolve them in our public issue tracker.

We prioritize issues using a metric field called Priority, which is individually calculated for every issue. It takes into account the number of affected users, the severity of the issue, and the urgency for a resolution. The higher the Priority score, the more pervasive and severe the issue is.

We have also standardized our workflow statuses across technology services to make it easy for you to see where an issue is at. Here’s the current workflow, and a description of each status.

Workflow status	Definition	Phase
Waiting on support	This issue is waiting to be reviewed by a member of the Support team. Typically, only recently created issues are in this status. Our team reviews these issues regularly.	Review
Waiting on customer	This issue has been reviewed, but needs more supporting information from the reporter to gauge how pervasive the problem is.
Escalated	The issue has been escalated to the development team is currently awaiting investigation and to be actioned.
In progress	Either the development or support team is currently working on this issue.	Prioritization
Pending	A fix for this issue has been proposed and is being reviewed and quality-tested by the development or support team. This may also indicate that a fix has been implemented and is waiting to be shipped in a release.	Prioritization
Cancelled	Work on this issue was cancelled because the user found a solution before it could be investigated.	Closure
Resolved	Work on this issue is complete. If it’s fixed, the resolution will be ‘Done’. If no code changes were required , the resolution will be ‘Duplicate’, ‘Cannot Reproduce’, Won’t Do’, or similar.
Closed	Work on this issue is complete and the reporter confirmed everything is working as expected.

How to get access to bug fixes

Once a bug fix is written, tested, and verified, we’ll progressively roll it out to your site as soon as we reasonably can – in many cases this will occur within a few days.

Please note the above priorities, timeframes, and objectives are intended to provide general guidance on how we internally handle bugs. Any response times or resolution timeframes in this document are non-binding targets and do not create any representations, warranties, obligations, or liabilities. Your franchise agreement and software license agreement governs any use of the applicable services and any related issues.