John Plocher wrote: > IMO, ConsolidationCGs should own Projects that are focused on > integrating changes back into its repository, while EnthusiastCGs > spawn Projects to create policies, documents or other artifacts that > can be [applied to/reused by/...?...] the various ConsolidatrionCGs.
While the distinctions you draw between the different types of CG are interesting, I don't think they are necessarily relevant to my proposal. As I've already said, I don't believe allowing multiple CGs to sponsor a project is a sensible option, due to the problems I've already pointed out. If Members have interests that cross-cut multiple CGs/Projects then the Members should participate in the appropriate multiple places. Trying to implement some quasi-formal connections from CG to CG, CG to Project and Project to Project seems like it will just create bureaucratic muddle and confusion. For example, when a Project needs to make decisions, who exactly does it take input from? The answer of course is the Members of the Project itself. If people from other GCs or projects want to influence another CG or Project, the correct mechanism is for them to participate in it. That way the responsibilities and reporting structures are clear and unambiguous, unlike the current woolly "sponsors" situation. > In the above example, this would mean that the DTrace CG drives the > evolution of DTrace by producing ARC umbrella cases, roadmaps and the > like; its people then go off and create Projects under ON to actually > implement that vision in the ON consolidation. > > Or are you thinking of something else? Actually, I agree with JimG that many of the existing CGs are either poorly scoped or dysfunctional. If I look at the projects in the ON CG, for example, I see a complete mishmash with no common theme. I think the solution is not to formalise the existing mess, it is to rip it all out and do it properly. To take your example above, I can see no reason why the DTrace CG would choose to run its projects in another CG - there appears to be no real benefits in that approach. And if the ON CG dies (as it should), it wouldn't be an option anyway. -- Alan Burlison --
