John Plocher wrote:
> Having said that, I think there is a larger proposal hiding
> here.  I am beginning to believe that we need to refactor the
> community at large and redo the constitution in significant
> ways:
> 
> [This stuff is still churning in my brain - consider these
> following items to be brainstorming ideas and not final
> proposals or opinions - I am interested in your collective
> thoughts, and expect this all to evolve significantly before
> it gets to an actionable form]

As long as we're dumping the churn from our brains, I'd been
thinking that there's really three different types of thing
we've currently lumped into the Community Group model:

 1. Consolidations - ON, X, Desktop, Storage, etc.
   - groups that manage code bases used directly in distros

 2. Service groups - Advocacy, Tools, ARC, Website, etc.
   - groups that provide community-wide services of some form

 3. Interest groups - Sysadmin, networking, drivers, Dtrace, etc.
   - groups interested in some technology, but who don't "own" the
     code base that delivers it.

Part of this came out of the LSI driver discussion - there was a
suggestion the driver community just take a vote and move on, but
what's the point of that?   They have no gate to control, their
decision wouldn't be binding on what the ON community group allows
into their gate.    While it's useful to allow interest groups a place
to gather, hold discussions, share documents, etc., I'm not sure they
really need to be Community Groups as they don't really have any
say over anything's destiny.

Service groups on the other hand, as discussed in the Website
community proposal discussion, really need to represent all of
the community and have buy-in from all of the consolidations,
so aren't really peers to the Consolidation groups.   They do
make important decisions that affect all the other groups, so
not only need to have some structure for doing so, but some way
to make sure the stakeholders have a say as well.

Consolidations though seem to be what the Community Group model in the
constitution was designed for, and that makes sense, since they're the
closest mapping to Projects in the Apache model.

What do we do with the three types of groups - do we keep them all
in their current form, or redefine new forms that better fit each type?
I don't know.

-- 
        -Alan Coopersmith-           alan.coopersmith at sun.com
         Sun Microsystems, Inc. - X Window System Engineering


Reply via email to