Hi all, Throwing my ideas on simplification into the ring, see below.
John Plocher wrote: > Peter Tribble wrote: > >> On Fri, May 16, 2008 at 11:17 PM, John Plocher <John.Plocher at sun.com> >> wrote: >> >> >>> The following is a first-pass whack at taking all of the 300 or so >>> existing Community Groups, User Groups and Projects and reorganizing >>> them into a more manageable structure. >>> >> Do you see this as just a one-time effort to straighten things out, or do >> you see the OGB as continually managing the structure of the community? >> > > I see this as a two part effort - one: move to a structure that accurately > reflects what we are doing and how it is done, and two, continually monitor > the various entities to ensure that they are effectively self-governing > their sub-communities. > > The latter implies being involved in some way with the sub-community > lifecycle: creation, heartbeat monitoring and destruction. > > >> There's much less need for a perfect community structure once you divorce >> community governance from that structure. >> > > Especially if it is easy for the community to morph that structure by > actively managing their own relationship ties... > > >>> Key to my reorg was an attempt to put PROJECTs under the COMPONENT >>> where they integrate rather than under the SIG where they get talked >>> about. >>> > > In the OGB meeting this Monday, we talked about how the terms we use > are driving us apart; in particular, the wildly different uses of the > word "Project". One camp associates "Project" with a large, viable, > stand-alone entity, the other with a transient task or effort that > feeds into such an entity. I chose the latter in my proposal, which > led to big "components" and little "projects". Unfortunately, it seems > that everyone else uses the other meaning, which means I need to change. > Bummer :-) > > How about the following top level "Community Group" entities: > > User Groups > SIGs > Projects > > The smaller things that feed into CGs would be called "Tasks". > > Thus, > > CGs evolve by the application of Tasks > CGs initiate their own Tasks > Tasks have people and a plan to do something that impacts a Project. > SIGS can affiliate with Projects > SIGs can initiate Tasks to cause affiliated Projects to evolve > Projects decide whether or not to accept the output of a Task > Tasks that impact the architecture of a Project are reviewed as > appropriate > > I'll try to use this new meaning from now on. (and I'll update the wiki > at http://www.genunix.org/wiki/index.php/OGB_2008/010) > I've added a summary of the simplification I've been thinking about to the wiki page above. I propose that rather than re-categorizing existing groups and projects, we add a layer to the hierarchy called Steering Committees (SCs) made up of Facilitators. Facilitators are a gap we've not yet implemented as defined in the Constitution. Steering Committees would be cross-functional teams where strategy and high-level decision-making happen. Here is the hierarchy: SCs : 4 committees made up of the 46 CG facilitators | CGs : 46 currently | Projects : 100+ The 4 steering committees could be: Core, Userland, Support, and Release. For detail, see http://www.genunix.org/wiki/index.php/OGB_2008/010#Michelle.27s_Ideas Within those four umbrellas, communities and projects can continue to flourish unbounded and mesh just as we have done with all the same rules of instantiation, voting rights, and status. We could implement Facilitators as defined by the Constitution (maybe expanding the role a bit) and those facilitators would bring decisions and issues of their communities to ~12 peer facilitators via their Steering Committee meeting each month. This could increase the communication across related communities and create a place to resolve related technical issues that are bigger than a single community. Then, we could bring the 4 steering committees together every 3 months to increase communication across the entire project, through the 46 representative facilitators. We'd only have four groups to poll when decision-making needs to happen on-the-fly. Core, Userland, Support, and Release are terms that should not require a glossary to understand, even for the new person. They also match what we're doing and could work nicely with regard to website navigation. We don't have to move any projects or community groups arbitrarily, we just organize them into the steering committees. Everyone gets representation, providing they work through a Community Group facilitator. (This is the same clause from the original 2007 re-structuring resolution that presupposes projects have communities.) In two years time, we can add a new steering committee if we need one. But, we shouldn't go beyond 5 while we are still only 5 years old. When we are ten, we can split each SC in two for a total of 10 steering committees to take us through the next 20 years. That's my US$.02 :) Thanks, Michelle > > >>>> Is this the existing ARC(s)? >>>> >>>> Not really... >>>> >> Ah. Please expand... >> > > The existing ARC is mostly Sun-internal people who have a long history of > being involved with architectural review. IMO, this needs to evolve into > something where the people doing the work (i.e., the contributers to the > various Projects and SIGs) are the people who get together and review each > other's Tasks to better understand the architectural impact on the systems > (or distros) we all are building. > > > >>>> If the ARC exists at that level, then there's something missing. While >>>> >>>>>> the ARC ensures that what we do is done right, it doesn't define what we >>>>>> do. Where is the part of the organization that decides what we should >>>>>> work on? >>>>>> >>>> The COMPONENT CG that is responsible for the thing that is being developed. >>>> >> Well, no. That's tactical - where's the strategy coming from? >> > > In my mind, strategy comes from SIGs (we must be secure, accessible,... > across multiple Projects) and from the Project's leaders - they set > feature-direction for their Project and decide what Tasks they wish to > encourage/admit. > > At a high level, a Project answers the question "do we want to do this?" > and the ARC answers "is this the best way to do it?". > > -John > > > _______________________________________________ > ogb-discuss mailing list > ogb-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ogb-discuss >
