Hey,
Here's an update to the community group guidelines. Some of the changes I've
included in this draft are -
o Brief details of Community Group Creation
o Added more formal voting procedures laid out in
the constitution
o s/-code/-notify for notification aliases for code commits
o More detail about why private mailing lists might be required
o Code review, cr.opensolaris.org
During these updates, I'm inclining to move towards a more generic FAQ on many
of these items instead, ala
http://code.google.com/support/bin/topic.py?topic=10442
Thoughts, comments all welcome.
Glynn
==
Guidelines for Community Groups, v0.2
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. In practice, a proposed Community Group should
ideally not have conflicting goals with an existing one (though
exceptions can be made to this rule).
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
While Community Groups may self-govern how they see fit, the following
are a set of recommendations for the day to day running of such a group.
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 a process for recognizing
their community involvement.
For example, a Community Group may decide that three or more +1's
are required from Core Contributors to update an individual to either
'Contributor' or 'Core Contributor' status. More formal voting
procedures are detailed in Article VIII, Section 8.3 and 8.4 of
the constitution.
When a Community Group has decided on this, a facilitator must
acknowledge these status updates to ogb-discuss at opensolaris.org where
the current OGB secretary can record them.
All Core Contributors should be strongly encouraged to be active,
and enthusiastic members of the Community Group, and help to grow
their respective communities through good communication and
mentoring. They should be subscribed to the relevant -discuss
mailing lists, and actively following the discussion.
2.2) Mailing Lists
A Community Group may request a mailing list for their needs as
appropriate. Mailing list names should give some indication of
their purpose, and have one of the following set of suffixes:
-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 new mailing list, or whether an existing mailing list
could serve that purpose. It may not neccessarily be the best
decision to split discussion off into a separate forum if there
is too little traffic being generated.
Private mailing lists may be desired if particularly sensitive
issues need to be discussed by a given Community Group, however
they should be rarely needed and often prove harmful to the
community. It is up to the Community Group to determine whether
a private mailing list is required, and what the process is
for approving that request.
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 currently edited
by designated leaders as listed in the 'Leaders' sections. This
does not correspond to membership status ('Contributor' or
'Core Contributor') of OpenSolaris.
It is up to the current set of designated leaders to make that
call to add additional people to maintain the web pages in
question, and this can be done by using the web application
as detailed in
http://www.opensolaris.org/os/communities/lead_reference/
2.4) Project Creation
Project creation is dependant on the endorsement of a Community
Group as detailed in
http://opensolaris.org/os/community/ogb/policies/project-instantiation.txt
Essentially this means that contributors within a Community Group
may ask for endorsement by the Core Contributors of that Community
Group. It is up to the Community Group to decide on their guidelines
for what may be an acceptable process to determine whether a project
gets endorsement.
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 must acknowledge that endorsement to
ogb-discuss at opensolaris.org.
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 the Community Groups to come to a set
of decisions during their day to day activities and interests. This
can be done by an informal consensus, or more formal vote. All
Community Groups, and in particular Core Contributors should be
encouraged to act responsibly and with the agreement of the
community. While formal votes help to bring a decision to a precise
conclusion, they may 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 is available for contributors to post code changes
and have them reviewed by peer contributors
http://cr.opensolaris.org/
Access to this site is allowed for all participants of a Community
Group with a 'Contributor' or 'Core Contributor' grant status. If a
contributor is looking to post a review, they should contact their
sponsoring Community Group and request 'Contributor' grant status
as detailed in section 2.1) Grant Updates.
3) Feedback
If you have any comments on these guidelines, or would like to see the
guidelines address something that isn't covered, please email
ogb-discuss at opensolaris.org with feedback.
