OGB Group Management Guidelines
From Genunix
Group Management Guidelines
This is a process and procedures document that is referenced by the OGB_2008/010_OpenSolaris_Constitution_2009 It is maintained by the OGB, and is expected to evolve as needed to meet the needs of the community.
Group goals
- User Groups:
- build a vibrant and active local community of OpenSolaris enthusiasts.
- Encourage and empower user group members to try new things with OpenSolaris,
- get involved in other aspects of the community and to
- bring others into the community.
- Communities:
- build a vibrant and active virtual community of OpenSolaris enthusiasts focused on some area of expertise.
- provide help/resources/information to others who may be interested in your areas of expertise
- Projects:
- define a technical problem or enhancement
- bring interested people together to solve the problem or work on the feature
- deliver results in a form that can be used by the rest of the community
- Electorate:
- help govern the community at large
- make sure that the community is running smoothly, and that disputes are resolved quickly, to the benefit of all.
Decision-Making and Voting Procedures
Most of a Groups's work is simply done by individual Contributors within a climate of ongoing discussion, informal group consensus, and a general desire to meet the group's shared objectives. However, occasional conflict is an inevitable part of working together to solve complex problems. The voting procedures below are designed to support both friendly collaboration and individual innovation, while at the same time providing adequate oversight for the OpenSolaris Community as a whole by enabling equal participation in formal decisions regardless of a person's location or time zone.
The voting procedures have been used by OpenSolaris Community Groups in the past to determine how future conflicts will be resolved so that volunteers on a project need not fear differences of opinion: contrary ideas can be voiced without derailing progress. The objective of using these voting procedures is to avoid unnecessary conflict over changes, while at the same time encouraging opinions that work towards producing quality products in a timely manner.
The historical voting procedures are documented here to provide a guide for groups who desire to use formal voting for decision-making, but are not required. The OGB encourages groups to devise a mechanism for decision-making that suits their goals and, if different from the following formal voting procedures, to document those decision-making mechanisms on their groups wiki pages.
Development Practices
Community Groups may or may not own development and maintenance of consolidation source, see the OpenSolaris.org Downloads page for a complete list of consolidations. If a consolidation is owned by a Community Group, specific instructions for development processes should be documented on the wiki pages for the community group with links to the source files and applicable licenses. In general, Community Groups developing code that is ultimately part of the ON consolidation follow the ON Development Process. Community and Project source code repositories are generally available through the OpenSolaris.org SCM Console and specific instructions for access should be documented on the associated wiki pages. Refer to the OpenSolaris.org Site Map for a complete list of developer tools available for reviewing, testing, and packaging code for OpenSolaris.
Location
Decisions by a groups are made by vote or consensus on a public meeting place that is most applicable to the action being discussed. For example, groups decisions that are specific to a single project are made through discussion and voting/consensus on the asynchronous meeting place (e.g., mailing list) for that project, whereas general Community Group decisions are made on the Community Group's general discussion place. Some discussions, such as investigation of security issues prior to their publication and nominations for Core Contributor status, are expected to take place in private prior to any public vote by the group.
Again, groups should define and document their own voting procedures, if they differ greatly from the following, widely used voting practices of Community Groups.
Votes
Each Core Contributor of a Community Group has the right to one binding vote on each proposed action of the Community Group. Other Participants may express their opinions through non-binding votes. A Core Contributor may change their own vote on a given action until such time as the action is no longer applicable (e.g., decisions regarding a given product release are final once the release is made public). Votes are expressed in the range [-1,1] with the following meanings:
| +1 | Yes, "Agree," or "the action should be performed." A +1 vote indicates that the voter is in favor of implementation of the proposed action. |
| ±0 | Abstain, "no opinion," or "I am happy to let the other group members decide this action." A vote in the interval between 0 and 1 (such as +0.5) can describe varying degrees of support for the proposal but still counts as an abstention. |
| -1 | No, "Disagree," or "the action should not be performed." A vote in the interval between 0 and -1 (such as -0.9) can describe varying degrees of disagreement with the proposal but still counts as an abstention. On actions where consensus is required, this vote counts as a veto if it includes an explanation of why the veto is appropriate and at least one other Core Contributor agrees that the explanation is valid ( regardless of their own vote). |
Voting Systems
Decisions of a Community Group are determined by several related voting systems, chosen per action type based on the degree of consensus or quorum needed to make the decision:
| Voting System | Approved by | Action Types |
|---|---|---|
| Consensus | At least three (3) binding +1 votes and no -1 votes (i.e., unanimous with a minimal quorum of three votes). | Putbacks (when subjected to vote). Addition of Core Contributor. Removal of Core Contributor (subject must abstain). |
| Majority | At least three (3) binding +1 votes and more +1 votes than -1 votes (i.e., majority vote with a minimal quorum of three +1 votes). | Design choice. Release plan. Product release. Facilitator nomination. Documentation (when subjected to vote). |
| Assumed | Approval is assumed unless a -1 vote is received, after which the action is reverted or the issue is decided by Majority or Consensus vote, depending on the type of action. | Putbacks. Documentation. |
Voting Period
Actions requiring a vote shall have a voting period of no less than seventy-two (72) hours. Actions are actionable before the voting period expires if all Core Contributors have voted and the issue would be approved by those votes.
Appeal
Once a decision is made, an action can only be revisited (brought to another vote) if at least one voter on the prevailing side of that decision declares a desire to change their vote and proposes a new vote on the action. There is no mechanism for escalation of decisions legitimately made according to these voting procedures. If it is believed that these procedures were not followed and, after being informed, the group refuses to revisit the decision, then a review of the group's procedures may be requested of the OGB. Upon review, the OGB may act to terminate the group, partition the groups into multiple groups, or provide advice to the groups; the OGB shall not make decisions for the groups.
Promotion of group members
- Participant to Affiliate/Developer: Must provide an example of at least one significant contribution which the participant has made towards the goals of the Group. If the Participant wishes to also become a Member of the Electorate, then the OGB Electorate Membership Process needs to be followed.
- Affiliate/Developer to Leader: The contributor must show demonstrated leadership talent and ability.
Dispute resolution: Rebuke in private, praise in public. Code (aka leadership and action) wins over passive debate. Try to get together in person (have a beer!) rather than rathole in an online flamefest.
