John Plocher wrote:
> [Cc'd to ogb-discuss]
>
> Many of you on the To: line have been vocal about the topics touched on
> below; you have been nominated to help come up with a concrete proposal
> to clean up and/or restructure the OpenSolaris community.  What follows
> is my current understanding of where things are at; the part this sub-
> committee gets to deal with is at the end.
>
> Please RSVP if you are willing to accept your nomination and help with
> this effort.  Oh, and feel free to make suggestions, ask questions, etc!
>

It's been about 10 days since we voted to create this committee. Do we 
have a committee set to go? How are we moving forward? I think we ought 
to meet via phone at least once next week. We'll need to discuss all the 
proposed plans -- I count about four so far.



> The OGB is working on restructuring the community from its original
> pre-constitution set of several dozen top level Community Groups into
> a smaller, more manageable number.

I disagree with the notion of restructuring from the perspective of 
reducing the number of current CGs. I also disagree with the notion of 
adding a few new groups on top of the current set of CGs just so the OGB 
has a small set of groups to interact with. If we attempt to actively 
manage the reorg this way we will most certainly be engaging in a 
massive cross-community communications effort, and it will take many 
months to gain consensus.

Even such a simple move as consolidating some roles will need to be 
communicated to the entire community, so that's another thing we need to 
add to the list of items for the committee: a communications plan.

Instead of restructuring as you have outlined here, I'd argue that we 
need a few top level categories into which many instances of groups can 
fit. I think Communities, Projects, and User Groups work well to start 
(there are other proposals for these as well). I name those categories 
"Groups" but they are just shells to hold things for the convenience of 
understanding. The OGB will not be interacting with those top level 
Groups, though. If we are decoupling governance from operations, then 
there is no need for the OGB to really be messing around with 
operations. We just create the shell, and let people create the Groups 
and do their work. The OGB should be concerned with much, much higher 
level issues -- Membership, dispute resolution, communications with Sun 
and other organizations, etc.

> The guidelines for that restructuring are
>
>   * Separate governance and operations.
>       * Governance defines the roles of [Participant, Contributer and 
> Voting Member].

There are a few other proposed sets of roles as well.

>     A Voting Member is
>         A CONTRIBUTER who wishes to have a vote in the
>         community-wide elections and decision-making
>         process.
>
>     A Contributer is
>         A PARTICIPANT who has been acknowledged by
>         one or more Groups as having substantively
>         contributed toward accomplishing the tasks
>         of that Group.
>
>     A Participant is
>         Someone who is participating in the
>         activities of a Group.
>
>     The distinction between Contributer and Core Contributer is being
>     simplified by allowing any Contributer to choose (or accept) the
>     responsibility of participating and voting in the governance of the
>     community as a whole.
>     The other operational attributes formerly associated with these
>     roles (commit access, SCM authority, website editorship...) are
>     explicitly disconnected from the definitions of these roles;
>     additional roles are expected to be defined by others to address
>     these operational needs.
>
>     See 
> http://mail.opensolaris.org/pipermail/ogb-discuss/2008-July/005814.html
>
>       * Governance concerns itself with overseeing resource allocation 
> and the
>         enfranchisement of new contributers.  To do this, the OGB 
> proposes to
>         create two new committees, one for Membership and one for 
> Resources.
>
>     They will be staffed by the facilitators of each top level community
>     group, and will be responsible for reviewing and approving each 
> group's
>     individual membership and resource allocation policies.
>
>     See 
> http://mail.opensolaris.org/pipermail/ogb-discuss/2008-July/005814.html
>     and 
> http://mail.opensolaris.org/pipermail/ogb-discuss/2008-July/005817.html
>
>    * Refine the structure of the OS.o world.
>
>     This is a classification or categorization effort more than 
> anything else.
>     The intent is to make everything a "thing", place each "thing" in one
>     of these categories, and then to come up with a set of top level 
> "things"
>     which will "own" all the remaining entities.   Only "top level" 
> things
>     will participate in the governance of the community (create new 
> members
>     and projects, allocate resources, report regularly to the OGB,...)

This seems like a centralize approach, and I'd argue we need the opposite.

I'd like to see all the Groups as equals in a web-like structure so they 
can associate with each other in any way they like. I see one level of 
hierarchy. Flat. I know some are worried the OGB will be flooded with 
thousands of things to manage, but the truth is we don't manage the 
community now and we'll not be managing it in the future. We are a 
policy board, not an operational board. This initial reorg is important 
because it recognizes the decoupling of governance from operations. I 
don't know who came up with that, but it's excellent. For that reason, 
we should not be afraid to at least explore super flat structures. The 
biggest complaint we've had on OpenSolaris (from a governance 
perspective, anyway) is that we are too bureaucratic and too 
hierarchical. We need to cut layers, not add them.


>     Current labels:  Community Groups, Projects
>     New labels:      User Groups, Consolidations, Projects, SIGs
>
>   *  Come up with an initial list of "top level things".
>
>     For governance, we need a rational set of top-level groups with which
>     the OGB can communicate. They need to be our "existing" top-level 
> groups,
>     there need to be enough of them so that the "soup" is distributed 
> across
>     them without large concentrations under a single top-level group, 
> and few
>     enough to make regular reporting feasible. They can slowly change 
> as the
>     community slowly evolves.
>
>     The architectural principle behind this tree is that it matches 
> the actual
>     practice we have today.

The practice we have in the OpenSolaris community or inside Sun? This 
has been confusing to me.  I get the notion of documenting what we 
/actually/ do, but I'm not sure if that means we are just taking the Sun 
processes outside or if we are looking at how the CGs and Projects 
function on opensolairs.org.

>     The wiki page at 
> http://www.genunix.org/wiki/index.php?title=OGB_2008/010

Can we decide on a single communications mechanism for this? We have at 
least four plans in wikis, on lists, in bug databases, and in blogs. 
Personally, I'd prefer things on list until decisions are made.

>     has an initial stab at such an hierarchy.  It is rough, it is out of
>     sync with some of what I wrote above, and it certainly can be made 
> much better.
>     This is where y'all come in - I'd like to flesh this out and come 
> up with
>     a concrete proposal for the OGB's July 21 meeting in a week.

 I think we need a new deadline. The week is already gone. How about the 
28th?


Jim

-- 
http://blogs.sun.com/jimgris/


Reply via email to