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.
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/devonce 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 <cholmes@opengeo.org> 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
could not decode message
could not decode message
One other thing to note, Galen and I and anyone else interested will be using this list to discuss roadmap items, to keep that process open. Eventually we'll probably split up lists, have one devoted to development, but while we're still a small group and list traffic is relatively light we'll just discuss everything on here. On 6/15/10 10:21 AM, Chris Holmes 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.
Cool. A few questions: * Have you guys moved all the earlier roadmap stubs from this page already? If not, which ones are missing? http://projects.opengeo.org/CAPRA/wiki/RoadmapStubs * If that's done, then I'll remove these pages from the Trac wiki http://projects.opengeo.org/CAPRA/wiki/RoadmapIdeas and update it with information you've posted here and to Google Code. * I'm a little concerned now about the proliferation of project management infrastructure around GeoNode. Currently, a GeoNode developer who is also interested in the roadmap needs three different accounts: GitHub, Trac, and now Google Code. There are three different project wikis, three different issue trackers. I'm ++ on trying out the google code workflow, because I think it's a good call that it's more accessible to non-techies than Trac or Github. But as we work on community building around GeoNode, I think we need to stay conscious about how we are splitting/replicating/maintaining our community resources and keep the discussion alive in the public channels. On Tue, Jun 15, 2010 at 10:35 AM, Chris Holmes <cholmes@opengeo.org> wrote: > One other thing to note, Galen and I and anyone else interested will be > using this list to discuss roadmap items, to keep that process open. > Eventually we'll probably split up lists, have one devoted to > development, but while we're still a small group and list traffic is > relatively light we'll just discuss everything on here. > > On 6/15/10 10:21 AM, Chris Holmes 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