[Aust-NZ] Initial Proposal - [was Finding a way forward - GeoNetwork ... ANZLIC Profile]

Mon May 26 10:32:05 EDT 2008

Thanks all for moving this discussion along.

On the topic of Web2.0 at Where2.0 conference last week, ESRI and
Google made a joint announcement stating a partnership to start
indexing spatial data and spatial web services on Google search
technology. The implications of this are huge from the perspective of
the industry as a whole. This opened a lot of questions about the
place of OGC Catalogue Services.

But Geonetwork already spits out GeoRSS which can be indexed by
Google's search engines. The other thing to look into for development
of GeoNetwork is the GeoSiteMap, a spatial extension to SiteMap which
allows better indexing of a website for online search purposes.

There were a number of other important announcement -- hope to give a
talk at Geoscience Australia upon return to OZ next week.

Cheers
Shoaib Burq

On Mon, May 26, 2008 at 4:57 AM, Cameron Shorter
<cameron.shorter at gmail.com> wrote:
> Seems like I wrote my previous email (on the bus on the way home) in
> parallel with Bruce.
>
> Some specific comments inline.
>
> Bruce Bannerman wrote:
>>
>> Finding an Open Source process that will work for GeoNetwork - ANZLIC
>> Profile will take a bit of trial and error to get right.
>>
>> We may not be able to treat it as a traditional Open Source Project as
>> there is a need to support ANZLIC involvement in the process.
>>
>>
>>
>> Many of the ideas here have come from Karl Fogel's book "Producing Open
>> Source Software, How to Run a Successful Free Software Project" (
>> http://producingoss.com/ ). This is an enlightening read if you have the
>> time.
>>
>>
>>
>> Below is a random collection of thoughts that needs further work. 
>> We need your input and experience to flesh out these ideas.
>>
>>
>> _Working with the GeoNetwork Community_
>>
>> We are not developing a project from scratch.
>>
>> We are contributing to and customising an existing OS Project, GeoNetwork.
>>
>> Therefore, whatever we want to get into GeoNetwork will have to be worked
>> through the GeoNetwork community and GeoNetwork Project Steering Committee.
>>
>> The GeoNetwork Community are not going to want to include all of our
>> changes at face value. To get them included will require a number of our
>> developers to work *within* the community,
>> contribute to the project and over time *earn* credibility that they know
>> what they are
>> talking about.
>> Simon and Byron have obviously been very successful at doing this and we
>> could learn from their examples.
>>
>> We will also need to be sensitive to the GeoNetwork community and by our
>> actions make it clear to them that we are not trying to hijack their
>> project, but act as good community members.
>>
>
> Yes, we do need to be sensitive to the Geoserver community and the open
> source software development process is slightly different to normal - but
> I'm confident that it is something we can work though, especially if we
> include people with Open Source experience in the decision making parts of
> our team.
>>
>> 
>>
>> _How can we get the work done?_
>>
>> This will provide some challenges for government organisations, where
>> development work is typically project based with defined deliverables. Some
>> initial ideas on how we can engage with the community and get work done:
>>
>> - Architects and Senior developers could start subscribing to the
>> GeoNetwork mailing lists  ( http://geonetwork-opensource.org/ ) to observe
>> how the community operates. When they
>>  feel comfortable with the process they could start contributing to
>> discussions.
>>
>
> All Geonetwork development teams should have at least one representative
> monitoring key email lists.
> However, there is a fine line between being informed, and being swamped with
> information that is not understood. A program manager should not need to
> become an expert in Software Development processes in order to make
> decisions. You hire a Software Architect or Engineer for that.
>>
>> - For some of our permanent developers, we could start setting
>> performance goals relating
>>  to GeoNetwork contributions and providing work time for this to occur.
>> These goals
>>  could possibly relate to a specific number of commits being accepted by
>> the community.  The work may or may not be explicitly AP related.
>
> Software development performance goals are very easy to fudge, and as soon
> as you tie pay scales to metrics, the metrics become meaningless.
> Lets put this point to the side for a bit.
>>
>> - For those of us who do not have permanent developers, we could explore
>> Cameron's idea
>>  of engaging specialist consultancies to do some of this work for us. We
>> could treat  this as *product support* with an appropriate annual fee. Over
>> time these consultancies  would also need to build up the required rapport
>> within the GeoNetwork community and be  available as a resource to use to
>> get our future customisation done.
>>
>> - I'm interested in other suggestions as well here.
>>
>>
>>
>> _How do we prioritise AP work_
>>
>> Ideally, we'd be able to come up with a list desired improvements, assign
>> a priority
>> and work through them one by one.
>>
>
> You missed "estimate cost of features".
>>
>> In practice, some organisations will have an urgent itch to scratch. If
>> they have the resources to fund (and community accepted developers to
>> undertake) that work, they should be free to do so.
>>
>>
>> How do we establish the list of priorities, determine if it is required
>> and assign a priority?
>
> I suggest "money=votes". It is the Open Source model of Meritocracy. The
> more you contribute, the more say you have.
>>
>> We have a set of priorities in the September workshop minutes last year (
>> http://www.osdm.gov.au/Metadata/GeoNetwork/Committees/default.aspx ) . Is
>> this list
>> being monitored and under active review?
>>
>> What processes do we need to go through to coordinate, review, monitor and
>> accept additions to this list?
>>
>> Who should be on this review panel and who has the responsibility of
>> liaising the requirements with the appropriate people in the GeoNetwork
>> community.
>>
>> What mailing lists should be used to coordinate this work?
>>
>>
>> 
>>
>> _How do we manage AP code development_
>>
>> It appears that Jeroen Ticheler has been successful in his proposal to
>> allow sandpit development within the GeoNetwork subversion revision control
>> environment (is this correct Jeroen?).
>> This is the obvious place to do our development work, feeding regular
>> changes back
>> into the main truck version when appropriate and accepted.
>>
>> Do we need an AP developers list, or would the geonetwork-devel list be
>> more appropriate?
>>
>
> Stick with geonetwork-devel until it gets too busy and another list is
> justified.
>>
>> What do we do for bug tracking?
>>
>
> Use geonetwork's bug tracker, possibly assigning a different module.
>>
>> What do we do for packaging, automated testing and functional testing?
>>
>
> Relatively minor technical issue with a number of solutions.
>>
>> How do we determine what goes into each release of GeoNetwork ANZLIC
>> Profile and enforce the practice of release early and release often?
>>
>
> Again, there are a number of software development methodologies that can be
> used to address user desires. Each come with different advantages and
> disadvantages, trading off quality, turn around time, cost, etc.
>>
>>
>> I leave this here. Hopefully there is enough meat to pick to pieces and
>> then build on.
>>
>>
>> I look forward to hearing some more constructive comments.
>>
>>
>>
>> Ben, do you have any comments from an ANZLIC perspective that may need to
>> constrain some of the ideas to come out of this?
>>
>>
>> Bruce Bannerman
>>
>>
>>
>>
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Aust-NZ mailing list
>> Aust-NZ at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/aust-nz
>>
>
>
> --
> Cameron Shorter
> Geospatial Systems Architect
> Tel: +61 (0)2 8570 5050
> Mob: +61 (0)419 142 254
>
> Think Globally, Fix Locally
> Commercial Support for Geospatial Open Source Solutions
> http://www.lisasoft.com/LISAsoft/SupportedProducts.html
>
> _______________________________________________
> Aust-NZ mailing list
> Aust-NZ at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/aust-nz
>