Hey,
Bonnie provided some excellent feedback off-line (thanks heaps!) - mostly a lot
of corrections to clean up the language, but she also pointed out a few
deficiencies. Given our discussions about reviewing it during today's OGB call,
I figured I'd release a 0.3.
There's still quite a few outstanding issues, among others, I think that we may
want to address
- Proposal of -user mailing lists, for user oriented discussion and/or
help (which nicely leads into today's discussion on list)
- What happens when a Leader is unresponsive and doesn't take
contributions for updating websites (or adding people to do it)
- Discussion related around what infrastructure people have access
to (in particular use of SCMs)
- The role of the Facilitator in Community Groups, and an approachable
way of knowing who the Community Group Contributors and Core
Contributors are
Glynn
==
Guidelines for Community Groups, v0.3
1) Introduction
Under the terms of the constitution, Community Groups have been set up
to self-govern their own interests and activities, particularly around
initiating and managing projects to accomplish those activies.
1.1) Community Group Creation
Community Group creation is set out in Article VII of the
Constitution. A proposed Community Group should ideally not
have conflicting goals with an existing Group, but exceptions
can be made if needed.
While the creation of Community Groups come with an added
degree of responsibility in providing official voting rights, it
may be appropriate to initially get an existing Community Group
to endorse a Project instead, and work towards building and
migrating to an official Community Group at a later stage.
2) Recommendations
2.1) Grant Updates
In Article III, Section 3.3 of the Constitution, a set of roles
are mapped out for involvement in OpenSolaris. Among the roles
to note for Community Groups are Contributors and Core
Contributors.
It is up to the Community Group to determine how it will recognize
involvement and grant people the designation of Contributor or
Core Contributor.
For example, a Community Group may decide that three or more "+1"s
are required from existing Core Contributors to designate an
individual as either Contributor or Core Contributor. The may also
decide to define what actions enable someone to move from Contributor
to Core Contributor and how someone can request a particular status.
Suggested voting procedures are detailed in Article VIII, Section
8.3 and 8.4 of the Constitution in the event of conflicts of opinion.
When a Community Group has determined a process for designating
people Contributors and Core Contributors, a Member of the Community
must send its list to ogb-discuss at opensolaris.org. The current OGB
Secretary will record the information. The list of Core Contributors
is used for voting, so any changes to the list must be sent when
changes occur. You can check the current list of grant allocations
on http://poll.opensolaris.org that the Secretary maintains.
All Core Contributors should be strongly encouraged to be active
and enthusiastic members of the Community Group and to help grow
the Community Group through leadership, good communication and
mentoring. They should be expected to subscribe to and participate
on relevant mailing lists.
2.2) Mailing Lists
A Community Group may request one or more mailing lists for its
needs as appropriate (details about how/where to make requests
are at the end of this section). Mailing list names should
indicate purpose and so should use one of the following suffices:
-dev: Developer dsicussion related to the topic
-discuss: General discussion related to the topic
-notify: Notification alias for code putbacks related
to the topic
It is up to the Community Group to decide whether a new project
warrants a ne wmaling list or whether use of an existing mailing
list is appropriate. It is often a good idea to watch traffic
for some period of time before creating a new list that will
separate discussion.
Private mailing lists may be desired by the Community Group
itself or by a Project endorsed by the Community Group if
sensitive issues need to be discussed. However, private lists
often prove harmful to the community and should be carefully
considered. It is up to the Community Group to determine whether
a private mailing list is required and how such a request for
a list will be approved. In all cases, the Community Group should
advertise that such a list exists and what conditions apply to
its subscription.
To request a new mailing list, or changes to existing ones, a
Facilitator of the Community Group should mail
website-discuss at opensolaris.org with details of their request.
2.3) Web Page Maintenance
Community Group and Project web pages can be edited by
designated Leaders. Leaders are listed at the top of each
Community Group and Project web page. Note that ability to
edit pages does not correspond to OpenSolaris membership
status (Contributor or Core Contributor).
Designated Leaders can add people to the Leaders list, and
encouraged to do so, as detailed in
http://www.opensolaris.org/os/communities/lead_reference/
2.4) Project Creation
Project creation is dependent on the endorsement of a Community
Group as detailed in
http://opensolaris.org/os/community/ogb/policies/project-instantiation.txt
Essentially, people contributing to a Community Group ask Core
Contributors of that Community Group to endorse creation of a
new Project. The Community Group defines the process it will
use to determine whether or not to endorse a Project.
For example, a Community Group may decide that three or more +1's
are required from Core Contributors within that community before
a Project is endorsed.
When a Project has officially been endorsed by a Community Group,
a Facilitator from the Community Group must send an email to
ogb-discuss announcing that fact. The following is an example
of such a mail
http://mail.opensolaris.org/pipermail/ogb-discuss/2007-July/002110.html
During this time, the Project may be granted web hosting facilities
(web pages, mailing lists and source code repositories) by mailing
website-discuss at opensolaris.org with the following information
- Project Name, ascii only
eg. nwam
(http://www.opensolaris.org/os/project/nwam)
- Project Title, single line title
eg. "Network Auto-Magic"
- Project Description, short description
eg. "A project for simplifying and automating network
configuration on Solaris"
A mailing list may also be created using the guidelines detailed in
section 2.2) Mailing Lists.
2.4) Community Group Decisions
It is the responsibility of each Community Group to manager its
activities and decision-making. This management can be done by
informal consensus or formal voting or a combination. All Community
Groups and associated Core Contributors are encouraged to act
responsibly and with the agreement of the Community Group members.
While formal voting can help make decisions, the process can also
alienate those who do not have a vote. Formal voting procedures
are detailed in Article VIII, Section 8.3 and 8.4 of the Constitution.
2.5) Code Review
A code review/ site/tool is available for use.
http://cr.opensolaris.org/
Access to this site is allowed for people with Contributor
or Core Contributor status within a Community Group. If someone
without such status wants to post code for review, they should
contact the Community Group sponsoring the associated Project
and request Contributor grant status as detailed in Section
2.1) Grant Updates.
3) Feedback
If you have comments on or questions about these guidelines, please
send email to ogb-discuss at opensolaris.org.
