Cookies on this website

We use cookies to ensure that we give you the best experience on our website. If you click 'Accept all cookies' we'll assume that you are happy to receive all cookies and you won't see this message again. If you click 'Reject all non-essential cookies' only necessary cookies providing core functionality such as security, network management, and accessibility will be enabled. Click 'Find out more' for information on how to change your cookie settings.

A core part of the Haiku project is Evolution - the process by which we ensure that Haiku continues to meet our needs.

The Haiku project aims to keep ahead with new developments while making sure that we focus on what's important to those using the system.

Requirements for websites change and expand all the time. Back in 2011, when we first surveyed our pilot departments they felt that video and podcasts weren't important to them. Within a year, their views had changed and integration with videos and podcasts from YouTube and SoundCloud were deemed to be an essential part of their communication strategies.

Each Haiku site pays an annual maintenance and development charge, part of which goes towards development work tailored to our requirements. We decide on the developments through a number of mechanisms.

Haiku Planning Day

We had our second planning day in September 2019. All editors in chief were invited to the day to work alongside the Haiku developers, project manager and designers. We felt that this worked well as a mechanism to draw out broader themes for big developments and infrastructure requirements as well as making requests for 'softer' requirements such as better documentation and more design support.

Feature Requests

If you have a particular requirement that Haiku doesn't yet meet, then ask your Editor in Chief to submit this to HaikuHQ. The Haiku development team will review the request and publish it on the HaikuHQ website where others can comment. Each feature will be considered. Is it a good idea? What are the pros and cons? Are there any additional requirements to consider, might there be an alternative route?


Every feature is flagged with a number of tokens. This represents the effort needed to develop the feature. We do this because sometimes things that seem very simple turn out to be quite difficult to develop - and knowing how much effort and resource a feature might take up means that it is easier to prioritize. 

For each development cycle we have a specific number of tokens to 'spend' in total - based on the number of sites using Haiku and contributing to the evolution process and the amount of effort available to the consultancy once significant maintenance, infrastructure developments and support have been taken into account. A substantial number of tokens are allocated to the work emerging from the Haiku Planning Day, the remainder are allocated to feature requests.


Features are worked up into proposals, with user stories and mock-ups where appropriate. Editors in Chief are then asked to vote on the features most important to them - giving each feature between 0 and 5 stars (0 = low priority, 5 = high priority). The developers will then take the top features - up to an agreed number of tokens - and incorporate them into the Haiku Roadmap

Roadmap & Reports

Development takes place in three week cycles and new releases with new features are relatively frequent. The point at which a feature is developed and released or a planned development appears depends on overall practicalities. Sometimes one feature depends on other elements being developed and released first or a bigger infrastructural change.

Currently specifications and developments are reviewed by the Divisional web team (a small project team contributes to developments around the design refresh). More regular reporting on releases for editors in chief is planned for this year. 

If you would like to see what's scheduled, and when, then take a look at the published Haiku Roadmap.