Our Github milestones represent a general direction for the future releases of Elgg.
This is the closest thing to a traditional roadmap that we have.

Github pull requests will give you a good idea of what’s currently being developed,
but nothing is sure until the PR is actually checked in.

We use the developer blog to post announcements of features that have recently been checked in to our development branch,
which gives the surest indication of what features will be available in the next release.

We want to make manual testing unnecessary for core developers, plugin authors, and site administrators
by promoting and enabling fast, automated testing at every level of the Elgg stack.

We think APIs are broken if they require plugin authors to write untestable code.
We know there are a lot of violations of this principle in core currently and are working to fix it.

We look forward to a world where the core developers do not need to do any manual testing to verify the correctness of code contributed to Elgg.
Similarly, we envision a world where site administrators can upgrade and install new plugins with confidence that everything works well together.

We cannot promise when features will get implemented because
new features are checked into Elgg only when someone is motivated enough
to implement the feature and submit a pull request.
The best we can do is tell you to look out for what features
existing developers have expressed interest in working on.

The best way to ensure a feature gets implemented is to discuss it with the core team and implement it yourself.
See our Contributor Guides guide if you’re interested. We love new contributors!

Do not rely on future enhancements if you’re on the fence as to whether to use Elgg.
Evaluate it given the current feature set.
Upcoming features will almost certainly not materialize within your timeline.