Implementation of New Features and Improvements
Atlassian schedules features for every major release of our products 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, 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
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. 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 version' field to find the version for which the bug is fixed.
Bug fix releases come out more frequently than major releases and attempt to target the most critical bugs affecting our customers. The developers responsible for bug fixing also monitor comments on existing bugs and new bugs submitted in JIRA, so you can provide feedback in this way.
When raising a new bug, you should rate the priority of a bug according to our JIRA usage guidelines. When deciding how to prioritise each bug, the developers responsible for bug fixing consider this priority as well as several other factors:
- how many of our supported configurations are affected by the problem
- whether there is an effective workaround or patch
- how difficult the issue is to fix
- whether many bugs in one area can be fixed at one time.
We give high priority consideration to security issues.
Patch policy
When bugs arise through a support case or cause serious problems, we try to provide patches for these issues. Look to the attachments and comments on the issue 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.
Support policy
When support determines that a reported issue is a bug, we will resolve the support ticket incident and refer customers to our bug reports. Create a login for JIRA so you can set yourself as a watcher to receive automatic updates.
Our partner network can help
If you require significant customisations, you may wish to get in touch with our partners. They 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 all 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.
