The main problem about not working directly in core contributions is the problem of reintegration: the more changes pile up outside, the less likely it is that they will be integrated. Let’s say there’s a long-running feature branch which receives 20+ commits - in order to finally suggest this to be merged into the core, it has to be squashed (and therefore very, very well documented since history becomes truncated). It also has to be possible to understand as “one unit of work” to give the reviewers/mergers a chance of actually understanding what merging a given proposal implies. Then there are the secondary concerns - CI runs unit, functional and acceptance tests that also have to be working, and these are notoriously difficult to manage externally.
The best chance for merging is obtained by:
- First of all discussing the potential change with the core team to explain why it is necessary and gain pointers on the proposal. Getting an initial verdict of the feasibility, basically. TYPO3 has core mergers for many individual topics - you can find a list on https://typo3.org/community/teams/typo3-development. I’m aware that some suggestions don’t fit neatly into a single area so you may need to get a couple of group chats going in Slack.
- Making the changes as smaller units of work, ideally ones that can be merged one small unit at a time. The proposed global scale refactoring is probably not going to be possible to achieve this way.
- Keeping changes completely up to date, which means continuously assimilating all changes that happen to upstream - and this is very hard work.
This is also why a “fast lane” working group would have quite a hard time getting their work done. You’re already onto some of it (3-month cycles) but I doubt that the larger changes would fit with such an optimistic cycle time. Some of the changes could easily be 6-12 month full-time projects, keeping in mind that things like acceptance tests also have to be preserved/adjusted. It’s a lot more work than it looks like on the surface.
Best suggestion I can give is, write down a vision for it (and be concrete!). Then try to plan out smaller units of work and their interdependencies - and then work (alone or in a group, doesn’t really matter) on each of those units of work in the right order. Once this is done, a wireframe for the work can be created as a series of issues combined under a single epic, which gives onlookers a way to see what has been done and what needs to be done, as well as understand why X is being done (part of a larger plan).
And before anything else, get feedback on the overall vision, then on he segmented plan.
This absolutely will not happen. It was tried once before, with the mythical TYPO3v5 (you may have noticed there’s a hole in the version sequence) which was attempted as a TYPO3 association-funded project. That ended up violating the working group’s stated compatible-successor principles and became a separate product now known as Neos. I couldn’t in my wildest fever dreams imagine that this would be risked a second time. It may have been the most costly mistake ever made in TYPO3’s long history.