Difference between revisions of "One Organizational Model"
Jump to navigation
Jump to search
(updated) |
|||
| Line 1: | Line 1: | ||
| − | '' | + | '''''This is not an official OSGeo policy page but an excellent reference to good practice.''' Michael Gerlek made the following notes about an object-like model that could be used to "describe" the organizational structure of the Foundation. It was slightly modified three years later to reflect common practice.'' |
| − | For the sake of discussion, let us use an object-like model to describe organizational | + | For the sake of discussion, let us use an object-like model to describe organizational structure of the Foundation. |
The '''Project''' type has the following properties: | The '''Project''' type has the following properties: | ||
| − | * | + | * to become an official [[Local Chapter]] it has to be initially chartered by the Board |
| − | * | + | * it should have a Management Committee of some sort |
| − | * must periodically report status to the Board | + | * official Local Chapter must periodically report status to the Board |
| − | * additionally, | + | * additionally, [[WebCom]] and [[SAC]] can provide some common infrastructural properties for '''Project ''' objects, such as Wiki space, mailing lists, etc. |
| − | New projects | + | New software projects are subject to the OSGeo [[Incubation]] process. |
| − | + | Several other types can be derived from the base '''Project''' class: | |
| − | * '''CodeProject'''- specifically concerned with code development work | + | * '''CodeProject'''- specifically concerned with code development work |
| − | * '''LocalInterestGroup''' - specifically concerned with bringing together individuals from a common geographic region, e.g. | + | * '''LocalInterestGroup''' - specifically concerned with bringing together individuals from a common geographic region, e.g. Ottawa or Brazil |
* '''SpecialInterestGroup''' - specifically concerned with bringing together individuals with a common geo-related interest, e.g. GRASS users | * '''SpecialInterestGroup''' - specifically concerned with bringing together individuals with a common geo-related interest, e.g. GRASS users | ||
| − | There | + | There is a limited number derived from ''Project'' which have been instantiated as singletons, they are known as the OSGeo committees: |
| − | * | + | * [[Incubation]] |
| − | * | + | * [[Marketing]] |
| − | + | * [[WebCom]] | |
| − | * | + | * [[EduCom]] |
| − | * | + | * [[geodata]] |
| − | * | ||
| − | + | OSGeo has developed into being a "federation" of '''Project''' objects, all of which share certain common properties. One of the underlying intents is that this model might help us better understand -- and possibly simplify -- the Board's role to just the following areas: | |
| − | * identify new strategic opportunities, and charter off | + | * identify new strategic opportunities, and charter off new Projects as required |
* oversight over all projects, to make sure they are following OSGeo's goals and principles | * oversight over all projects, to make sure they are following OSGeo's goals and principles | ||
* control of budget and allocation of funds | * control of budget and allocation of funds | ||
| − | |||
| − | |||
Latest revision as of 09:15, 1 October 2009
This is not an official OSGeo policy page but an excellent reference to good practice. Michael Gerlek made the following notes about an object-like model that could be used to "describe" the organizational structure of the Foundation. It was slightly modified three years later to reflect common practice.
For the sake of discussion, let us use an object-like model to describe organizational structure of the Foundation.
The Project type has the following properties:
- to become an official Local Chapter it has to be initially chartered by the Board
- it should have a Management Committee of some sort
- official Local Chapter must periodically report status to the Board
- additionally, WebCom and SAC can provide some common infrastructural properties for Project objects, such as Wiki space, mailing lists, etc.
New software projects are subject to the OSGeo Incubation process.
Several other types can be derived from the base Project class:
- CodeProject- specifically concerned with code development work
- LocalInterestGroup - specifically concerned with bringing together individuals from a common geographic region, e.g. Ottawa or Brazil
- SpecialInterestGroup - specifically concerned with bringing together individuals with a common geo-related interest, e.g. GRASS users
There is a limited number derived from Project which have been instantiated as singletons, they are known as the OSGeo committees:
OSGeo has developed into being a "federation" of Project objects, all of which share certain common properties. One of the underlying intents is that this model might help us better understand -- and possibly simplify -- the Board's role to just the following areas:
- identify new strategic opportunities, and charter off new Projects as required
- oversight over all projects, to make sure they are following OSGeo's goals and principles
- control of budget and allocation of funds