In regards to the review of the items. What me and Chris discussed was that after the initial item was submitted it would have the initial review and basic specification flushed out. At this step the decision would be made if the road map item was in or out of feature scope for the GeoNode project, if outside of scope the ticket would be closed. I think for the technical feasibility analysis this should happen at the technical specification stage. If it is decided that the item is technical impossible, or excessively difficult, then it should be tabled and marked as this - however we shouldn't necessarily throw it out because some technical solution to the problem may present itself in the future.
----
Galen B. Evans
Disaster Risk Management
Latin America & The Caribbean
Sustainable Development Network (SDN)
World Bank
1818 H St. NW 20433
Washington, DC 20433
Sebastian Benthall ---06/15/2010 11:57:57 AM---On a related note: Now that we have this process for filling out roadmap items, that raises
 From: | Sebastian Benthall <[email protected]> |
To: | [email protected] |
Date: | 06/15/2010 11:57 AM |
Subject: | Re: [geonode] Roadmap process |
Sent by: | [email protected] |
| |
| |
On a related note:
Now that we have this process for filling out roadmap items, that raises really important question for the developer community:
* What processes should be in place to allow for the necessary technical review of these roadmap items? Any given roadmap item may or may not be technically feasible and could fit into the stack (or not) in any number of ways.
* Where should technical specifications go? David and I have discussed setting up the developer documentation at something like geonode.org/dev once we get the server set up. Does that work for everyone?
* Where should feature specifications go? Are they appropriate for the main geonode.org website? So far, for historical reasons, I've had them on a geonode.org Google Apps account (yet another place for project documents--one that we should probably cut out of our system)
On Tue, Jun 15, 2010 at 10:21 AM, Chris Holmes <[email protected]> wrote:
- 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.
--
Sebastian Benthall
OpenGeo - http://opengeo.org
