On Aug 8, 2007, at 1:34 PM, 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 I'd hope the OGB is more careful in > CG instantiation than project instantiation).
When CGs are broadly scoped, they fail to reach consensus on common goals, then start in-fighting, and eventually the board has to step in and clean house (which upsets everyone, including the board). I am speaking directly from the Apache experience. > 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 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. > > 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.) Apache has an incubator project (CG) which is tasked with the job of taking a few volunteers with a code base and turning them into a self-governing community. That didn't work very well because sub-boards are just like boards -- they have no real interest in the project and thus nothing to engage them in oversight. But, at least it keeps the new group in a constrained sandbox until they can learn basic Apache principles, like how to do a legal release. What did work was to have three experienced Apache folk volunteer to be mentors for each new project, such that those individuals would be responsible for teaching the others how to get things done. > 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 creating havoc among the technologies and blissfully ignoring the complaints from the engineers who actually do the real work of IETF standards. HTTP security sucks because that same bureaucracy demanded that HTTP authentication be owned by the Security Area instead of Apps, thus taking authority out of the hands of the only people affected. Fortunately, the areas only impact how charters are defined, how ADs are selected (resulting in a wider representation on the IESG than would have been the case in a simple election) and how the agenda is arranged -- they have no formal role in working group governance or approval of an RFC. ....Roy
