Improvements to core

The twin deep-engineering Core Initiatives of Configuration and Web Services have been taking a long hard look at Drupal's basic, underlying architecture of late. We're swirling around three fundamental pieces that should, we believe, revolutionize Drupal core and Drupal development, allowing for a quantum leap in Drupal's capabilities. (Excited yet?) The catch is, we have to get these right. More than that, we need to nail these. For that reason, we're trying to solicit wider feedback on a few key architectural questions. I have tried to summarize the situation and the challenges below, and invite informed, insightful feedback from the community.

The three cornerstones of this new approach are Configuration, Context, and Plugins. All three are things that Drupal core does not, in fact, provide in anything resembling a useful way. We need to get all three of them into core, however, and they need to work together well. The problem is that there are very good reasons for all of them to require one of the others first, which creates a circular dependency. We need to sort out that problem before we can get building.

I'm a bit late in getting this out, but such is life when moving and attending a wedding. :-)

We had a good Core Conversation on Butler in Chicago. Sadly Dries ended up not being able to attend, but just about everyone else was on board with the roadmap. The roadmap itself hasn't changed much since Copenhagen, but things are moving again. There was also considerable talk of very, very interesting tie-ins to the configuration/deployment core initiatives, as having a more robust pre-database configuration option should help resolve a lot of the challenges we were looking at.

Slides from the presentation are attached below.

Next steps:

Now that some developers and companies are responding to Dries' Drupal 7: let's get it done, it's likely they will give more priority to fix and/or review beta blocker issues. So, it would be useful a clearer criteria about what's a beta blocker, and better consistency between the beta blocker list and the beta blocker tag.

The list in Drupal core improvements (6 issues) is more complete but updated every one or two weeks, and the tag in the issue queue (3 issues) is currently not complete but more real-time.

If we add tags step by step following the beta blocker criteria mentioned in the list, then the cumulative results are now the following for open, not fixed, critical D7 issues:

I would like to start a discussion about staging in Drupal 8...

By staging, I mean having a test site, where you can make changes and test them out, before pushing them to the production site and making them live for everybody.

I wrote at http://acquia.com/blog/drupalcon-buzz-can-we-say-r-word-drupal-8 asking questions about whether we need to collect together various roadmaps and plans in a central place to communicate a "plan" to developers and Drupal users.

What do you think? How could we make that work and keep it up to date throughout a core development cycle? Do you think that would be valuable or a distraction?