On 3/16/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > robert burrell donkin wrote: > > > Ken wrote: > > > I've posted *my* first-pass definition of the term: a TLP that > > > has no deliverable packages of its own, only from its subprojects. > > > my first pass definition is quite different: > > an umbrella is a project where there is the legal and formal > > organization structures do not coincide. > > > symptoms include divisions between committers (sub-projects with > separate > > karma and mailing lists) and the need for additional rules and > management > > due to the inability to provide oversight over the entire codebase. > > Robert, so you would want to ask the same question I asked Dain? To wit: > > - Are you going to make one community from the bunch, > with everyone having access to work on every piece > of code? > > - Are you going to have a large, single, PMC with everyone > having binding decisions over every aspect of the project? > > Are those indicators for your definition?
+1 though i would prefer to think of three dimensions: legal, formal and social (community). the second is IMO a decisive indicator: legally, decisions must be taken by the pmc as a whole. if that's not true in the formal structure of the project we have a definite umbrella. the first question is about the community dimension. a community does not have to accord with the formal legal organisational structure. ATM it just mostly happens to do so. i would definitely still ask it, though. community needs to be a superset of the formal legal divisions or it is inevitable that the project will drift towards a disjunction between the legal and formal structures as separate communities pull apart and establish their own social territories. so, it's important to establish a esprit de corps. Sounds like you'd have those, and additional ones. not sure that i would - maybe fewer with more consequences :) the legal situation here is pretty simple: TLPs with all pmc'ers having an equal binding vote on all decisions binding on the ASF and each being responsible for oversight. the formal structure of a project includes karma. so, pmc'ers need to have karma for the entire codebase so that they can act (where necessary) to address legal issues. mailing lists are another formal structure. one of the ways that oversight is exercised is through reviewing commits. therefore, pmc'ers need to be fed every commit email: anything else is a legal fiction. the same goes for issues and wiki changes. the easiest and most transparent way to achieve this is through a single mailing list for legally important messages for a TLP to which all pmc'ers are obliged to subscribe. IMHO this needs to extend to VOTEs as well. this arrangement is self-limiting factor in terms of scaling: if a project becomes so large that pmc'ers struggle to read these important messages then the legal project needs to be split. if there is still sufficient esprit de corps then federative solution is needed. this means that the legal entities are split but the communities are not changed. - robert
