[Aust-NZ] Initial Proposal - [was Finding a way forward -
GeoNetwork ... ANZLIC Profile]
Cameron Shorter
cameron.shorter at gmail.com
Mon May 26 07:57:48 EDT 2008
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
More information about the Aust-NZ
mailing list