[OSGeo-Discuss] Open Source development metrics

[Landon Blake]

Bruce,

 

I agree with Puneet. In this scenario it would make more sense for the
organization to maintain their own fork of the code to which
improvements can be made. This really doesn't cause problems for the
parent of the fork as long as there is an established process and some
honest effort made to integrate the best of the improvements back into
the parent code base.

 

This is actually how OpenJUMP works. There are only a handful of
developers that actually work on the parent code base. Most of our
contributors maintain their own fork, but siphon back improvements to
the parent.

 

Landon

 

________________________________

From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of
Bruce.Bannerman at dpi.vic.gov.au
Sent: Wednesday, May 28, 2008 12:00 AM
To: discuss at lists.osgeo.org
Cc: Aust-NZ OSGeo
Subject: [OSGeo-Discuss] Open Source development metrics

 


IMO: 


An issue has come up recently on the OSGeo-AustNZ list that I'd
appreciate some feedback from our wider OSGeo Community. 


The context of this issue is that we are exploring ways to support
development of the GeoNetwork ANZLIC Profile. 

In particular, we're looking at options that allow permanent staff to
contribute to ongoing OS development work outside of normal Project
based development with its well defined deliverables and timeframes. 



In Australia within the public sector and also in many larger private
organisations there is a Human Resources process in place that is based
on Performance Management. This process allows either staff or managers
to initiate discussions that allow for goal based work to be undertaken.


In principal both parties agree to a set of goals. If the goals are met,
it contributes to the employee's remuneration review.


What I'm trying to find are some examples of generic metrics that are
meaninful to Open Source development methodologies. They must be 
specific, meaningful and measurable. 


For example, we could look at measures such as: 


"Get feature X accepted into the trunk of GeoNetwork by June 2009" 


However this is probably unrealistic  as to do this the developer will
have to have existing credibility within the community and there may be
good reasons why the community does not want to have 'product X'
included. 


Does anyone have any examples that they use or thoughts on the above? 


I do understand that metrics can be abused, may be meaningless and may
not be the best way to handle this, however we have to start somewhere. 



We have a window of opportunity to get some more developers working on
OS projects as the Performance Planning cycle re-starts shortly and I'd
like to help our developers get some constructive ideas to take into
their sessions.  



Bruce Bannerman




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.

 

 

 



Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20080528/b1189668/attachment-0002.html>