RFC #88: Public roadmap updates

[thibaudcolas]

Ahead of the Wagtail 6.0 release :) View the rendered RFC.

[lb-]

Could we maybe change the title format going forward to include the release number? So that it's easier to look at in the RFC listing.

[thibaudcolas]

Thanks @lb-, great point. For this you’d suggest I switch to "v5.3" then? Something like

• Filename: text/088-v53-roadmap-updates.md
• PR title: RFC #88: v5.3 Public roadmap updates

Or would I use the current release cycle?

[Scotchester]

Lots of great stuff! Is it too much? 🙂 How can we reduce the number of things getting delayed/carried-over? One of the issues with publishing a public roadmap is that people can be disappointed when their favorite items slip from the original schedule.

[olifante]

Lots of stuff in the next release indeed: 10 cards planned for 5.3 and another 10 cards for the entire remaining future. Overpromising and underdelivering could indeed lead to disappointed users and overburdened developers.

On another note, what is the incentive for someone to sponsor a feature if it's already been selected for inclusion in the next release? Perhaps it would be enough to have a minimal plan for the next release and allow sponsors to push for inclusion of their favourite features on top of the minimal plan.

[thibaudcolas]

Good question @Scotchester and @tiago-castro-henriques. I think we’ve felt ok about carrying things over because we’ve prioritized keeping to schedule over specific things shipping, and because lots of the "roadmap-level" things take longer than a single release has room for. Your point still stands though.

Do you think we should make more of an effort to do less carry-over then?

---

On another note, what is the incentive for someone to sponsor a feature if it's already been selected for inclusion in the next release?

For the specific features earmarked as "needs sponsorship" currently, we’re essentially doing some of the work but still think there is room for sponsorship in a future release if that makes sense? There’s certainly room for us to make that kind of status clearer.

[thibaudcolas]

@Scotchester @olifante I have updated the RFC to provide more details, and make it clearer what is a straight up "carry over", and what are extensions on existing work. Could you take another look?

[thibaudcolas]

I have made further changes based on discussions with colleagues and the core team, with the goal of being more conservative in our roadmap scheduling:

• The dashboard enhancements are now a "Future" roadmap item. Still hoping to work on this in the next and next + 1 releases but we don’t know how much work will be needed at this point.
• Same for readability / content quality checks
• "CSP compatibility improvements" are done enough for now and won’t carry over despite the potential for even further improvements – since we don’t know when CSP compatibility will be achieved.
• "Multi-tenancy improvements" now earmarked for a "Future" release – keen to do those for the May 2024 release but we can’t tell for sure at this point.
• In May 2024, we will aim to ship "Admin accessibility improvements" rather than the full "WCAG 2.1 AA for Wagtail admin"

[Scotchester]

This looks great to me with the latest updates!

[lb-]

Happy to approve also. I'm keen to understand the direction on the auto lock / auto save stuff if possible.

I think there could be some alignment with the dirty form logic / Stimulus migration. But that's probably best to discuss elsewhere.

I also agree that CSP is best kept in the future, not a specific release. Hopefully we will keep making some progress each release though.

Thanks Thibaud for managing this.

[thibaudcolas]

Thank you @Scotchester and @lb- 😌 I believe this is the first time we get those roadmap updates approved for an upcoming version before the release of the preceding version – which is amazing! I’ll leave this open for another week in case other people have feedback (@activus-d mentioned being interested in reviewing during our developer relations team meeting).

I'm keen to understand the direction on the auto lock / auto save stuff if possible.

@gasman and I were discussing this last week I think. They seem quite different in scope.

Auto-lock is almost entirely a UX/UI problem. It’ll be the same lock/unlock logic as we have right now but over AJAX. We need to think of when to trigger locks (dirty from check?) and un-locks, and how to update the UI for the lock-er and people locked-out. Likely quite a bit of Stimulus here, and yeah overlap with the dirty form check as this will live-update based on interactions with the form. I believe we have preliminary designs for the full auto-save experience but not this intermediary step. Will follow up on Roadmap item #41 auto-locking for pages.

Auto-save is more extensively discussed on Auto-save #7636. We’ve not done much further research on this since, aside from having "Telepath everything" on the roadmap as a preliminary step.

[thibaudcolas]

Thank you all for the feedback :)

wagtail.org/roadmap/ is now fully up-to-date with what we discussed here.

You might also find it interesting to look at the underyling GitHub Projects views or the Closed Milestones, which show historical data. There’s quite a bit on there now, since we adopted this new process 6 releases ago / more than a year ago.

Birds’ eye record for reference:

• v4.0: 11 items shipped
• v4.1: 6
• v4.2: 8
• v5.0: 8
• v5.1: 7
• v5.2: 7

For v6.0 – we have 11 items lined up currently. 7 of those are ""feature development areas"", 1 is our Season of Docs tutorials project with @activus-d which is very close to shipping, and 3 are the upcoming Outreachy internships. So we could well get all 11 through!