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

[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







-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.osgeo.org/pipermail/aust-nz/attachments/20080526/4a657aa2/attachment.bin