Implementation of New Features and Improvements
Atlassian schedules features for every major release of JIRA or Confluence at the beginning of each release cycle. Therefore, new features and improvements are scheduled one version at a time.
We maintain roadmaps for more distant releases internally, but experience has shown that these roadmaps are often pre-empted by changing customer demands, and making our roadmaps public would create expectations that we would not fulfil. By only making a definitive schedule for the next version we can stay agile and responsive to dynamic needs of our customers and ensure that for each release we deliver those features that will benefit customers the most.
How We Choose What to Implement
In every major release we aim to implement highly requested features. Customers can vote on the issues they consider important in our public issue tracker, and the current tally of votes is available online (see JIRA popular issues and Confluence popular issues). If you have a feature that you would like to be included in either of the two products, please vote for the issue if one already exists, otherwise please create a new issue.
However, while popularity in JIRA is a significant measure of how important any one issue is to our customers, it is by no means the only determining factor of what will be scheduled. Other factors include:
- Direct feedback from face to face meetings with customers, and through our support and sales channels
- Availability of staff to implement features
- Impact of the proposed changes on the application and its underlying architecture
- How well defined the requested feature is (some issues gain in popularity rapidly, allowing little time to plan their implementation)
- Our long-term strategic vision for the product
For example, one much-requested feature may require considerable code changes or changes in the underlying architecture, forcing us to refactor the product's internals, which takes some time. As we perform these changes we implement other features, which may not be the most popular, but that can be developed concurrently with the refactoring process.
Alternatively, there may be some highly popular feature that could be implemented relatively simply, but that would be rendered redundant or need to be implemented again as a result of some development planned further into the future. In that situation we may postpone the popular feature in order to save potentially wasted development time.
When looking through a list of popular features please keep in mind that as issues are scheduled one version at a time. This means many of the issues in the list will have no target version set for their implementation. If you are looking at the list at the end of a release cycle you may see no popular issues scheduled at all. This occurs because implemented features are removed from the popular issues list, and we are polishing an upcoming version to ensure that we deliver a release of high quality. Please wait until the upcoming version is released, to determine what features we will be attacking next.
We always keep our focus on popular issues and do our best to implement them as fast as possible. Please vote for the issues you feel are important and add your comments, as it is the best way to let us know what you think.
How to influence the release process
Previously, Atlassian offered a service through which customers could pay Atlassian to implement specific features on a consulting basis. We have now discontinued this service, as we found it wasn't delivering the best results for all our customers. Atlassian will still perform large corporate customisations of our products, but we no longer accept commissions for individual features.
However, there are other ways to influence how we schedule features:
Feedback
Create an issue online, and not only provide the description of what you would like done, but why it is important to you, how this will impact your business, and how feature X will improve your sex life (better still, how it will improve our sex life). Let us know why a feature is important.
Before creating an issue, please see if one already exists. If you find one, please vote for it.
Link Related Issues
Often, feature requests will naturally group into areas of functionality that can be implemented together. Such groups are attractive for us to fix because solving a number of related issues often requires significantly less resources, and satisfies more customers than solving each problem individually. If you see related issues, use JIRA's issue linking features to link them together. The more 'related' features that can be fixed at once, the more likely we are to attack it.
Extending JIRA or Confluence
Both Confluence and JIRA offer powerful and flexible extension APIs. If you would like to see a particular feature implemented sooner, it may be possible to develop the feature as a plugin. Documentation regarding the plugin APIs for extending JIRA and Confluence is available online, and advice on extending either product may be available on the JIRA or Confluence user mailing-lists.
How we approach fixing bugs
A similar approach applies to bugs, which we also track using JIRA. Check the 'fix for verion' field to find the version for which the bug is fixed, and look to the attachments and comments to find if there's a workaround or a patch.
If you patch your product, please refer back to the bug report for when you upgrade. You will be responsible for making sure the fix has been integrated into the product, or the patch is available for your version. Let us know through the bug report if you have any questions through this process.
For some bugs, we may be unable or unwilling to issue patches - again for similar considerations as we use for new features. This should occur only with medium or low priority bugs. This does not mean a version is not supported - it just means we are not producing a patch.
Our partner network can help
If a feature, improvement, you may wish to get in touch with our parters, who specialise in extending Atlassian products and can do this work for you. If you are interested, please contact us.
Code Contributions
If you have already implemented a particular feature, you may wish to donate the code to Atlassian. The advantage of donating code is that we take over the task of maintaining your extensions and ensuring that they continue to work with future versions of the product, saving you the cost of maintaining the code yourself. Whilst we don't give discounts for donation of code, we appreciate your generosity. Things we look for in donated code:
- It has been generalised - while we appreciate that it solves your problem, we must consider the needs of 5000 other customers before we can incorporate it
- It has been commented and tested - unit tests: good. functional tests: better. working, commented, fully tested code: priceless.

Comments (4)
Dec 15, 2005
Martin Ollesch says:
Regarding How to influence ...: The standard user in JIRA is not allowed to link...Regarding How to influence ...:
The standard user in JIRA is not allowed to link issues in the Confluence Project; in the JIRA project he is.
Martin
Jan 30, 2006
Charles Miller says:
Thanks for pointing this out. I've changed the permissions on the Confluence pro...Thanks for pointing this out. I've changed the permissions on the Confluence project in JIRA so anyone can link issues.
Apr 18, 2007
Pete Miller says:
It would be good to include a link to the latest release plan from this page(hop...It would be good to include a link to the latest release plan from this page(hopefully that's a constant link
)
Jun 02
Christine A says:
Hello there, Some comments: Alternatively, there may be some highly popular ...Hello there,
Some comments:
Maybe you could/should indicate those issues by a special tag, flag, status, whatever.
Where/how can we know whether you guys are the begining, middle or end of a cycle?
This would prevent us from the sad impression of not being heard/taken into consideration.
I guess this is good, and we are certainly delighted that you pay so much attention to our opinion. Anyway, a drawback of this way-of-working is that everybody (you and us) is putting the attention/effort/energy on the most glaring and fundamental missing features, while there are lots of small ones, that would be very short to implemente, and that would make our lives so much more easier, and jira still much more user-friendly, but nobody of us has neither the time, nor the energy to find them, parse them, comment them, and vote for them. So they will obviously never been implemented, which is obviously a pitty for the quality of Jira. Maybe you could reserve a part of your development broadband to kill all these small issues...
Best Regards
Christine.