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)
>>> 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
