I think we all are seeing some serious flaws in the existing organization based on a variety of examples in the last year. I have plans to introduce a proposal in the next few weeks, as I've not fully baked my proposed structure and associated constitutional amendments, but I'll start throwing out some ideas.
1) The current Constitution has within it a major flaw, in that it does not define Projects. It refers to them, but never defines them. 2) Existing terminology is excessively confusing and has, to an arguable extent, painted us into corners. A "Community Group" sounds like a loose collation of related "things". A "Project" sounds like a place to do work, collaborate on details, and work in a targeted way. The Constitution puts organization in CG's, but not in projects... projects answer to and are "owned" by CG's. This is where things get sticky. Lets take two examples, one that works in this model and one that doesn't. First, lets take the Advocacy CG. This is the model CG thanks to the hard work of Jim G. You go to the CG main page and you are greeted with all the information you need to get started. There are several projects, all well segmented, its a thing of beauty. This works, I believe, because the core contributors of the Advocacy CG have a handle and grasp on all of the projects benieth it, even if they aren't involved directly, and people contributing projects trust and look to the leadership of the CG Core Contributors. Sara D. or Jim G. or Teresa G. (on and on) can speak to any of the Projects under the CG with respect and trust, and then be back on their way. On the other side, lets consider the LDOM's CG proposal. This was met with the suggestion of instead collapsing xVM/Xen and Zones CG's into a larger Virtualization CG as projects, and then bringing LDOM's along side. This didn't work (short version) because while LDOM's, Zones, and xVM are all Virtualization efforts, they really are completely distinct. Could Core Contribs of a Virtualization CG make judgements that would be respected, trusted, and useful to the underlying Projects? Not to mention that these are large efforts which themselves may require projects. For these reasons and more, it proved that in our Constitutional model "Virtualization" isn't a Community Group; LDOM's is. 3) Now, lets consider the Distribution CG proposal (that will go to vote regardless of any discussion, btw). Shawn Walker is absolutely correct that there needs to be some way to bring distributions together in an organized way within the OpenSolaris community framework. Linux distros are a great example, they are all over the place and independant, wouldn't it be nice if all the OpenSolaris distros had a home (if they choose to participate of course)? The problems noted above with the LDOM's effort are almost identical in the case of distributions. Should Core Contribs of a Distribution CG make decisions about Belenix, Nexenta, Schilix and Indiana? I don't think so. Never-the-less, there should be a grouping which I call a "meta-community" or "Consortium" which can provide a loose social grouping of CG's to facilitate collaboration and coordination. 4) There are two solutions (I'm still working through this, so this isn't final) that I see... a) Push things down a layer. This would make the intuitive definitions make sense. This requires major modifications to the Constitution, but more closely mimics what we actually do in practice today. b) Add an additional layer above CG's, my "meta-communities" or "Consortiums" idea. Consortiums in this model wouldn't have any real power at all, but would provide a much needed means to pull together various functional areas of the project in a much more organized way. 5) If we are going to ever do away with the term "Community Group", we should do it sooner rather than later. Its still very early in OpenSolaris's life, I think doing so is no out of the question if deemed appropriate. Like I said, I'm still baking the idea, but we need to make contribution much easier than it is today and currently there is too much bureaucracy, partially because "projects" are somewhat heavy wieght... if "projects" are much more granular it could facilitate handing out projects more easily, better facilitating contribution, because projects come with repositories. This all feeds into the contribution model which needs so much work, but I honestly have mountains of research to do before I can properly express a useful stance. benr.
