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
