Hey Glynn,
Any update on the community group guidelines? Are we ready to adopt
them? Or are you looking for more feedback?
cheers,
steve
Glynn Foster wrote:
> Hey,
>
> At the last meeting I volunteered to write some *informal* guidelines of what
> the various Community Groups were expected to do in the day to day activities.
>
> The message that we're trying to express is that it is up to the Community
> Groups to figure out how to self-govern themselves in whatever way works best,
> rather than the OGB being involved all the time.
>
> Here's what I currently have as a first draft. There's probably heaps missing,
> or unclear content that I'd appreciate feedback on. What parts of what you
> need
> to get done are confusing? undocumented? hurdles? What suggestions do you have
> for other Community Groups?
>
>
> Glynn
>
> ==
>
> Guidelines for Community Groups, v0.1
>
> 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.
>
> 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.
>
> 1.1) Grant Updates
>
> Under the constitution (Article III, Section 3.3), 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.
>
> 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.
>
> 1.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
> -code: Code discussion related to the topic
> -discuss: General discussion 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.
>
> 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.
> Any requests for a private mailing list must get the approval
> from the OGB first.
>
> 1.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/
>
> 1.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
> 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 1.2.
>
> 1.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.
>
> 2) 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 details of what you would like to
> change.
> _______________________________________________
> ogb-discuss mailing list
> ogb-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/ogb-discuss
--
stephen lau // stevel at opensolaris.org | http://whacked.net
opensolaris // solaris kernel development
