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

Sun Jun 1 18:49:21 PDT 2008

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/35715f39/attachment.html>