DrupalCon Buzz - Can We Say the "R" word for Drupal 8?
by Peter Wolanin
If you are reading this and Drupal 7 is not yet released, pop over to the critical issue queue and roll, review, or comment on a patch before you go any further!
Ok, done? Drupal 7 is the top priority, but getting people together for the core developer summit stimulated (as intended) lots of excitement and discussion about the future of Drupal core code and what Drupal 8 could look like.
That brings us to the "R" word: roadmap. Drupal has never had a formal roadmap or specification for the changes that would go into a particular Drupal version, and I don't expect that it ever will. In many ways this has been very productive for the project in that it encourages newer contributors to feel that they have the power to jump in and make their own vision a part of core. However, there have been some spectacular (i.e. unfortunate) examples of effort that has been spent on features or rewrites that went nowhere, and some examples of APIs that have grown in an ad-hoc fashion and are either difficult to use or have different parallel implementations in different parts of Drupal core.
From the buzz of activity and discussion in San Francisco, however, there is clearly already a strong inclination towards making informal roadmaps among those at DrupalCon. I participated in or overheard several discussions at DrupalCon that lead or could lead to informal roadmaps for different sub-systems in Drupal 8:
- Can we bring consistency to all entity CRUD?
- Do we want a centralized notion of context in core?
- Can we build a more generic hierarchy API to be used for menus, books, taxonomy, etc?
- How do we provide a more generic and useful framework for search?
So perhaps we need to work together to aggregate these informal roadmaps in one place and (perhaps most critically) communicate to Drupal users as well as contributors an overall plan or direction when work starts on Drupal 8? We'd need to keep such a working plan updated so there is some common point of reference and so that it reflects the initiatives underway, as well as indicating which changes should be considered postponed or non-starters.
Would we (as a community) be more effective in undertaking big API cleanups - the grunt work - if they are documented as part of a plan? While there is some hope that using distributed version control tools like git will make it easier to undertake large-scale changes or cleanups, many of the top contributors have been using them for Drupal 7 already. Would we be faster or better at adding certain features? Would we be able to bring more new contributors to core if they had a clear picture of where one little patch fit into a larger architecture?
I don't have the answer these questions myself, so leave a comment here or get involved on http://groups.drupal.org/unofficial-drupal-roadmap to provide your $0.02.