새로운 기능 구현과 개선
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.
새로운 기능 구현 내용을 선택하는 방법
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.
릴리스 과정에 어떻게 영향을 주는가
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:
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.
연관된 이슈 링크
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.
JIRA 혹은 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.
Alternatively, 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.