One of the goals we've talked about for the GeoNode project is to open 
up not just the software development but also the funding/roadmap 
process.  We want the vision to be collaboratively built, meeting a 
number of specific use cases by making a strong and flexible core.

Galen and I last week worked on a little process to open up the filling 
out of the roadmap.  The first goal is to open up to the web all the 
ideas that have been talked about in various conversations, so that 
everyone can see the next steps for GeoNode and the potential future 
directions.  This should make it much easier for potential funders and 
contributors to see where they can help out.  The second even more 
important goal is to open the roadmap for anyone to submit an idea and 
get it on the roadmap, so we all shape the future together.

We started the roadmap page, and got a few initial items on, see 
http://geonode.org/roadmap/

It has a link to submit a new roadmap item, you just create an issue at 
http://code.google.com/p/geonode-roadmap/issues/entry  There you will be 
prompted for the pieces to fill out and then either Galen and I will 
guide through the process of getting on to geonode.org

The basic workflow that we do is at 
http://code.google.com/p/geonode-roadmap/wiki/RoadmapWorkflow  If anyone 
else wants to help us we can make you an admin on that project as well. 
  The issue tracker is just to track roadmap items, for now we close the 
issue when it gets on to the web site, like 
http://geonode.org/roadmap/upload-non-georeferenced-maps/

Once we get a lot of roadmap items I'd like to flesh out another set of 
cross cutting views of the features, organized by use case.  So we could 
have GeoNode for Urban Planning, which spells out how a GeoNode could be 
used, and what roadmap items would help it.  And I'm hoping the ITHACA 
team can help us flesh out GeoNode for disaster response.

Having this roadmap in place should allow us all to more easily approach 
funders, and be ready to turn an item in to a feature spec, a technical 
spec, an estimate, a terms of reference and a funded contract.  If we do 
this right I think it could be a great boon to all the underlying open 
source projects we rely on, as we are committed to improving the core 
technologies of each of them.  This is essential to our success, so the 
GeoNode is as flexible as possible, not a series of one of hacks.

Reply via email to