Simon Phipps wrote: >> None of those are 'umbrella' groups in the sense that you seem to be >> suggesting. They may be large and/or important groups in their own >> right, but they do not have subservient groups reporting to them. You >> seem to be suggesting that we have some sort of hierarchical >> organisation - that would appear to be a radical departure from the >> current setup, and I'm not at all clear how we would get to there from >> where we are now. > > So I am receiving conflicting advice. I was advised that the ON > repository and the SFW repository were each home to many working units > of code. If that's not the case and the whole existing OpenSoalris > development world is many many unstructured groups then that's news.
That's not what I said. I said that the list of things you identified didn't 'own' other subservient groups. I wasn't talking about where code eventually ended up. Your proposal doesn't match the way the existing ON gate works internally - the ON gate doesn't own the projects that integrate into it. The ON CTeam manages the integration of projects and defines processes and standards that projects must adhere to in order to integrate - that's a long way from 'owning' the projects. Neither do the ARCs own the projects who present their case materials to the ARC for approval. >>> I'm not proposing using "Group" as the structural umbrella; we need >>> a number (15-ish) of top level Groups for that. >> >> Why do we need a hierarchy? > > For operations, we don't. > For governance, if we are to have liaisons with each Group, we will > either be overwhelmed or there will be no contact. Instead of that, we > need a manageable set of top-level Groups who aggregate other Groups for > member nomination and resource allocation purposes. I'm happy to have a > proposal for how we do that, but it is neither "four groups" nor is it > "hundreds of groups". > >> >>> - "Group" is the class we are instantiating. >>> - For governance purposes, the OGB will instantiate a set of >>> top-level Groups. Those Groups will organise whichever other Groups >>> they need to function, and so on. >>> - For operational purposes, all Groups can relate to whichever other >>> Groups make sense. >>> - For website purposes, Groups can be listed in the sets that make >>> the most sense for each page of the site. So your use case below can >>> be accommodated. >> >> That all seems a little vague to me, at least. Who gets to decide >> what, and when it has to be decided by? > > There seems to have been plenty of discussion of that already and > several possible schemes. I'm not a "compiler" type... > > S. > > -- Alan Burlison --
