On Wed, Aug 08, 2007 at 04:34:34PM -0400, Brandorr wrote: > Actually my proposal would reduce "management's involvement". Requests > wouldn't have to keep coming to the OGB, as the more general CGs would be > more broadly scoped, and new projects groups wouldn't keep coming to > OGB-discuss for approval, where there is a higher bar to cross. (At least
They already don't. Community Groups can create projects however they please; only inter-CG conflicts come before the OGB, and formation of new CGs. > I'd hope the OGB is more careful in CG instantiation than project > instantiation). We're not careful at all about project instantiation; that's left (as the constitution requires) to CGs. As I've noted elsewhere, we're probably being more careful than we might prefer with CG formation because of the costs of getting it wrong. We need more flexibility. > I also think you misunderstood what I was saying. Currently if you want to > start a project, you just need a CG to endorse the project. If you want to > start a CG you need full board approval from the OGB. I am advocating > removing this useless overhead from the OGB. (At the CG level, you only need > three contributors to approve your project request). > > Currently someone comes in with there project, sees all these micro > communities, and figures we need to start a micro community as well. The > thought is with fewer and broader CGs, most projects groups will have > higher chance of having a CG that alligns with their goals.) I agree in principle, but we've been down this road before. The response from the "micro" CGs (some of which are not really so micro) was broad-based, vocal, and overwhelmingly negative. The takeaway was that many of these communities have formed around technologies espousing incompatible worldviews (for example, QFS and ZFS). Attempting to combine them, while logical if not for all these damned people, would in reality lead to reduced productivity and increased infighting. This seems to be the essence as well of Mr. Fielding's assertion. Please let's call this one dead. > I also think that the size or number of the pieces of a given set of > technologies should not makes them get their own CG. As an example, the LDOM > working group might have 5 different projects in the Virtualization > community. This is what I proposed yesterday, but there is no interest from the principals. We're not going to force people to work together who don't want to or believe they can't. > Another piece I have been advocating is an incubator community, that would > be the fastest way for new projects and groups to take advantage of > Opensolaris.org resources. (Get the code out!!) Although the need for this > CG will be less urgent, if we had broader scoped CGs. (BTW - The current > constitution labels the OGB-CG as the last resource CG for project > instantiation.) This was the previous idea for an "incubator" CG; we decided that instead each CG was able to "incubate" its own projects on whatever terms it chooses. There is no need for a separate CG to create new projects. Nor does the Constitution say anything about the OGB sponsoring projects, only that we are to recognise with grants those who have made contributions falling outside any other Group's charter. What's under consideration now is some sort of "CG incubator" or probationary structure for groups of people with a common interest but no history of contribution to OpenSolaris. In many cases, these may be Sun product teams with newly-opened code bases in which they wish to sponsor new projects. We need a clean, simple way to encourage them to do so while making sure their community is viable and that they understand the mechanics of operating a CG. Once that stage is complete, they would (re-)apply to form a CG. As you note, it's all about how to help people get started and be successful. > As an example of what I am talking about, with the plethora of protocols and > working groups that the IAB resides over, how does the IETF limit themselves > to only eight areas, that all working groups fall into? By having "areas" that don't have any meaning other than navigation tags. Surely you don't think all the people working in the Applications Area agree on the set of applications that ought to exist or how they ought to be implemented? It would be impossible to reach consensus in such a broad group. Again, the analogy here is with Mr. Fielding's tags, which would be a useful bit of infrastructure. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
