Simon Phipps wrote:
> http://defect.opensolaris.org/bz/show_bug.cgi?id=1937
The more I think about this, the less I like the idea of making Projects be
at the same level as [SIGs, Consolidations, Distros and User Groups].
We are trying to simplify things. Moving from 44 CGs today to a
new order where we have 44 SIGS+Consolidatrions, 54 user Groups and
172 Projects gives us 270 top level things to manage. This is not
simplification in my book.
Maybe we are conflating too many things together? There are threads
here focused on simplifying too many things at once: Suffrage,
navigation, communication, decision making...
An alternative:
(I'll post PART 2 [specifics about a transition] in the morning -
there are not enuf hours in the day...)
=======================================================================
PART 1 - the basic structure
=======================================================================
We are a transparent community, everyone can watch what we do.
We are a community governed by those who contribute, so CONTRIBUTERs
have the right and responsibility to make the decisions that impact
their activities.
We are a community of communities. Governence of that metacommunity
is performed by CONTRIBUTERs who have chosen to contribute to that
governence.
Our community has structure:
User Groups are externally focused on specific geographical
or social demographics, and work to grow and inform the
community.
Special Interest Groups are internally focused on activities
taking place within the community, and work to set common
strategic direction across the entire community.
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.
=======================================================================
What follows are operational definitions of these various terms.
People and Roles
----------------
SEAT, VOICE and VOTE
Terms used to describe the various rights granted to parties in
a deliberative meeting. SEAT means you have the right to listen
and discuss, VOICE means you can make motions and amendments, while
VOTE means you have suffrage in any decisions being voted upon.
OBSERVERS
Anyone not defined below. Everyone has SEAT in all community
activities.
CONTRIBUTER
Anyone who has contributed to the community.
CONTRIBUTERS have VOICE in the OGB "community" and VOICE and VOTE
in the CGs they have contributed to and in any PROJECTS of those
CGs that they are affiliated with.
Anyone can become a CONTRIBUTER to a CG by providing the following:
* their account name on the OS.o website,
* a signed contributer agreement, and
* certification by the FACILITATOR of a CG that the person
has contributed to [PROJECTS in] their CG.
Once given, CONTRIBUTER status in that CG is permanent.
There may be different roles that CONTRIBUTERS assume, based on
a CG's decision making process and the type of CG, such as
EDITOR
a CONTRIBUTER who has some set of website content
management authority.
GATEKEEPER
a CONTRIBUTER who has some set of source or package
repository management authority.
FACILITATOR
a CONTRIBUTER who has some set of authority to speak
for, facilitate or otherwise manage the day-to-day
operation of the CG.
GOOD STANDING
Given by default to all CONTRIBUTERS, an individual
CONTRIBUTER may be stripped of their right to VOICE
and VOTE in a CG for [undesirable behavior] by a
majority vote of the rest of the CONTRIBUTERs in
that CG.
ARCHITECT
a CONTRIBUTER who represents a COMPONENT (or a set
of PROJECTS within a COMPONENT) in the ARC community.
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. VOTING MEMBERS have VOICE and VOTE in the
annual OpenSolaris Members Meeting.
OGB Member
Da Usual Suspects. They have VOICE and VOTE in the OGB community.
Types of Community Groups
-------------------------
The OGB
A "special" CG where the CONTRIBUTERS are defined to be
the elected OGB members. Responsible for the usual stuff.
The ARC Community
A "special" CG where the CONTRIBUTERS are defined to be
the ARCHITECTS from the various COMPONENTS and PROJECTS.
The AT LARGE Community Group
A "special" CG whose CONTRIBUTERS don't fit elsewhere.
SIG
A gathering place for people with a common interest related
to the internal activities taking place in the OpenSolaris
community.
A SIG:
* has mailing lists, web pages, CONTRIBUTERs and
OBSERVERS
* can affiliate with or endorse other SIGs, COMPONENTS,
USER GROUPS and PROJECTS.
* produce strategic artifacts that can be used by others to
better understand and align efforts across the larger
community.
While SIGs may have source and package repositories, they are
not primarily focused on creating or managing components.
USER GROUP
Similar to a SIG, but more focused on being an external-facing
geographical or social activity rather than the inward focus of
a SIG.
A USER GROUP:
* has mailing lists, web pages, CONTRIBUTERs and OBSERVERs
* can affiliate with or endorse other SIGs, COMPONENTS, USER
GROUPS and PROJECTS
* generates interest in the activities of the community and
* drives individuals to become CONTRIBUTERs, users and enthusiasts.
While USER GROUPS may have source and package repositories, they
are not primarily focused on creating or managing components.
COMPONENT
A sub-community that is focused on the lifecycle management of
things that become packages. Similar in concept to "Steering
Committees", "Apache Projects" and the like, they tend to
be focused on source code in a repository and the associated
release-related decision making that surrounds it (i.e.,
build schedule, alpha/beta cycles, release chartering,
CONTRIBUTER ROLE assignment, ...).
A COMPONENT has
* mailing lists, web pages, core contributers, contributers
and spectators.
* source and package repositories
* a set of PROJECTS where specific development activities take
place, many times consisting of (see below)
* 1 or more versioned CONSOLIDATIONS
* several to many NEW FEATUREs, and
* several to many BUG FIXes
COMPONENTS are created by promoting a PROJECT.
PROJECTS
An offshoot of a COMPONENT CG or another PROJECT, focused
on performing some aspect of the development process
for its sponsoring parent. PROJECTS may be "promoted"
to a COMPONENT if requested by the set of CONTRIBUTERS
to that PROJECT and its parent(s), subject to ratification
by the OGB. PROJECTS may also associate themselves
with other PROJECTS to indicate dependencies, overlap
or other types of relationships.
PROJECTS may be created by any CONTRIBUTER to that
COMPONENT. Existing CONTRIBUTERS are expected to work
with new participants to find or create new PROJECTS
for them to contribute to, thus creating new CONTRIBUTERS.
There are different types of PROJECTs, and PROJECTS may
change there types over time:
* A versioned CONSOLIDATION
(Sometimes called releases or branches when using
cvs or svn)
The CONTRIBUTERS to this type of PROJECT behave
as the C-TEAM for a COMPONENT's source code and
package repositories.
They are responsible for producing a specific named
and versioned deliverable for use/consumption
by others.
* A NEW FEATURE
Encompasses and coordinates the development efforts
needed to add a new feature to a COMPONENT.
FEATURES may be associated with a CONSOLIDATION,
or may be one themselves. ARC interaction is
desirable for NEW FEATURES.
* A BUG FIX
Encompasses and coordinates the development efforts
needed to fix a bug. ARC interaction is usually not
needed for these unless the bug fix requires
incompatible changes to a COMPONENT's existing
architecture.
clone a CONSOLIDATION's source repo, fix the
bug, test the fix, request to integrate,
integrate, test again, disolve PROJECT
* The first Version of a brand new thing
New features that could/should stand alone,
PROJECTS that need to be reused by multiple
COMPONENTS, ... and are expected to be promoted
into a COMPONENT of its own at some near term point.
[This is a sketchy place holder right now...]
