How we prioritize feature requests, bug fixes, and security fixes

We've created a guide to help users understand jira.atlassian.com workflows and statuses. Below, you'll find details about feature requests, bug fixes, and security fixes.

Feature requests and suggestions

When a customer creates a feature request, the request automatically enters the gathering interest status. We measure interest in a few ways, including the number of votes a request receives and the UIS (user impact score) of the feature. UIS is calculated using vote velocity and the number of active users who would be impacted by the change. If a request doesn't generate enough interest, we'll close it. This criteria ensures the most popular suggestions are addressed first.

If a request generates enough interest, we move it to the reviewing state. An Atlassian product manager will investigate the viability and relative priority of the suggestion, and then they will triage it into one of three statuses: under consideration, future consideration, or not being considered.

Under consideration: Includes requests we think will add significant customer value and are a strong fit for our roadmap. When a feature request is under consideration, there's a high likelihood we will deliver the feature in the near future. We'll keep you in the loop and provide an update within a few months of your request.
Future consideration: Includes requests that could be additions to our longer-term roadmap. Once a year, we'll reconsider the request and alter the status if needed.
Not being considered: Includes requests that we are unable to implement. While we appreciate the potential benefits of all requests, we unfortunately cannot implement all of the excellent suggestions our customers make. We won't work on requests in this status, but we will review them after one year and consider altering the status. We understand it may be disappointing to see a suggestion you feel passionately about either closed or triaged into not being considered. However, we believe that we owe our customers greater transparency into feature requests, and we believe this new workflow will help us accomplish our goal.

We mark the final resolution of suggestions in one of the following ways:

Resolved: fixed: we've completed your suggested fix!
Resolved: won't do: the suggestion did not gain enough customer interest or does not fit with the direction of our product for the time being.
Resolved: duplicate: a more popular, duplicate suggestions already exists.
Resolved: invalid: the suggestion is not expressed clearly enough to be considered thoroughly by a product manager.

The suggestion workflow

Statuses explained

Atlassian’s suggestion workflow is identical to the bug workflow. This is intentional and designed to help our customers have a consistent understanding whether they're looking at a bug or a suggestion in our backlog.

Remember, when an issue is closed, check the resolution to understand if code was implemented.

Workflow status	Definition
Gathering interest	This suggestion needs more unique domain votes and comments before being reviewed by our team.
Reviewing	We're currently reviewing this suggestion. This may involve collecting more information about the customer problem, conducting a technical investigation, or analyzing the strategic alignment with our roadmap.
Under consideration	We are looking into this suggestion and believe it to be a strong candidate for our roadmap. We will continue investigating and provide a follow-up in a few months time.
Future consideration	We see this suggestion as a potential candidate for our longer-term roadmap, but won't be working on it at the moment. We will reconsider the suggestion in a year.
Not being considered	While we appreciate the potential impact and value this issue may bring to our customers, we will not be working on it in the foreseeable future. We will review this ticket in a year to see if our decision has changed.
In progress	The development team is currently working on this issue.
Waiting for release	A fix for this issue has been implemented and is waiting to be shipped in a release.
Closed	Work on this issue is complete. If it’s fixed in a product, the resolution will be fixed and the fix version field will indicate the product version that contains the fix. If no code changes were required, the resolution will be duplicate, won't fix, handled by support, timed out, or similar.

Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our New feature policy.

See this Atlassian Community post to understand how jira.atlassian.com works.

Bug fixes

As with all software companies, we have a bug backlog. We urge our customers to submit bug reports when they find them. Atlassian Support helps verify bug reports and identify workarounds if possible. Once the bug is verified, Support will log a bug report in our backlog.

Critical Bugs

A critical bug is something that makes an application unavailable. Users are not able to perform their job function and no workaround is available. Some examples of a critical defect are a login failure affecting most users, significant data loss, or all or most pages not displaying.

Major Bugs

A major bug is something that makes a feature unavailable, significantly degrades performance, or impairs users' job functions. Examples of major defects include a critical bug that has a viable workaround, intermittent failures, or when an application is functional but frequently-used gadgets or macros don’t work.

Minor Bugs

A minor bug is something that makes the application or specific feature not work as expected, but there is a workaround available. The user experience may be impacted, but job functions are not impaired. Some examples of a minor bug are keyboard shortcuts not functioning, sections of pages loading slowly, some searches failing, and UI (user interface) defects that do not affect functionality.

We strive to fix critical bugs in our next maintenance release whenever possible. These fixes are released to our customers in the "bug fix releases" detailed below. Non-critical bugs are scheduled into our backlogs with a variety of considerations.

User Impact Score (UIS)

We prioritize non-critical bugs using a metric called User Impact Score (UIS), which is individually calculated for every issue. UIS takes into account the number of affected users, the severity of the issue, recent interest, and the percentage of users affected per instance. The higher the UIS score, the more pervasive and severe the issue is.

