Unofficial Drupal Roadmap

Problem Summary

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.

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?

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.

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.

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 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?