As this is an open source project, we should probably let go of some of the more mundane project principles :-), so:
- 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.
- 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 features are most important to us
- Which features are most attainable (link to gap)
- Which features need to be worked on by core team, in what order
- Which features need to be coordinated by core team, worked on by others, in what order
- Which features 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.