RFC 116: Wagtail 8.1 roadmap updates

[thibaudcolas]

View the RFC in HTML. View the combined RFC + roadmap preview. Once reviewed with enough feedback and approved by the core team, those changes will go live on the Wagtail Roadmap.

---

We have a 👏 new 👏 product 👏 strategy

This set of roadmap updates is the first one to be heavily influenced by our newly-announced product strategy. While the strategy is very much in continuation of our previous work, it’s a great opportunity for us to reset things as well, so this set of roadmap updates comes with:

• More new items than usual (12).
• More items proposed for closing / archiving than usual (7).
• All items now explicitly part of one of our strategic themes. It sounds fancy but really it’s just a way to understand how each item is intended to support our strategy.

Feedback welcome

I would particularly love feedback on items relating to two themes that I think historically we’ve been good at but haven’t actually invested much in:

• For 🛠️ DX for humans with AI, feedback on Agent skills for DX.
• For 🌳 How we build Wagtail, feedback on Security process automation.

And of course feedback on any and all other aspects of the RFC very welcome too!

Format experiments

Just want to highlight a few RFC format updates, I’d like feedback on that too if people find it helpful:

• I added a table of contents per section, to make it more scannable?
• I created a separate more visual RFC 116 roadmap preview, combined with the existing roadmap items, for people who prefer a more visual format?

[Stormheg]

Were 'Choosers UI improvements' that did not make the previous release reconsidered? Or are in they in this document under a different name?

[thibaudcolas]

yep (direct link to that item). This is super high-value so is regularly reconsidered, but we felt the timing wasn’t right. Paraphrasing discussions:

• Better choosers is very relevant to our strategy, both as a way to get better CMS UX for content operations, and to support deep integrations / customizations by providing reusable high-quality UI components and (ideally) a high-level integration API (the internal code terminology is ModalWorkflow).
• It’s also one of our biggest accessibility / usability gaps. Choosers are far behind the work we’ve done to make other listings and forms more usable (page editor redesign, universal listings, etc).
• And from a maintenance perspective they’re really hard to work on.

The main issue was the amount of work needed, the ROI just isn’t there for us to add it back to a release. Here’s the path I’ve tentatively proposed:

1. Scope this down to rebuild only one type of chooser first, with two simultaneous implementations in the codebase (tentatively: page chooser only, not even link chooser)
2. New architecture based on our in-progress v3 API, as a way to dogfood the kind of fine-grained filtering we definitely need for this use case.
3. Defer until the cost of implementation can be reduced via adoption of agentic engineering practices.

That last point I think is the biggest lever for us to get to this sooner than later. We need enough speed boost (for example better QA with more E2E integration tests?) that we can feel confident the choosers work would fit within the 6-8 weeks of work we can easily commit to in a single release, rather than the current uncomfortable 12+ weeks.

[Stormheg]

This is cool to see happening! Feels in line with my suggestions on wagtail/wagtail#14363

[Stormheg]

Interested to see how this will shape up

[thibaudcolas]

As an experiment, I created a separate more visual RFC 116 roadmap preview, combined with the existing roadmap items, for people who prefer a more visual format? The RFC + PR format is great for detailed feedback but felt a bit hard to look at as an overview. Feedback very welcome!