[OSGeo-Board] Projects, Committees and Working Groups

[Mark Lucas]

Frank,

Well thought out and well written.  Agree completely.

This structure will allow us to appropriately focus available people  
and resources as we pursue our overall goals.  The working groups can  
be unfettered by process and bureaucracy to respond in an open source  
way to needs and opportunities.  The board will sit at the other end  
of the spectrum and focus on top level priorities and formalizing the  
infrastructure.

Projects have been pretty successful on their own.  Why muck with  
success, we will need to create an environment that shows the  
benefits of consolidating resources and applying standard practices  
for the benefit of all concerned.

Commitees should be focused, limited, and meaningful.

Mark

On Mar 26, 2006, at 3:49 PM, Frank Warmerdam wrote:

> Folks,
>
> I've been a bit conflicted about what sorts of sub-committees we have
> within OSGeo for a while.  I would like to suggest we have the
> following "types" of committee:
>
> 1) Project
>
> This is our traditional heavy weight project.  It is run by a Project
> Steering Committee.  A project has it's own subdomain on the web site.
> Most projects will be an open source software projects like GRASS,
> MapServer, etc.  All Projects must go through incubation, but are
> treated as somewhat "arms length" from the board in the sense that the
> board will not normally interfere in the operation of a project as  
> long
> as certain basic constraints are satisfied.  Project PSC Chairs are
> VP's of OSGeo.  Projects may also have dedicated funds help by OSGeo,
> but available for the project to use as the PSC sees fit as long as  
> some
> basic "good governance" requirements are met (proper accounting, not
> obviously being wasted or mis-appropriated).
>
> 2) Committee
>
> This is a group assigned some specific area of responsibility by  
> the board.
> A committee's chair is a VP of OSGeo and reports back to the board.
> Committees are given a mandate by the board on formation, and some
> independence to pursue their assigned mission.  But they exist to  
> "serve"
> the board, and the board may direct them as it sees fit.  In many  
> cases
> policies developed in committee should be referred to the board for  
> final
> approval.  This would include committees like VisCom, WebCom, IncCom.
> Committees do not have their own funds to disperse, and all  
> spending needs
> to be explicitly approved by the board, or at least the treasurer.
> Committees may have their own project subdomain on the site, though  
> this
> isn't critical.
>
> 3) Working Group
>
> This is intended to be the "lightest" format.  Working groups live  
> primariliy
> in the wiki, and do not need to explicitly formed by the board.  They
> essentially form as a community of interest with some hosting of  
> resources
> on the foundation web site.  Working groups's chairs are not  
> officers of
> the foundation and they don't have a reporting responsibility to  
> the board.
> They can internally organize themselves as they see fit (formal  
> meetings with
> minutes are optional for instance).  Working groups do not have  
> their own
> project domain, and any special resources (like a web page not in the
> wiki, mailing lists and so forth) should be requested from WebCom but
> are provided at WebCom's discretion.   Other resources (funding,  
> adopting
> policies, etc) may be requested from the board, and are granted at  
> it's
> discretion.
>
> ---
>
> My intent is that several existing efforts, such as the  
> "languages" (as in
> perl/python/php), the "binary distribution" group, the "cerfication  
> group",
> the "telescience infrastructure" could all be organized as working  
> groups
> for the time being.  Some of them might well be promoted to full  
> fledged
> committees at some point, but only as needed.
>
> My main objective in the above nominclature is to provide a "light"  
> way
> of organizing some efforts that don't necessarily have a clear  
> mandate yet,
> or for which we don't need a log of "process overhead".   While  
> I've had
> this idea for a while, I must admit my desire to push it now is partly
> driven by Jo's concern I was putting too much weight on "process".   
> There
> must be some sort of irony in my solution to "process overhead", being
> to develop a new process (ie. working groups)!
>
> But I'm also interested in formalizing what I see as the  
> distinction between
> "projects" and "committees".  Something that gives a voice to our  
> assumption
> of independence for software projects, and our assumption that  
> committees
> are not intended to be so independent.
>
> I'm not sure if it would be valuable to have the above written into  
> our legal
> bylaws, but I would like to see us adopt it as a practice, and  
> possibly
> adopt it in some form.
>
> By the way, I think the Geodata group could conceivably be pursued  
> as just
> a working group.  The main reason I think it makes sense to promote  
> it as
> a committee is to give it a more formal "heft" in the organization  
> and to give
> it's chair an appropriate title to use in advocacy and  
> communication with
> the outside world.
>
> Best regards,
> -- 
> --------------------------------------- 
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGF, http:// 
> osgeo.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: board-unsubscribe at board.osgeo.org
> For additional commands, e-mail: board-help at board.osgeo.org
>