Skip to content

Latest commit

 

History

History
113 lines (84 loc) · 4.58 KB

GOVERNANCE.md

File metadata and controls

113 lines (84 loc) · 4.58 KB

Governance Model

This document is inspired by the Meritocratic Governance Model composed by OSS Watch. It should not be considered set in stone and may evolve over time as the project grows.

Overview

This is a meritocratic, consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the project community.

Roles and Responsibilities

Contributors

Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process.

In addition to their actions as users, contributors may also find themselves doing one or more of the following:

  • supporting new users (existing users are often the best people to support new users)
  • reporting bugs
  • identifying requirements
  • providing graphics and web design
  • programming
  • assisting with project infrastructure
  • writing documentation
  • fixing bugs
  • adding features

Contributors engage with the project through the issue tracker, writing or editing documentation, and participating at our Oasis Network Community server on Discord. They submit changes to the project itself via pull requests, which will be considered for inclusion in the project by existing committers (see next section).

Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before.

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time.

Contribution Process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. The Oasis Network Community server on Discord is the best place to ask questions, and the Oasis Protocol GitHub is the best place to see open bugs, open proposals and more.

For details on how to contribute, see CONTRIBUTING.md.

Decision Making Process

Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced. All non-sensitive project management discussion takes place in the Oasis Protocol GitHub via issues and Architectural Decision Records (ADRs).

In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

ADRs and Lazy Consensus

Decision making typically involves the following steps:

  • proposal,
  • discussion,
  • vote (if consensus is not reached through discussion), and
  • decision.

Any community member can make a proposal for consideration by the community and can do so by creating an issue or pull request proposing an ADR. Discussion of the proposal can then take place using issue or pull request comments.

In general, as long as nobody explicitly opposes a proposal or patch, it is recognised as having the support of the community.

For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal.

In case consensus is not reached through discussion, the project committers may vote to either accept the proposal or reject it. Votes are cast using comments in the proposal pull request. The proposal is accepted by a simple majority vote.