> > 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. > Ok, cool. I guess we figure out whether or not its in scope via mailing list discussion. Perfect.
> 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. > Sounds good. > [image: Inactive hide details for Sebastian Benthall ---06/15/2010 11:57:57 > AM---On a related note: Now that we have this process for f]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*<http://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* <http://geonode.org/> website? So far, for > historical reasons, I've had them on a *geonode.org* > <http://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]*<[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/* <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*<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*<http://geonode.org/> > > The basic workflow that we do is at* > > **http://code.google.com/p/geonode-roadmap/wiki/RoadmapWorkflow*<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/*<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* <http://opengeo.org/> > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
<<ecblank.gif>>
<<graycol.gif>>
