As this is an open source project, we should probably let go of some of the more mundane project principles :-), so:

1. No one should let the absence of a Roadmap right now hinder them in any way from starting to build or develop stuff they would really like to build or develop. Just don't hack drupal core, is all I'm saying.
2. No one should let the presence of a Roadmap hinder them in any way from building or developing stuff they would really like to build or develop. Just don't hack drupal core, is all I'm saying.

In making the roadmap we should consider

• Which functionalitiesfeatures are most important to us
• Which functionalitiesfeatures are most attainable (link to gap)
• Which functionalitiesfeatures need to be worked on by core team, in what order
• Which functionalitiesfeatures need to be coordinated by core team, worked on by others, in what order
• Which functionalitiesfeatures can be published as 'needed, who will work on it?' (Now I'm making it up as I go along)
• What kind of quality control we like to implement through development and testing principles (e.g. no core hacking, use cck+views when possible, helping others build modules is always better than building them)
• Which features are new to Drupal 6. Depending on how far in the future our own switch to v6 is planned, these features should probably not be built separately for Gnomepal. If we do incorporate such a feature, we should see if a module was incorporated into core and use that module to ensure a manageable upgrade path for us and for our users

The Roadmap should very concretely describe

• A first build
• What functionalities
• What modules
• What configuration
• What manuals
• (also: what specifically not to invest core team time in for the first build)

(My instinct is to take make this first one distinctly manageable and attainable)

The Roadmap should very vaguely describe

Second, Third, Fourth builds. A moment for switching to another version of Drupal.