Alan Coopersmith wrote: > We do have a hierarchy at the moment, a very rigid one - all top-level > groups are "communities", they can create second-level groups called > "projects" - which led to the creation of user groups as projects, > since we really didn't want to go through the whole formal community > creation process for each user group. The additional distinction that > only groups at the project level can have scm repositories has led to > the communities that represent Consolidations having to create Projects > just to do the thing they were created for - managing a shared code base.
OK, I should clearly have been more specific. Firstly we don't have a hierarchy that actually does what we want, and as a result we bend and/or bypass it at present. Things like the 'sponsors' relationship between CGs and Projects are generally considered not to be a good fit with what we need. Secondly, we have two types of groups, but all the instances of those types are peers - there is no hierarchy within CGs or Projects. Under the new proposal it appears that we would change - the proposed hierarchy is up to 5 levels deep in places. That implies that *within* CGs, Projects etc we are going to have a hierarchy. -- Alan Burlison --
