Drupalcon Chicago - Keynote - Dries Buytaert
Dries kicked off another Drupalcon today by giving his keynote presentation to the community. If you missed it then you can view it on the Drupalcon website but read on for my summary and thoughts.
Dries has been doing these keynotes for a while now, and every one gets better and more polished. Today's was no exception. Dries summarised the process of Drupal 7 development and suggested changes and improvements to the Drupal 8 development workflow. He also outlined some of his priorities for Drupal 8.
In the keynote at Drupalcon Chicago, Dries pulled out several good things that came out of the Drupal 7 cycle including, test driven development, development snapshots and the usability team (among others). I think that the most significant here is the test driven development. With the Drupal core getting bigger and bigger and adding more and more features it is increasingly important to know when we've broken something, small changes can have wide implications, especially in a large, complex system like Drupal. But, there is a risk here: that we become too test focused, and if the tests are passing then the patch must be good. We need to be careful to write useful tests that actually work and ensure that we keep manually testing things too.
Dries highlighted an important statistic:
30 people contributed 50% of changes to Drupal 7. But there is still a huge tail of over 900+ contributors that added or changed something. Still this statistic doesn't capture the hard work of the people who write documentation, or test patches or do other work that doesn't result in a code change in core.
Dries went on to talk about the changes that he'd like to implement to the Drupal 8 development cycle. This was possibly the most interesting part of the keynote, Drupal is transitioning from a small project to a larger project and the community has to re-organise to accommodate that. Dries announced that Drupal 8 was open for development today (as soon as he could figure out how to create a branch in git!) And that we'd be shifting to a different model for getting changes into core.
Drupal 8 development workflow
Dries outlined a 'lieutenant workflow' that he'd like to use for core development going forward. Certain 'initiatives' would form and be organised by 'initiative leaders'. They would work in a branch of core to create a new feature or add something significant. Only after the branch passed certain criteria would the branch be merged into the main-line branch. The criteria to judge a branches readiness included: performance, accessibility and documentation. I think this a really good thing, and possibly the most exciting thing about Drupal 8 development. It should cut down on the number of monstrously long issues and reduce the amount of re-rolling. It will also enable much more long term planning and development. You can get work into a branch, and not have to worry about it being 100% perfect, because it can be fixed up later.
Also of huge significance was Dries' wish to keep core to a maximum of 15 critical issues at any one time. This will have ramifications for the feature branches, and whether they get included into the main-line branch or not, but more importantly means that Drupal 'HEAD' will be reasonably stable all the time.
Taking the initiative
Dries then went on to outline his thoughts on what the first initiatives should be, the two major ones are: Configuration management and Content staging. These are the major pain points of most sites that we work on today, how do we move our configuration around and how do we move our content around. Drupal 8 will solve these problems, if the community can come up with a solution. After all, all this is just talk unless someone actually comes up with an idea of how to do this and someone else writes the code.
The Drupal ecosystem
Dries finished by talking about how we need an amazing ecosystem around Drupal to really push it forward into new markets and satisfy the existing one. We need to talk the right talk and have the right tools available to be the best community we can be, so that we can engage with business, or individuals on their level. Dries suggested that if we didn't have this, and if it wasn't better than our competitors then Drupal would die!
There's going to be a lot to discuss at Drupalcon over the next few days...