Landon, on the other hand, following that logic, if forking is advisable, it will keep on growing, with new forks, new forks-of-the-fork, and so on. The energy needed to keep all that project "forkhood" somehow synchronized is not only honest, but discouraging and efectiveless. I don't see neither how a user can simply make a proper decission among a fork-hood. Not everybody is expert enough to understand differences, or has enough time to download several forks and compare them (continously in time). Are really all the differences among forks impossible to reconcile, using that 'honest effort'? ;-) Miguel
________________________________ De: [EMAIL PROTECTED] en nombre de Landon Blake Enviado el: mié 28/05/2008 16:27 Para: OSGeo Discussions Asunto: RE: [OSGeo-Discuss] Open Source development metrics 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 12:00 AM To: [email protected] 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.
<<winmail.dat>>
_______________________________________________ Discuss mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/discuss
