Unofficial Drupal Roadmap
New Approach to Content Types.
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.
Lazy Loading Theme Variables
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;
Sessions on Drupal.org and the Community Wanted For Drupalcon 2008
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.
Wiki based on battle plans?
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.
devel list post
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
Defining a roadmap for i18n in Drupal 6 core
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?
What do we need?
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.
No activity - what do we do?
Right then, first questions
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?
Since there has been lots of dicussion on why Drupal should or shouldnt have a roadmap, lets combine the power of those who think we should offer some form of an unofficial roadmap and build it right here.
