Hi Glynn, Thanks for working on this much-needed document. I sent you a few comments a while back that I'm not sure I see reflected here. See http://mail.opensolaris.org/pipermail/ogb-discuss/2007-July/002108.html
My general point is that the constitution seems to require consensus voting for project instantiation and core contributor grants, while your wording implies that community groups have more leeway in that area. For example, you refer to "suggested" voting procedures, while my reading of the constitution is that they are required. Thanks, Nick Glynn Foster wrote: > 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. > _______________________________________________ > ogb-discuss mailing list > ogb-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ogb-discuss -- Nicholas Solter, Solaris Cluster Development http://blogs.sun.com/nsolter