When you hear the support team or someone from Advisory Services tell you to watch or vote for an issue, this is why. When you log a support ticket and the root cause is determined to be a bug that is in our backlog, the support engineer notates the support ticket against that bug. The input from you and our support team will impact the UIS.

We have also standardized our workflow statuses across our cloud and on-premesis products to make it easy for you to see the status of an issue. Here’s the current workflow, and a description of each status:

The bug fix workflow

Statuses explained

Workflow Status	Definition
Needs triage	This issue is waiting to be reviewed by a member of the Atlassian product team. Typically, only recently-created issues are in this status. Our product teams review these issues regularly.
Gathering impact	This issue has been reviewed, but needs more supporting information to gauge the pervasiveness of the problem.
Long-term backlog	A fix for this issue is required, but is planned for the future. The issue is less severe or pervasive than other issues.
Short-term backlog	A fix for this issue is required, and will be prioritized in the near future. The issue is more severe or pervasive than other issues.
In progress	The development team is actively working on this issue.
In review	A fix for this issue has been proposed and is being reviewed and quality tested by the development team.
Waiting for release	A fix for this issue has been implemented and is waiting to be rolled out.
Closed	Work on this issue is complete. If the bug has been fixed, the resolution will be labeled fixed. Code changes are rolled out to the full customer base as needed. If no code changes were required, the resolution will be labeled duplicate, won't fix, handled by support, timed out, or similar.

See more in our Atlassian Cloud bug fix policy or our Data Center and Server bug fix policy.

Security fixes

We never want to face security vulnerabilities, but unfortunately, they do happen. When a user raises a security bug issue and the Atlassian support and product teams verify it, we assign a priority level based on the CVSS (Common Vulnerability Scoring System), which is an industry standard vulnerability scoring metric. You can learn more about CVSS at FIRST.org.

The CVSS drives the priority with which we address security bugs. All security bugs have an associated SLA (service level agreement) for remediation. Let’s dive into those priority levels and SLAs:

Cloud-based Atlassian products

These timeframes apply to all cloud-based Atlassian products, and any other software or system that is managed by Atlassian, or is running on Atlassian infrastructure.

Security bug priority levels & SLA -- cloud-based products

Critical

Critical security vulnerabilities, when exploited, can include a root-level compromise of servers, not needing special authentication, or an attacker not needing to persuade a target user into performing a special function. We will fix critical vulnerabilities in-product within two weeks of their report. We recommend users upgrade as soon as a fix is available unless they have a mitigation in place.

High

High security vulnerabilities are usually difficult to exploit, but when they are exploited, they could result in elevated privileges for an attacker, or significant data loss or downtime for the company. We will fix high vulnerability bugs in-product within four weeks of their report.

Medium

Medium security vulnerabilities usually require the attacker to reside on the same local network as the victim, and they usually require the attacker to manipulate the victim using social engineering tactics. Or, the exploitation of a medium security vulnerability will provide limited access to the system. We will fix medium security bugs in-product within six weeks of their report.

Low

Low security vulnerabilities typically have very little impact on an organization’s business and usually require local or physical system access to exploit.

Typically, we will release fixes for high, medium and low security defects with the next scheduled release. We will backport critical security bug fixes according to Atlassian’s backport policy (see below).

Self-managed Atlassian products

These timeframes apply to all self-managed Atlassian products, and Jira Align (both the cloud and self-managed versions). A self-managed product is installed by customers on customer-managed systems, and includes Atlassian's Server, Data Center, desktop, and mobile applications.

We will fix critical, high, and medium-severity bugs in-product within 90 days of their report.
We will fix low-severity bugs in-product within 180 days of their report.

Backport policy

We will always backport critical security bug fixes, and we will backport other security bug fixes when possible.

Atlassian’s backport policy differs based on the product:

For Jira, Confluence and Bitbucket, we will backport critical security bug fixes to all feature release versions that were released within six months of the date the fix is released. We will also backport fixes to any long term support (LTS) version that has not reached end-of-life.
For all other products, we will backport critical security bug fixes to the current and previous feature release versions. For example, if we developed a critical security bug fix on January 1, 2020 for Bamboo, we would have produced the following new bug fix releases:
- Bamboo 6.10.x, because it was released on September 17, 2019 and was the current release.
- Bamboo 6.9.x, because 6.9.0 was the previous release at the time of our critical security bug fix.

Read more on our Security bug fix policy page.

Atlassian Security Advisory

Atlassian will publish a security advisory at the same time the fix is released for critical-severity vulnerabilities in an Atlassian product.

We publish the advisory on http://www.atlassian.com/trust/security and send an email notice to the alerts mailing list for the product concerned. We also put advanced notice on the Critical security advisories page within the Advisory Services cloud for our Advisory Services customers.

All other security issues can be monitored by Atlassian customers on jira.atlassian.com. Security issues will be marked with a security label. As we fix issues, we will list them in the release notes, just as we do with other bugs.

References

Was this content helpful?

Connect, share, or get additional help

Atlassian Community