Most of the discussion on this issue has been around a web site / CMS for
project developers, but I want to mention the other side. If we think
about OSGeo.org as the front door to The Open Source Geospatial
Foundation, the look and feel of the site becomes really important.
Right now it appears that OSGeo.org is setup to accommodate developers
and keen users, which is an important goal. However, if OSGeo wants to
appeal to a wider audience, I believe that the website must become
clearer to navigate and read. <br><br>For example, when I go to the
web site, I should be able to read about the newest OSGeo news, but
what I see is "Current News", where the last news item is dated May 31.
Sure the actual recent news is available via the News link on the
sidebar, but what I'm getting at is there seems to be a confusing
presentation and a lack of consistency, which ultimately will scare off
fringe users / browsers / non-members. I would imagine the visibility
committee would like to avoid this.<br><br>I realize that the web
committee is addressing these issues and they deserve kudos for that.
Finding the balance between a developer oriented site and a friendly
web present is challenging, but it's important to consider both
functions.<br><br>IMHO,<br>Aaron<br><br><br><div><span class="gmail_quote">On 7/17/06, <b class="gmail_sendername">Allan Doyle</b> <<a href="mailto:adoyle@eogeo.org">adoyle@eogeo.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is it so important to move things to a common environment for<br>developers? Is the cost of doing that so high that it starts to cut<br>into development?<br><br>Jody's point about matching look and feel sounds like the more
<br>important one. If we work backwards, what end result are we looking<br>for? Surely not carefully lined up projects, all neatly tucked away<br>into a version control system with parallel file naming conventions,<br>variable naming schemes and so on. I'd like to see compatible binary
<br>packages for major platforms, ease of side-by-side installations of<br>components, etc. Basically the topics we were hitting on in the<br>OpenSDI list.<br><br>If projects do the proper copyright/IP management, then it should be
<br>ok to use any tools to do so.<br><br>Or am I missing something?<br><br> Allan<br><br>On Jul 17, 2006, at 17:37, Jody Garnett wrote:<br><br>> Hi Cameron, thanks for keeping discussion open and on the list.<br>
> Much nicer out in public even when difficult.<br>><br>> From my perspective I got a lot of work to do to get GeoTools ready<br>> and Collabnet is the last thing on my mind. I am way more concerned<br>> about what the standard Look and Feel ends up being for OSGEO
<br>> projects... because that I will match.<br>><br>> We origionally started using Confluence for the uDig project and<br>> looked into porting the content to Drupal. It really did not work<br>> and i would be sorry to say how much time we spent on it. It was
<br>> interesting how effective donating confluence is to open source<br>> projects is for Allisian....<br>><br>> Thanks for quoting the following page, the tables near the bottom<br>> were started by me to explain why GeoTools is not moving
<br>> to Collabnet at this time... which is not to say we are not hurting<br>> for resources (in the meeting to day we were talking about hosting<br>> builds on TOPP and Refractions servers).<br>>> This page is a good start:
<br>>> <a href="http://wiki.osgeo.org/index.php/Project_Infrastructure_Migration">http://wiki.osgeo.org/index.php/Project_Infrastructure_Migration</a><br>> So what I want is this:<br>> 1. Web LNF from the webcomm (who I have not had a chance to help
<br>> with until the geotools IP check is done)<br>> 2. Update my confluence sites to match<br>> 3. Keep tabs on CollabNet offerings, and how seriously intergrated<br>> LnF is as a requirement for OSGEO projects
<br>><br>> If the times comes to switch, and it may, it will be based on the<br>> least hassle for developers on the project. The performance of<br>> confluence<br>> on the codehaus is a trouble, and I can no longer export based on
<br>> the timeouts experienced (bleck).<br>><br>> One serious issue is that most of our navigation structure is based<br>> on parent child page relationships included in pages via macros,<br>> this is the kind
<br>> of thing that never translates well - even if the base content<br>> does. So I am really not going to give this much more thought until<br>> it becomes a problem. It is nice having CollabNet as an escape<br>
> avenue if needed.<br>><br>> All the best,<br>> Jody<br>><br>><br>><br>> ---------------------------------------------------------------------<br>> To unsubscribe, e-mail: <a href="mailto:discuss-unsubscribe@mail.osgeo.org">
discuss-unsubscribe@mail.osgeo.org</a><br>> For additional commands, e-mail: <a href="mailto:discuss-help@mail.osgeo.org">discuss-help@mail.osgeo.org</a><br>><br><br>--<br>Allan Doyle<br>+1.781.433.2695<br><a href="mailto:adoyle@eogeo.org">
adoyle@eogeo.org</a><br><br><br><br><br>---------------------------------------------------------------------<br>To unsubscribe, e-mail: <a href="mailto:discuss-unsubscribe@mail.osgeo.org">discuss-unsubscribe@mail.osgeo.org
</a><br>For additional commands, e-mail: <a href="mailto:discuss-help@mail.osgeo.org">discuss-help@mail.osgeo.org</a><br><br></blockquote></div><br><br clear="all"><br>-- <br>+--------------------------------------------<br>
| Aaron Koning<br>| Information Technologist<br>| Prince George, BC, Canada.<br>+--------------------------------------------<br>| <a href="http://datashare.gis.unbc.ca/fist/">http://datashare.gis.unbc.ca/fist/</a><br>
| <a href="http://datashare.gis.unbc.ca/gctp-js/">http://datashare.gis.unbc.ca/gctp-js/</a><br>+--------------------------------------------