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

[Bruce.Bannerman at dpi.vic.gov.au]

IMO:

Hamish,

I see this particular aspect applying to permanent employees of public and 
larger private organisations (though particular aspects could also 
possibly be applied to support contracts).

We need to find meaningful measures that Managers or Employees can take 
into the Performance Planning sessions to discuss the need to undertake 
GeoNetwork work. It is a two-way process and can be initiated by either 
party.


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.


Any thoughts on measures are appreciated.



Bruce Bannerman







Hamish <hamish_b at yahoo.com> 
27/05/2008 01:09 PM
Please respond to
hamish_b at yahoo.com


To
Aust-NZ OSGeo <Aust-NZ at lists.osgeo.org>, Bruce.Bannerman at dpi.vic.gov.au
cc

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






Bruce wrote:
> However, in the public sector and also in many larger private
> organisations there is a Human Resources process in place that
> are based on Performance Management.
...
> As to specific metrics that can be used, I'm open to
> suggestions. They must be specific, meaningful and measurable.

there is nothing too wrong with outcome based funding, they want to know 
thier money is well spent even if they are not an expert in the field. but 
I think it is wise to avoid metrics which micro-manage and focus on 
deliverable results instead.

e.g. assesment by number of lines of code committed per day or number of 
commits is very useless. I can commit each time I save the file or wait 
and do one big commit when I have finished the module I am working on; SVN 
likes big atomic commits, while I assume a CMS like git likes many smaller 
ones, more often. If I want more lines of code I can adjust indent rules 
or write less efficient C ...

better is to have contracts that say "we will pay you X dollars to 
impliment Y feature in a functional and usable way, and require you to 
submit it to upstream with documentation and examples and assist with any 
merge issues that arise therein." rather than get hung up on the details 
of lines of code or commits.


2c
Hamish




 



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/aust-nz/attachments/20080527/65c09a8b/attachment.html