Aside from kind of wishing that this document was somehow combined with the roadmap itself [1] (in order to prevent page creep, it may just be my preference) it looks like a good start.
I decided to stay out of the huge thread from a few days ago, but since I'm already writing, I'd like to say that I'd like a more transparent roadmap, mainly for selfish reasons. I want to get a sense of what's planned, and what is going into a release _before_ it's been released. Every release has bug fixes, but most of our releases have a compelling story. 1.7.0 gave us, among much else, a new RasterSymbolizer that worked, yet I only found this out after it was released. Speaking as someone who wishes to spend a good chunk of his time here working on documentation, I would like to keep more in lockstep with the developers, so that docs can be planned and written _before_ the software is released. The way things are working for 1.7.1 is a good start (as in, I think I'm aware of what's new and exciting, and am writing accordingly). [1] http://geoserver.org/display/GEOS/Roadmap Thanks, Mike Pumphrey OpenGeo - http://opengeo.org Justin Deoliveira wrote: > Hi all, > > Out of the recent discussion I have decided to come up with a draft of what a better community-centric process might look like. I have written it up here: > > http://geoserver.org/display/GEOS/Roadmap+Process+Draft > > It is by no means complete and needs to be refined based on everyones feedback. > > -Justin > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
