Unofficial Drupal Roadmap

I have been writing up a white paper on how Drupal could work, but wanted to submit an initial and important first step. I know allot of people see comments as nodes being a major issue. Many want it, while others site potential problems with performance. Without comments as Nodes we have no code uniformity making any CCK features and Views features needing exceptions based on if its a node or if its a comment.

When a page.tpl.php file is generated all of the variables are populated with content. This includes all the regions, the css and javascript, and everything. Some of these are never used in some themes (e.g., $mission) and some are often rebuilt later like $styles and $scripts.

I propose we lazy load the content in these variables when the variables are called the first time which will typically be in the template files. Since lazy loading is a feature of objects it will mean these variables will be attached to objects.

So, in drupal 6 you theme would have:
<?php
print $styles;

My name is Matthew Pare and I'm a Co-Chair for the "Community and Core" track for Drupalcon Boston 2008. Over the last couple of weeks we have been planning and brainstorming to make Drupalcon Boston 2008 the best Drupalcon to date! One of our recommended track session topics is "Drupal.org and the Community" and since your viewing this post on the "Unofficial Drupal Roadmap" groups.drupal.org group I thought you would be excellent candidates for submitting sessions on the topic.

My name is Matthew Pare and I'm a Co-Chair for the "Community and Core" track for Drupalcon Boston 2008. Over the last couple of weeks we have been planning and brainstorming to make Drupalcon Boston 2008 the best Drupalcon to date! One of our recommended track session topics is "Drupal.org and the Community" and since your viewing this post on the "Unofficial Drupal Roadmap" groups.drupal.org group I thought you would be excellent candidates for submitting sessions on the topic.

What about implementing a roadmap as a wiki based on Drupal 6 battle plans? Or now we might want to shift to Drupal 7.

It would group the features/bugs by categories and include a list of contributors willing to work on each item. No item can be listed without having at least one volunteer interested in working on it. That way we won't waste time with items that no one is interested in, but people can get a better idea of what is planned in the future.

What about implementing a roadmap as a wiki based on Drupal 6 battle plans? Or now we might want to shift to Drupal 7.

It would group the features/bugs by categories and include a list of contributors willing to work on each item. No item can be listed without having at least one volunteer interested in working on it. That way we won't waste time with items that no one is interested in, but people can get a better idea of what is planned in the future.

I think this recent post on the devel list by chx would make a reasonable start for a roadmap:

http://lists.drupal.org/pipermail/development/2007-February/022353.html

I think this recent post on the devel list by chx would make a reasonable start for a roadmap:

http://lists.drupal.org/pipermail/development/2007-February/022353.html

Although actual implementation details are still forming around the pieces we are trying to implement for the Drupal 6 core i18n feature set (which will get shipped with Drupal 6 hopefully), we should define some goals which we aim for, so we see the target. Unless we work in the same direction, there will be no useable consistent i18n solution in Drupal core for people to build their sites on. So what is possible to accomplish in the Drupal 6 timeframe, and what will only be possible to implement in contrib modules?

Although actual implementation details are still forming around the pieces we are trying to implement for the Drupal 6 core i18n feature set (which will get shipped with Drupal 6 hopefully), we should define some goals which we aim for, so we see the target. Unless we work in the same direction, there will be no useable consistent i18n solution in Drupal core for people to build their sites on. So what is possible to accomplish in the Drupal 6 timeframe, and what will only be possible to implement in contrib modules?

I am willing to dedicate some real time and purpose to such a project. We will need a bit more organization form the top down though. I'm joining a couple of the mailing lists towards that end and i would really like to get the ball rolling on this. I use drupal privately and professionally and both would benefit immensely from this project. While I would love for such a project to be self sustaining (wiki or otherwise) i think it will require some early heavy seeding to get things going. Perhaps integrating "development time frame" as a field into project_issue module would also provide some structure to help make the "feature improvements" process more organic.

I am willing to dedicate some real time and purpose to such a project. We will need a bit more organization form the top down though. I'm joining a couple of the mailing lists towards that end and i would really like to get the ball rolling on this. I use drupal privately and professionally and both would benefit immensely from this project. While I would love for such a project to be self sustaining (wiki or otherwise) i think it will require some early heavy seeding to get things going. Perhaps integrating "development time frame" as a field into project_issue module would also provide some structure to help make the "feature improvements" process more organic.

Should it be a wiki roadmap, or maintained by one person?
How finegrained do we want to see the roadmap?
Can we facilitate contrib developers with roadmap features?
Do we need a roadmap module?

Should it be a wiki roadmap, or maintained by one person?
How finegrained do we want to see the roadmap?
Can we facilitate contrib developers with roadmap features?
Do we need a roadmap module?

Let's make that Roadmap..

Let's make that Roadmap..