[…] I would still very much prefer the Neos.Ui package(s) to be part of the neos-development-collection […]
I wonder about your reasoning against that?
Thanks for chiming in! 
I think it’s crucial we think this through thoroughly, and your objection marks an important point.
To explain my thought process: I’m thinking of the third dev-collection as an attempt at an Inverse Conway Manoeuvre. Starting with Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
I would hypothesize that our repository structure determines our communication structure. Following Conway, this would mean: to support our system design, we must reflect its desired structure in our repository structure.
The key question then is: What is the desired structure of our system design?
My assumption is, that Neos.Ui is to Neos what Neos is to Flow. Flow is a general purpose application framework that supports (but not exclusively) Neos. Similary, Neos is a general purpose content application framework that supports (but not exclusively) the Neos UI.
To be clear: By this I don’t mean that we need to anticipate someone writing an entire UI of their own. I rather think that every Site built with Neos can be considered an Application supported by Neos, and the Neos UI simply lives in that same layer. In reverse conclusion this also means that every requirement the UI poses upon the Neos Core will result in an API that every other Application/Site will benefit from.
Admittedly, this is a very strong assumption and might very well be a case of YAGNI. I believe that as a team and a community, we need to make a decision here.
There’s some anecdotal evidence that I think supports my hypothesis:
For instance, the problems outlined in my original post bother us precisely because there’s a structural boundary and we’re palpably violating it. If the Neos.Neos.Ui package would be part of the neos-development-collection repository, we would probably notice some weirdness there, because the boundaries between Neos.Neos and Neos.Neos.Ui are unclear, but I’m not sure it would bother us enough, to consider it worthwhile to fix it. (And this would be okay, if we do not wish to follow a strategy of avoiding cohesion in this area)
The way it is now, the two repositories neos-ui and neos-development-collection are in a clear customer<->supplier relationship. Some desired functionality in the UI may require changes to the underlying domain model. I consider it a good thing that such changes need to go the extra mile, encouraging us to talk about broader concepts, and cannot be snuck in silently.
A good recent example for this is the “Publishing Bonanza” topic. There was one big PR in neos-development-collection which triggered a discussion with 5 participants (see: FEATURE: Highlevel Workspace API by nezaniel · Pull Request #4943 · neos/neos-development-collection · GitHub). The result was a design for a high-level Workspace API, that is useful to integrators and other backend consumers rather than just the UI. This is much more than we would have needed to solve the immediate problem in the UI, and I for one certainly didn’t see that coming
This goes to show, that the boundary between neos-development-collection and neos-ui forces us to make a clear cut. Any functionality that spans both repositories must be split into two separate PRs that will be discussed under very different perspectives. It also means, that the overall change will (ideally) be reviewed by 4 rather than just 2 people, with 2 reviewers focusing on the domain and infrastructural impact, and 2 reviewers focusing on the UI impact.
This is all grey theory, but besides those strategic considerations, I also see more mundane things to consider. Just looking at some basic metrics about both repositories and what we’d end up with:
| Repository | Size | Open Issues | Open Pull Requests | CI Duration |
|---|---|---|---|---|
neos-ui |
~300MB (Source) | 234 | 53 | 15-20min |
neos-development-collection |
~170MB (Source) | 471 | 93 | 35-40min |
| both, unified | ~470MB | 714 | 146 | 50-60min (possibly less thanks to parallelization) |
I cannot actually judge how problematic such increase in size would be. I just have a strong urge to split things up, when their size grows beyond a (subjectively) comfortable level :D. Looking at issues and PRs though, I would definitely say that this would have a negative impact on the signal-to-noise ratio for both sides.
All that being said, I have to say that I’m not entirely opposed to the alternative approach of folding in neos-ui with neos-development-collection. There are some strong arguments for it:
Cross-Cutting changes would be much easier to implement. Especially if our mission is to disentangle the boundary issues between Neos.Neos and Neos.Neos.Ui, this would (paradoxically) be much easier to do, if they’d live in the same repository.
Running E2E tests on every change may be a good thing. Currently, we do not recognize if a change in neos-development-collection breaks the UI, unless a new PR in neos-ui is opened that triggers an E2E test run. We had multiple such incidents in the past, and of course the nature of this issue poses the risk of such defects falling through and being released to the public. However, there’s cost involved with this: The E2E tests are a delicate thing, often false-negative and quite difficult to maintain. So, the cost would be again a decrease of the signal-to-noise ratio for most PRs in neos-development-collection, and a lot of wasted compute power for false-negative runs and subsequent re-runs. The upside would be a better detection of UI-breaking bugs in the core.
There would be less confusion about where to open issues. From the outside it is hard to judge whether a bug needs to be reported in neos-development-collection or neos-ui. neos-ui is the less prominent repository of the two, but most end-user-facing bugs need to be reported there. Occasionally, we move issues around, because we find they’ve been reported in the wrong place. We must stay alert about this problem and make sure to check new issues in both places. A unified repository would solve this problem for good.
Our communication & review practice may actually improve. If we’d all be looking at the same repository all the time, chances are each individual maintainer will engage with issues & PRs they would otherwise have overlooked.
Long story, short: I do not have fully conclusive reasoning to offer. I believe both approaches have their advantages and disadvantages, and we need to make a decision. I don’t know if it’s too early for this, but maybe, or eventually we should put this up for a vote:
Q: How shall we approach step 2 in the above roadmap?
- Establish a
neos-ui-development-collection - Merge
neos-uiwithneos-development-collection - Stay with status quo
(Provieded, of course, we decide collectively to proceed with the roadmap in general)
Wdyt?