:sparkle: View the official Wagtail public roadmap. View full historical data in GitHub Projects.
Our public roadmap is where you can learn about what features we're working on, what stage they're in, and when we expect to bring them to you. It also covers major community or project efforts that aren’t features.
We’re planning to iterate on the format of the roadmap itself, and we see potential to engage more in discussions about the future of Wagtail. If you have feedback about this roadmap repository itself, such as how the issues are presented, let us know through GitHub Discussions for Wagtail.
Every item on the roadmap is a GitHub issue, with labels to indicate high-level areas of focus.
Only items of significant interest to the community go onto the roadmap. This definition is purposefully vague at the moment, and should be reviewed on a regular basis.
Items only go onto the roadmap once they have been considered by the core team. These items might, or might not need an RFC for implementation details before they get on the roadmap.
The roadmap is arranged on a project board to give a sense for how far out each item is on the horizon. Every project or feature is added to a particular board column according to the release in which it is expected to be done. Items spanning multiple releases / long-term architecture changes can have a dedicated column. Items without any agreed delivery mechanism go into a "Future" column. This Future column acts as a way to attract contributions and/or sponsorship on items that align with our long-term plans.
Once an item is delivered we remove it from the board - the release notes act as the record of its delivery.
RFCs can be used for roadmap additions, so core team members and the wider community can provide feedback easily. Using an RFC isn’t mandatory as long as additions still get duly reviewed by the core team.
The core team review should include:
Feedback from the wider community is also welcome as part of roadmap additions.
Roadmap items should have titles accessible to stakeholders without technical expertise a lot of context on how Wagtail works
Proposed roadmap items should provide enough details to fill in the relevant sections of this proposed roadmap item template:
## Summary
A short overview of the proposed work. One paragraph, tweet-sized.
## Intended Outcome
A short paragraph or list of 2-5 items detailing what will be the result of this work.
## More information
If relevant – a list of 1-3 links to related issues, pull requests, RFCs, or other documentation.Usage of the template as-is isn’t mandatory. For example, if an item is already tracked by a given issue / pull request / or RFC with sufficient details – that can be used as-is.
It helps with planning of a release if roadmap items are reviewed ahead of development starting for said release. Our process should fit between a major/minor release’s first release candidate (RC) and the final release (as defined by our release schedule).
For example, if Wagtail 4.2’s first RC is released on Friday 20th Jan, and its final release is on Monday 6th Feb, roadmap additions can be reviewed for two weeks between Monday 23rd Jan and Monday 6th Feb, including potential discussions at two core team meetings. This means the RFC will spend 3 days in its "Review" stage and 10 days in "Final Comment Period".
To keep the review process fast, we recommend to:
For maintainers, here is guidance on how to manage our roadmap data:
roadmap repository as roadmap entries. This makes for a more consistent experience for everyone (same labels, comments all in the same repository, etc.)