To follow up on today's call ...
I'm not sure things are getting simpler. We seem to go back and forth
between simple and complex in my mind. That could just be my poor
understanding, of course. :) If I'm missing the simplicity, forgive me.
Below is a suggestion I think is consistent with Simon's proposal. It
can be argued in the committee, but my intent is to give Alan a simple
base from which to continue his work.
Let's remove the term "Community Group" and simply replace it with
"Group" and have three top levels organizing the entire OpenSolaris
Community: (1) Communities, (2) Projects, (3) User Groups. So, "Group"
also replaces Simon's "Thing" and Alan's "Collective" and other such
terms we've been discussing. Three big buckets with big hairy icons on
the site:
* Communities: Social groups gathered around an issue or technology.
* Projects: Development groups gathered around repositories and
integration tools.
* User Groups: Groups of users gathered around a geography.
No need for SIGs since they are really just Communities. No need for
Consolidations since that's a Sun term, and we should just keep making
them Projects as they open (just ON at this point?) to be consistent
with what's already out there. All three levels are structurally equal
to each other and can associate with each other. In fact, it would
probably be in their interest to associate with each other, but they
don't have to. They have web relationships (Simon's mesh), not
hierarchical relationships, but they can certainly choose a hierarchical
relationship if they want. The more they self organize and grow their
membership and argue for consensus the more influence they'll
potentially have in the community. Or they can just pass on that and get
work done and participate in governance to a minimum degree as required
to get access to resources, grow contributor roles, etc.
We can also trim the levels of membership to three: (1) Participant, (2)
Contributor, (3) Member.
* Participant: You have registered on the site.
* Contributor: You contribute to a Group and have been recognized by
that Group.
* Member: You have earned the right to vote in community-wide elections.
In terms of voting, the OGB concerns itself with the Members and
community-wide elections only. The OGB can suggest voting mechanisms for
the Groups, but those management decisions are up to the Groups -- as
long as they don't break the big rules the OGB specifies. Same with
access to resources. That's a Group decision, not an OGB decision.
Regarding the Membership Committee: I don't think it should be made up
of people from all the Groups because there will be too many groups and
the committee will be too big. All I'm specifying above is three
categories in which there will be about 280 or so Groups. I think in the
call today Simon or John suggested that we reduce the current Community
Group list down to 8-15 or so. In that case, sure, having a
representative from each Community Group would be a reasonable approach.
However, that suggests that the OGB is going to actively reorg the
community, and I'm suggesting that we stand little change of doing that
at this point. So, we should let the community organize itself (or leave
the current structure in place). Also, I can see some big arguments
coming from reducing the CG list from 45 to 8-15. I don't think it's
necessary. So, if we have a small number of categories but a large
number of Groups, the OGB will have to simply appoint the Membership
Committee, and the specification it produces can be discussed and voted
on by the community. In that case, the Membership Committee can be small.
Just an idea.
Jim
--
http://blogs.sun.com/jimgris/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ogb-discuss/attachments/20080708/5f833de5/attachment.html>
