Martin Bochnig wrote:
if you do see a difference {community <--versus--> project}, then okay. i would appreciate it, if someone could and actually would explain it to me.
I believe that there are several different/conflicting definitions in play: Scenario #1: The proposed constitution ARTICLE VII. Community Groups 7.1. Purpose. In order to promote a diversity of activities within the OpenSolaris Community and to provide a means for self-governance within those activities, the Open- Solaris Community is held to be composed of Community Groups that are initiated by the OGB for the purpose of focused management and accomplishment of a given set of activities. Community Groups are, in turn, responsible for initiating and managing projects to accomplish those activities. The OS.o website definitions: OpenSolaris communities are social groups whose members engage in open conversations and will have representation in the governance process. Although communities do not have source repositories, it's expected that communities will endorse technical projects and have projects of their own. OpenSolaris projects are collaborative efforts that produce objects such as code changes, documents, graphics, or collaboratively authored products. Projects will have code repositories and committers and can live within a community or independently. The majority of existing OS.o communities: A community can also be a collection of people interested in a common aspect of OpenSolaris, such as User Groups, Marketing, or Performance. The "projects" spawned by these communities tend to be specializations of the umbrella group (one for each city where there is a user group, one for each performance enhancement effort...); these communities do not necessarily "have" a source tree, but rather leverage one or more other community's. The "traditional Solaris Perspective A community corresponds to a component or technology. Or maybe a better analogy is a C-Team. It controls a source tree, and acts as a gatekeeper for changes that go into its component. A community also spawns projects (development efforts) that may in the future integrate back into its source tree. This is exemplified by the OpenSolaris ON and JDS Communities. ============================== I would like to see this evolve into an environment where there are three types of grouping: COMPONENTS, COMMUNITIES and PROJECTS. COMPONENTS (such as ON, Documentation, JDS) would be very much like C-Teams or Steering Committees. They manage source trees and have a set of PROJECTS under development. COMPONENTS will require a long term commitment and a small set of core developers to guide them over their lifecycles. Think of traditional Sun Consolidations, Source Forge projects, and the various Apache efforts. The tasks related to managing a COMPONENT are gatekeeping, publishing of "releases", program management, prioritization of PROJECTS, schedule related decision making, etc. Next come COMMUNITIES, which are the social groups that do things that cross COMPONENT boundaries. They have their own web and hg archive repositories, but their focus is on leveraging some common theme across many COMPONENTS. User Groups, Performance, Security, ARC and Marketing all fit here. COMMUNITIES are expected to be cheap and easy to create by anyone (think Yahoo/Google/NetNews groups). They are also easy to disband. Among their "tasks" is to be a fertile source for new ideas that drive the creation of PROJECTS in various COMPONENTS. Finally, PROJECTS are where development work actually gets done. PROJECTS fall out of the daily evolution and growth of COMPONENTS as they interact with the various COMMUNITIES. Think of PROJECTS being equivalent to bugfixes and RFEs... PROJECTS can be managed (ARC, design and code reviews, schedules and roadmaps, ...) have sets of contributers (core and otherwise) affiliated with them, and integrate back into their COMPONENT. PROJECTS can be nested, providing for things like a PRINTING PROJECT having bugfixing subprojects as well as new feature developments like Presto and Tamarack within its scope. -John _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org