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.
Proposal: Add a community testing period to each major Drupal release, before marking it as the recommended stable download.
Currently on Drupal.org, we recommend the very latest release version of Drupal core as the recommended download. But, it often takes Contrib and Docs much longer to catch up to the point where the system is stable and easy to use from an end user (site builder) perspective. Novice or less skilled site bulders who do not realize this and arrive "too early" get extremely frustrated as a result. Contrib developers are placed under extreme stress to have their modules ported as soon as possible, often long before they are ready to do so and with issue queues clogged by angry demands from frustrated users (instead of useful issue reports by more advanced users). Often by the time many users are able to work with the new release to build and upgrade sites, we are halfway through the next major release cycle. This makes it hugely expensive or impossible for many organizations to keep up. Finally, fixing bugs in the new release is very painful due to the necessity to freeze API changes and have strict backporting rules.
This problem causes a great deal of pain and conflict community-wide.
Proposed Solution Summary
This solution is based loosely on the very successful Debian Linux model. Please see the (brief) introduction to this approach at http://wiki.debian.org/DebianReleases#Introduction if you are not familiar with Debian stable/testing/unstable .
To implement this kind of "testing" release for Drupal would be laregly semantics and rethinking how we refer to releases on drupal.org. It would not require extra work or compromise from anybody, nor changes to existing workflow or versioning. In fact, it improves life and reduces stress for contributors.Read more
[ EDIT, Feb 24th: This thread is now retired. The discussion has continued with a proper proposal at: http://groups.drupal.org/node/212648. Please go there and review that proposal instead. ]
This was originally a very off-topic and long-winded post on http://drupal.org/node/1366940. That version was edited for brevity and for lack of a better place, I'm posting the longer op-ed piece here. Following discussions there regarding Drupal release cycles, and the idea of bugfix / stability releases every second release, I wanted to add these points about the silent majority: The users out there, and their needs.
I'm arriving late for the party here, but I'd like to add my $0.25. I'd like to remind everyone of the giant elephant in the room that hasn't yet been addressed: The 99.9% of the Drupal community that is made up of site builders, and end users (those people who actually pay for all of us to make a living by investing in sites that are built using Drupal coreand mostly a whole bunch of contrib modules).Read more
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?
So we're this close to an alpha for the Media module (for d7). There are only a few outstanding critical alpha-blocking issues that need to be resolved. I'd hoped to have it today, but it looks like it'll probably be Monday.
Next week is the time for you to jump in if you're interested in developing for the project! It's been loads of fun, from the initial discussions and plans over a year ago with arthurf, dopry, drewish, Roger López, myself and others, to fantastic core Drupal 7 integration of stream wrappers by pwolanin and GSOC student jmstacey, to some powerhouse #d7ux magic by mverbaar and Jody Lynn, to the latest overhaul introducing Media fieldable entities (with an eye for core Drupal 8) and WYSIWYG integration by JacobSingh and dipen chaudhary, with some potential upcoming fine-tuning from jQuery guru dmitrig01.
If you're interested, join us in IRC at #drupal-media. After giving the module a spin (you'll need Drupal 7 Alpha 1, Media, Styles, and WYSIWYG + CKEditor, and optionally Media: Flickr and/or Media: YouTube), you should subscribe to the Issue queue. (You can also see recent screenshots at AaronWinborn.com.)Read more
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.Read more
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:
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.Read more
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:
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?Read more
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.Read more