Re: [OSGeo-Discuss] Open Source development metrics
Jody Garnett wrote: Try for a couple of the metrics you use when evaluating open source projects If a project or F/OSS developer has been around for a while, there are bound to be online metrics about it/him/her, for instance on Ohloh. Some examples: http://www.ohloh.net/projects/305 http://www.ohloh.net/accounts/blowagie Sure, this is just an indication based on an algorithm that takes many parameters into account, but indications such as increasing year-over-year development activity and maturity can't be faked. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
Just a word of warning; those sites get tripped up; you can see the history for geotools is missing because we just cleaned up our subversion repository a bit. Jody Bruno Lowagie wrote: Jody Garnett wrote: Try for a couple of the metrics you use when evaluating open source projects If a project or F/OSS developer has been around for a while, there are bound to be online metrics about it/him/her, for instance on Ohloh. Some examples: http://www.ohloh.net/projects/305 http://www.ohloh.net/accounts/blowagie Sure, this is just an indication based on an algorithm that takes many parameters into account, but indications such as increasing year-over-year development activity and maturity can't be faked. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
The following one is also useful: - http://cia.vc/stats/project/geotools For projects going through incubation these tools are a valuable resource in figuring out who changed what when. Jody Jody Garnett wrote: Try for a couple of the metrics you use when evaluating open source projects If a project or F/OSS developer has been around for a while, there are bound to be online metrics about it/him/her, for instance on Ohloh. Some examples: http://www.ohloh.net/projects/305 http://www.ohloh.net/accounts/blowagie Sure, this is just an indication based on an algorithm that takes many parameters into account, but indications such as increasing year-over-year development activity and maturity can't be faked. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
Jody Garnett wrote: Just a word of warning; those sites get tripped up; you can see the history for geotools is missing because we just cleaned up our subversion repository a bit. True: in my personal history, it's as if I have been inactive for years, but in reality all the CVS data disappeared when we switched from CVS to SVN. br, Bruno ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[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. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
IMO: Thanks for the comments Puneet, Actually, a variation on the above may be the best metric -- create feature X that we need in our organization and that works for us. That would allow your organization to determine what is meaningful for your organization first and for open source second. In other words, you would treat open source development no different from non-open source development. Open source would simply become a normal activity. Once feature X works for you, you could consider donating it to the open source community by whatever process that particular open source project has. Other metrics such as SLOC (source lines of code) or feature in SVN trunk are not only subject to abuse, they are also mostly meaningless. We want to avoid anything that could result in an isolated fork or branch. This is a danger with this approach. However, it has merit in that it would allow a developer to meet their performance criteria and concentrate on getting the customisation into the trunk in their own time. Bruce 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. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
On 5/28/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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. Actually, a variation on the above may be the best metric -- create feature X that we need in our organization and that works for us. That would allow your organization to determine what is meaningful for your organization first and for open source second. In other words, you would treat open source development no different from non-open source development. Open source would simply become a normal activity. Once feature X works for you, you could consider donating it to the open source community by whatever process that particular open source project has. Other metrics such as SLOC (source lines of code) or feature in SVN trunk are not only subject to abuse, they are also mostly meaningless. 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. ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
On 5/28/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: IMO: Thanks for the comments Puneet, Actually, a variation on the above may be the best metric -- create feature X that we need in our organization and that works for us. That would allow your organization to determine what is meaningful for your organization first and for open source second. In other words, you would treat open source development no different from non-open source development. Open source would simply become a normal activity. Once feature X works for you, you could consider donating it to the open source community by whatever process that particular open source project has. Other metrics such as SLOC (source lines of code) or feature in SVN trunk are not only subject to abuse, they are also mostly meaningless. We want to avoid anything that could result in an isolated fork or branch. This is a danger with this approach. Quite the contrary -- don't fixate on forking as a bad thing. Do what is good for your own organization. If it is of sufficient general interest, and if enough folks find it of use to them, it will get absorbed in the main branch anyway. Else, it will either die off (in which case it still served your own organization's purpose) or develop as a specialized branch. Very Darwinian. Forking is not a bad thing. I have no idea why it is viewed as such. Forking is one of the beauties of open source, brings diversity in the code base, and even ensures longevity. The ability to fork is what ensures that in open source there will not be any lock-in. The beauty of this approach is the open source is not treated as something special. It becomes as normal as non-open source software. However, it has merit in that it would allow a developer to meet their performance criteria and concentrate on getting the customisation into the trunk in their own time. Bruce .. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
Hmmm, I tend to strongly disagree here. Forking indeed can prevent a lock-in if that is becoming a serious issue in the project. Otherwise it just causes lots of duplication of efforts and dilution of energy into different forked versions. It also does not help the average user much in selecting what's good for him/her. I think that Ubuntu as a popular release is one of the proofs that too much choice does not help to reach the large crowd. By limiting the installed default software packages they quickly reached a huge user group. My 2 cents, ciao, Jeroen On May 28, 2008, at 12:01 PM, P Kishor wrote: Forking is not a bad thing. I have no idea why it is viewed as such. Forking is one of the beauties of open source, brings diversity in the code base, and even ensures longevity. The ability to fork is what ensures that in open source there will not be any lock-in. The beauty of this approach is the open source is not treated as something special. It becomes as normal as non-open source software. .. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Open Source development metrics
On 5/28/08, Jeroen Ticheler [EMAIL PROTECTED] wrote: Hmmm, I tend to strongly disagree here. Forking indeed can prevent a lock-in if that is becoming a serious issue in the project. Otherwise it just causes lots of duplication of efforts and dilution of energy into different forked versions. I think you agreed with me above. Forking for the heck of it is bad. Having the ability to fork, when forking becomes necessary, can be heaven-sent. I am not advocating to go make your own version of the beast. I am saying -- look, don't treat open source any different. Make it mainstream. Use it to solve your own specific problem. Trying to create open source to solve the world's problem is a sure recipe for failure. Of course, it just might happen that your own problem might also be the problem for many others in the world. In which case, donate your work back to open source so others may benefit. And, don't worry about forking. Given that most problems faced by most folks are likely to be mostly similar, your solution would likely work for someone else as well. Very Darwinian, no? It also does not help the average user much in selecting what's good for him/her. I think that Ubuntu as a popular release is one of the proofs that too much choice does not help to reach the large crowd. By limiting the installed default software packages they quickly reached a huge user group. My 2 cents, ciao, Jeroen On May 28, 2008, at 12:01 PM, P Kishor wrote: Forking is not a bad thing. I have no idea why it is viewed as such. Forking is one of the beauties of open source, brings diversity in the code base, and even ensures longevity. The ability to fork is what ensures that in open source there will not be any lock-in. The beauty of this approach is the open source is not treated as something special. It becomes as normal as non-open source software. .. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
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: discuss@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.___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Open Source development metrics
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: discuss@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. winmail.dat___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Open Source development metrics
IMO: Thanks Landon and Puneet, In this case, I tend to agree with Jeroen. There is a community developing GeoNetwork (and other projects) with ongoing work occuring. This would be occurring concurrently with our development work on a fork. We would want to be able to take advantage of the new developments that others make to the parent project, without having to refactor our 'fork' each time, or conversly, the additional work of refactoring our customisations, or part there of back to the parent project. We (the Australian ANZLIC community) have tried this approach already with the GeoNetwork ANZLIC Profile, and it is clearly not working (despite might I add the outstanding efforts of the main developer). I think that the only sane approach is to work within the parent project's community as peer participants. I do agree with Puneet that the *ability* to fork a project is critical to the success of open source projects, however I think that it should really only be used as a last resort if a situation is clearly unsalvagable. There is too much dilution of effort otherwise. Bruce Bannerman 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 ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
RE: [OSGeo-Discuss] Open Source development metrics
I think I should clarify what I mean by a fork. There is the very public, conflict-driven version of a fork, and then there is an often private, cooperative version of a fork. Imagine this scenario: The company Who's Wet Now Inc. is using OpenJUMP internally to produce flood maps of urban areas in the United States. They have several features that they would like to add to OpenJUMP, but need to integrate the features more quickly than is normally possible in the OpenJUMP community. As a result, they maintain a private fork of the main OpenJUMP code base in their own SVN repository. This allows them to integrate there new features quickly, without waiting for discussion and approval by the larger OpenJUMP community. The private build of OpenJUMP is distributed to all their employees. The most commonly used features are then moved by Who's Wet Now into the main OpenJUMP code base after community discussion and approval. Any patches for bugs found during the Who's Wet Now development process are also migrated back to the main OpenJUMP code base. In a scenario like this I think a fork may be acceptable, and even a beneficial thing. I think any of the following reasons would be valid reasons for maintaining this type of cooperative fork: [1] New features that an organization wants to integrate into the program are very specialized and would not be utilized by most of the community. [2] Changes an organization wants to make to a program are controversial or experimental. [3] An organization needs to move development ahead at a pace that is faster than the larger community of developers is comfortable with. As long as the organization maintaining the private fork does [1] a good job of tracking their modifications compared to the parent code base, and [2] actively participates in moving the benefits of their fork development back to the parent code base when appropriate, I don't see any problem with the fork. This is based on my own limited experience with OpenJUMP, which is just one program among many. If the organization creating the fork is not a good citizen of the community then I recognize that a fork can be a very bad thing. Landon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Miguel Montesinos Sent: Wednesday, May 28, 2008 3:09 PM To: OSGeo Discussions Subject: RE: [OSGeo-Discuss] Open Source development metrics 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: discuss@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
