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.
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.
Decision-Making and Voting Procedures
Most of a Collective's work is simply done by individual Contributors within a climate of ongoing discussion, informal group consensus, and a general desire to meet the collective's shared objectives. However, occasional conflict is an inevitable part of working together to solve complex problems. These voting procedures 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 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 is to avoid unnecessary conflict over changes, while at the same time encouraging opinions that work towards producing quality products in a timely manner.
Location
Decisions by a collective are made by vote or consensus on a public meeting place that is most applicable to the action being discussed. For example, collective 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 collective.
Collectives 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. 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. |
| -1 |
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). Initiate new project. Terminate project. 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 collective refuses to revisit the decision, then a review of the collective's procedures may be requested of the OGB. Upon review, the OGB may act to terminate the collective, partition the collective into multiple collectives, or provide advice to the collective; the OGB shall not make decisions for the collective.
Promotion of collective 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.
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.
