Peter Tribble wrote: > The discussion seems to be taking place in this thread. Oh well. > > To summarize, I'm highly negative on this. > > Extending the definition of CGs to include projects (and, to a lesser > extent, user groups) isn't workable.
I don't see it as an extension of a definition; I see it as the elimination of one. We can argue whether that's good or not, but the attempt is to remove layers, not add them. I see the use of the term "communities" to just a general word that people would use to describe the overall community and the individual collectives inside -- just like we do now, actually. The specific terms would be SIG, Project, or whatever. > For one thing, I expect the number > of CGs to be small; creations and administration of CGs is a > heavyweight process that should be avoided for other structures like > projects which should be trivial to create; Why keep any heavyweight process at all? > we're going to end up with a > lot of CCs; many projects may just have one or two active people - > One or two active people in a project is fine. In fact, it's better than an entire community group that is non-functional or poorly scoped. > and wouldn't (and shouldn't) have the minimum of 3 (desirable 5) > CCs for operation. > > You can't create CGs without CCs. We're not. CGs would go away under this model. > Doing so makes the CG > unconstitutional from the start. Note that CCs are really the people > providing direction (not necessarily those buried in the work - Theoretically, yes, but I don't see the CCs providing direction at all. Not as a group, anyway. Specific individuals, sure, absolutely, but the CC's have thus far done very little in the way of providing direction in the community. We've had this discussion last year. Many people felt that the OGB should actively manage the community, which I don't agree with since the OGB has zero resources and is really only a policy board. > although > they may often be the same). If it isn't clear at the start who's providing > direction for a community, then that community doesn't have any leadership > to generate a proposal. > > (Personally I would prefer to see the current CC role swept away. In that > currently the only real community role of a CC is to vote in global elections; > surely it would be better to have all Contibutors be Members, and the Core > status only relevant within a particular CG or project or whatever - where > any group could have it's own leadership structure.) > I'd certainly support the consolidation of some of our levels in the community and I see no reason for the distinction between Contributor and Core Contributor. > I'm sure you didn't mean it this way (or maybe you did?) but the membership > committee sounds far too elitist to me. > I think the intent here is to agree on some standards, to be honest, not to actively manage or screen people becoming CCs. That's my reading of it, anyway. > And if we are to redefine membership (as in voting membership), then we need > to set the rules out for everybody. The proposal doesn't specify what > the quality > control requirements of the Membership Committee are. > Sure, there are many things that need specifying. > Overall, where's the simplification? What we really want is to (a) make > projects easier to create (b) add SIGs, which is what many of the old > communities were, and (c) simplify the membership structure by getting > rid of the Core/non-core split and just having Members. > Agree on the Core/non -core split issue. But if we add SIGs to the current structure, what's the distinction between a CG and a SIG? I don't think we need both. And what do we do with the UGs then? OpenSolaris this year will grow significantly in the user area, and they shouldn't have to live under the Advocacy CG. If they do, we could very well have 10k+ people in Advocacy next year, and 90% of them would have no clue what the Advocacy CG. On Projects: they are already pretty easy to create but do they all have tight associations to CGs? Should they? We should just automate the process and de-couple them from CGs. With the new webapp they can have associations with other projects and consolidations. Now there certainly are exceptions to this and there are some well functioning CGs, but I'm not at all convinced that most CGs care that much about the Constitution, and so I think it would be a good thing for Governance on OpenSolaris to move more into the background and get the project work more up front. I no longer see a need for that CG layer in the community (and I used to support the current structure). Don't have the answer. Just exploring the issue. :) Jim -- http://blogs.sun.com/jimgris/
