Peter Tribble wrote: > >> Special Interest Groups are internally focused on activities >> taking place within the community, and work to set common >> strategic direction across the entire community. > > I'm not sure I agree with the notion of internally focussed. > The way I see this is that SIGs are communities based around > technology, subject matter, or shared experience. They tend > to be horizontal structures that may span multiple projects > or components.
I think we are trying to say similar things. > >> Finally, there are the various Components that are developed >> by the community. The open source of our open source community, >> if you will. >> >> Components are created from, and are evolved by PROJECTS that >> invent new features and/or fix bugs. > > This is where it gets a bit hazy for me. You've invented a new term here; > I'm not sure that we couldn't use the term "project" for all cases (as a > constitutional term). The problem is that the word "project" means different things to different people. To an "apache-ite", it has connotations of large long lived semi-autonomous entity responsible for the care and feeding of an entire development effort, and of the thing that that development effort produced. To an ARC member, the above is usually called a consolidation or even a product; the dozens to hundreds of bugfixes, new feature additions and code tweaks that the effort to produce version N+1 out of version N entails are called projects. I don't care what words are used to describe these things; the important thing is that we all use the same definitions when we use them :-) There are two entities in play here - the big thing being built and the little development efforts that go into building it. These little development efforts are extremely important to us as an open source development community because they are the mechanism where community members are able to contribute to the shared codebase(s). > SIGs, with a wider view, have a role to > play in bringing together disparate projects and identifying gaps. +1 - in a sense, those little development efforts (which I termed PROJECTS) are generally tactical efforts and the SIGs are more of a strategic force. >> VOTING MEMBER >> A CONTRIBUTER who has asked for suffrage in the decision making >> activities of the larger OS.o community. Suffrage can be revoked >> if not exercised. > > This raises a question I didn't include in my proposal. Does someone have to > explicitly request the vote, or would they be put forward by someone else? I think it should be driven by the person themselves, mostly because I have difficulty figuring out what business it is of mine whether or not you desire to vote or not. The point I was trying to make is that voting is connected with a desire to contribute to the management of the meta community, and isn't some sort of special status or recognition. (One stray thought I had was to explore the ramifications of making "contributership" in the OGB CG the way people got to vote on OGB things - like elections, referendums, etc - people that wanted to drive the community would simply join the "community" CG...) >> The ARC Community >> A "special" CG where the CONTRIBUTERS are defined to be >> the ARCHITECTS from the various COMPONENTS and PROJECTS. > > Is this the existing ARC(s)? Not really... > > Why can't architects come from SIGs? In fact, given the broader base, > SIGs ought to be a good place to find architects. Oops? :-) Good catch. > If the ARC exists at that level, then there's something missing. While > the ARC ensures that what we do is done right, it doesn't define what we > do. Where is the part of the organization that decides what we should > work on? The COMPONENT CG that is responsible for the thing that is being developed. >> The AT LARGE Community Group >> A "special" CG whose CONTRIBUTERS don't fit elsewhere. > > In my view, the existence of the at large community is a bug, and it > should be eliminated. (Especially once you don't tie community suffrage > to roles in CGs.) Good discussion fodder :-) > It should not be part of governance to define those relationships. IMO, it should define the potential relationships, but not dictate the specifics. > Making project creation easy (trivially easy) +1 > Going back a page or two, I'm starting to think that how the ARC fits > into all this is what we really have to work out. My assumption is that the ARCs are connected to COMPONENTS in that each COMPONENT has an architecture that evolves over time, and to PROJECTS, which are the mechanism by which that architecture changes. How that connection is realized is yet another task to do... -John
