I (that means I. Disclaimer: this is my idea. blame me.) would like to see -- Views in core. Without Merlin burning out. -- more shops contributing to core. The biggest deterrent currently IMO is that their work might or might not be accepted and even if gets in, it might be two years before they can use on a client site. -- the security team to only deal with releases that have automated testing so they have a good chance of their patches not breaking core. To achieve all this in one plan, I would like first to ask everybody who wants to contribute core to go to the Views queue and help out! Support requests, bug reports, many things are doable without being the Grand Master of Views. This has immediate returns in fixed bugs, or just a little bit less immediate with less load on Merlin resulting in better Views. But it does not take two years to get deployable results, not at all. And then, if we have brought down the Views queue to a managable size, then we should write tests for Views. Again, this is something a lot of people should be capable of even without knowing the innards of Views and usable right now even with Drupal 6 -- simpletest is backported. Once we have a lot of tests, we should commit them to core along with skeleton code that makes the tests pass. This is a radical but logical change to our core development model. Hopefully this can lead to many smaller patches striving to replace smaller pieces of skeleton code with real instead of few gigantic patches trying to get some major part of Views in core. We do not do anything else for Drupal 8. No other major API changes just tests for Views which are immediately and easily backportable to Drupal 7, once again allowing for immediately deployable code. Obviously there will be changes as our old and hardwired modules get partially replaced by Views. However, this plan would hopefully allow for a short Drupal 8 cycle instead of a year plus long one and when Drupal 8 gets released, the security team has an easier work. Another side benefit is that I can see people jumping over Drupal 6 completely with the D7CX movement quickly putting a deployable (I seem to like that word) Drupal 7 on the table. So relatively quickly (but still it gets more than two years) deprecating D6 wont be as bad. Also, as Drupal 8 won't break APIs as bad as usual, the contrib authors will have an easier job of maintaing D7 and D8 branches. Another benefit is that the usability folks can work on a stable platform so Drupal 8 can be even more usable than Drupal 7. I should list the drawbacks here but aside from a few crazy core developers (like little me) being a bit frustrated for being in a soft API freeze for Drupal 8, I can't see any. I will certainly be less frustrated over not being able to overhaul everything than I would be to being able to but working almost in isolation. There is a huge chasm between real world sites and core development and this would allow us to bridge.