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

[Rob Atkinson]

I am putting together some Use Cases to describe the needs the community has
of a metadata management tool, specifically the ability to "compose"
metadata artefacts like ANZLIC data set descriptions, data product
specifications (cf ISO 19131 and the EU INSPIRE methdology, and service
profiles) from more reusable lower level artefacts, like reusable data
access agreements, data quality statements, data access service
descriptions.

We will be publishing a sample based on some real-world deployed data access
services (time series water resources observations) at the end of the month.

In general, we should avoid making premature architectural decisions with
some real world data access services as test cases, otherwise we risk
building a tool to solve the wrong problem.  We desperately need some
"framework data set" examples, as well as  "myBusinessData" examples for how
a framework data set can be used to underpin a business application and its
derived data sets.


Rob Atkinson
(wearing a SISS project hat)

On Mon, Jun 2, 2008 at 11:49 AM, <Bruce.Bannerman at dpi.vic.gov.au> wrote:

>
> IMO:
>
>
> I'd like to wrap this thread up soon and put together a summary of the
> discussion into a proposal for a way forward for GeoNetwork ANZLIC Profile.
>
>
> I'd like to start work on this summary next week, starting 10th June.
>
>
> Where should this proposal go, once it has been subject to our peer review?
>
>
> I suspect that it may be appropriate to go to the ANZLIC Council for
> approval, however this needs debate.
>
>
>
> I have been contacted by several people off line and understand that they
> have not been in a position to respond due to work commitments.
>
> We have one more week for comments, please take the time to do so if you
> are able.
>
> I'd like to read more from the ANZLIC community.
>
> I also know that Ben and Jeroen would like to add additional thoughts.
>
> Simon, I'd also appreciate reading your additional thoughts on what would
> work.
>
>
>
>
>
> Bruce Bannerman
>
>
> __________________
>
>
> 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.
>
>
>
>
> _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.
>
> - 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.
>
> - 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.
>
> 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?
>
> 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?
>
> What do we do for bug tracking?
>
> What do we do for packaging, automated testing and functional testing?
>
> How do we determine what goes into each release of GeoNetwork ANZLIC
> Profile and
> enforce the practice of release early and release often?
>
>
>
> 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
>
> Notice:
> This email and any attachments may contain information that is personal,
> confidential,
> legally privileged and/or copyright. No part of it should be reproduced,
> adapted or communicated without the prior written consent of the copyright
> owner.
>
> It is the responsibility of the recipient to check for and remove viruses.
>
> If you have received this email in error, please notify the sender by
> return email, delete it from your system and destroy any copies. You are not
> authorised to use, communicate or rely on the information contained in this
> email.
>
> Please consider the environment before printing this email.
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/oceania/attachments/20080602/c593b0d8/attachment.html>