Thanks for putting this together so quickly Jim, comments inline... > Roles. There are three roles in the OpenSolaris community: > > 1. Participants: Those who are registered on opensolaris.org are > eligible to be participants in a user group, project, or community. > 2. Contributors: Those who have been recognized as having > substantially helped with the goals of a given group. That > person would have been allowed by a group to edit web pages, > commit code directly to a project gate, or help moderate a > mailing list, for example. Each user group, project, and > community may have their own set of standards for recognizing a > person as a contributor. > 3. Leaders: Those who have the responsibility of leading a user > group, project or community. For example, they may have the > final say to wrap up discussions, or they may decide the > technical direction of a given project. Leaders may appoint > participants to the level of contributor. Leaders may also > appoint participants/contributors to the level of leader. Each > user group, project, and community may have their own set of > standards by which a person is recognized as a leader. > While the "Leader" role is clearly scoped to a user group, project, or community - it's not immediately clear to me from the definition of the Contributor role what it's scope is. Perhaps, "That person is allowed by a group to edit the group's web pages, commit code to the group's gate, or help moderate its mailing lists" ? > > > Creating Communities, Projects, and User Groups > > Overview: Groups can be created, archived, reactivated and changed. > All groups are considered equal, and there is one process to create > all groups. > > Group Creation Process > > 1. Go to http://defect.opensolaris.org > 2. Create a new "bug" under Community > Infrastructure > Create > with the following information > 1. Your opensolaris.org user ID (required) > 2. Type (Community, Project, User Group) > 3. Community Name > 4. Title > 5. Description > 6. Leaders (opensolaris.org user IDs required) > 7. Mailing List Requirements > 3. Someone other than yourself with an Opensolaris.org user ID > needs to vote for the "bug" you just created. Group requests > will only be accepted once they have one or more votes from > people other than the originator. > 4. Wait. As someone becomes available, your request will be > processed by one of the admin team and you will be notified. > Perhaps we should define the "Admin" team, since that will surely raise questions for people inquiring about status. > > > Archiving > > >From time to time, a group may become dormant. But since it's never a > desirable situation to have unmaintained infrastructure on the web, > there is a process for archiving groups. If there has been no activity > from a group for six months, or at the discretion of the OGB or its > nominated committee acting in the interests of the community, the > following may happen: > > * Mailing list changed to 'no subscriptions' [note: may need to > note Jive forum status here too] > * Web page visibly tagged with 'Dormant' > * List of leaders/participants reset to zero > * SCM write disabled > There might be historical value in having the leaders/participants left intact. Is there any harm in doing so? > > > Disputes > > Disputes. Disputes among participants shall be resolved by the > respective group according to its normal decision-making procedures. > If a dispute extends into to the OpenSolaris community at-large, then > the participants may appeal to the OGB. Maybe explicitly define the scope to the group: "Disputes among participants within a Community, Project, or User Group shall be resolved by the respective group according to its normal decision-making procedures. If a dispute needs escalation beyond that group (i.e. if it extends into the OpenSolaris community at-large, or crosses group boundaries), then the participants may appeal to the OGB" > Suspension of Participants. The OGB is responsible for ensuring that > participation in the OpenSolaris community is constructive. When abuse > is reported to the OGB, the OGB will review a participant's actions in > the following way: > > 1. The OGB will notify the participant that his or her > participation in the OpenSolaris community is under review and > that the review will be completed within thirty days. The review > should occur in a closed session and remain private unless an > action is made to suspend the participant. > Is it the OGB or the Member Board that reviews the participant? > > 1. The OGB may order a temporary removal of the participant's write > access to the OpenSolaris community infrastructure until the > review is complete. > I think we should call out the specifics (e.g. does write access include the ability to post to mailing lists? Or just code repositories?) > > 1. Upon conclusion of the review, the OGB may vote to suspend the > participant's write access to the OpenSolaris community > infrastructure for up to six months. If the participant has > previously been subjected to a suspension, the OGB may recommend > expulsion. > 2. A suspended member may attend and vote at a meeting of the > members, in person or by proxy, subject to the normal rules of > conduct for that meeting. > Really?
cheers, steve -- stephen lau | stevel at opensolaris.org | www.whacked.net
