This document defines the Ethereum OASIS Open Project's community governance per OASIS Open Projects Governance Policy.
Our primary goal is to increase the minimum quality of Ethereum-related standards. We aim for the mean quality of standards that pass through our process to be greater than the mean quality that have not.
The Ethereum OASIS Open Project community is governed by this document and in accordance with OASIS Open Project Rules. The purpose of this document is to definine how community should work together to achieve its technical goals.
The Ethereum OASIS Open Project aims to work by lazy consensus within each TSC, as described under Decision Making below. Each TSC is responsible for determining when it has lazy consensus.
Within a TSC, those who show up and do the work get to make the decisions.
The TSC should be open to changing decisions based on new information, if a consensus emerges to make such a change.
The following code repositories are governed by the Ethereum OASIS Open Project community and maintained under the project namespace:
- Ethereum OASIS Project repository: The main repository.
- baseline
- baseline-website
All members of the community must complete and abide by the Required Legal Agreements, which includes abiding by the OASIS Open Projects Code of Conduct. Failure to meet these requirements means a contributor is no longer eligible to participate.
- Contributor: People who have contributed to a TSC repository in the last 2 years. Anyone can be a contributor, so long as they agree to contribute under the terms of this document.
- Technical Steering Committee (TSC) chair: one or more persons appointed by the Project Governing Board to ensure the TSC runs smoothly. The chair is empowered to suspend a contributor temporarily or permanently (for example for egregiously or repeatedly breaching the Code of Conduct). Appeals can be sent to the PGB under the same 2/3 majority rule used for overturning consensus decisions.
- Project Governing Board (PGB): The Project Governing Board is charged with ensuring the overall project runs smoothly, as described below.
Each Technical Steering Committee (TSC) has a chair (or co-chairs) appointed (or removed) by the PGB. The chair of a TSC is responsible in the first instance for the day-to-day functioning of the TSC. The chair of each TSC should have a firm understanding of the technology under the TSC's purview, and the skills of a Technical Project Manager.
The Project Governance Board (PGB)'s responsibility is to ensure that every TSC is running reasonably well. With a special majority, the PGB can
- overturn or confirm a TSC's declared consensus;
- replace a TSC chair;
- determine that a participant has failed to abide by the Code of Conduct, and declare them ineligible to participate for a term the PGB decides;
- create or close TSCs;
- appoint its own chair;
- change this governance document.
The PGB also follows and is responsible for upholding the OASIS Open Projects Rules.
The PGB is comprised of one representative from each Sponsoring organization. Additionally, each TSC Chair is a member of the PGB. The PGB roster is maintained at https://github.com/ethereum-oasis/oasis-open-project#governance
Editors are appointed (or removed) by the relevant TSC chair(s). Any Contributor is eligible to be an Editor.
Editors are expected to be actively involved in discussion of Proposals and helping them reach the quality level required to reach Candidate stage, and more generally to actively maintain the overall quality of their TSC's specification(s).
As defined in Decision Making, Editors are empowered to interpret the "Lazy Consensus" of a TSC, subject to direction from the chairs to implement a formally declared decision.
To start a new TSC, there must be
- a request from at least three sponsoring organizations who commit to participating
- a named Chair and Vice Chair who have agreed to the expectations for chairs
Although it is not required, ideally a proposed TSC will have at least 5 initial participants.
To be considered active, a TSC must satisfy the following heartbeat requirements:
- at least 3 active participants representing at least 2 different companies
- at least 1 commit per month in one repo
Any TSC failing to meet one or more of the above heartbeat requirements is considered inactive.
Note that the PGB may permit the formation or continuation of a TSC that does not meet the above requirements.
The Ethereum OASIS Open Project supports all of its TSCs. However, if a TSC would like additional resources, beyond those provided by default by OASIS, to support its initiatives, it may seek additional funding.
- Only Ethereum Open Project Sponsors may do this. Any Sponsor may provide additional funding through OASIS that is designated for a specific TSC to allocate.
- No advance vote or approval by the PGB is required.
- The TSC determines where to direct the funds collected, either directly or via a process they establish.
- The TSC and its projects may not use the OASIS or Ethereum Open Project names when seeking or using additional funding unless the PGB has been notified in advance.
- The TSC must give advance notice to the PGB before disbursement of any funds.
- The PGB may veto the acquisition or use of such funding at any time for any reason; the intent is to ensure that the acquisition and use of any such funding is consistent with the overall goals of the Ethereum Open Project.
If a TSC chooses to seek funding outside of the OASIS funding path, they still must not use the OASIS, Ethereum Open Project, or TSC project names when seeking or using additional funding unless the PGB has been notified in advance.
The Project Governing Board may close a TSC at any time.
An active TSC may only be closed with a Special Majority Vote of the PGB.
Any TSC which is inactive may be closed with a Full Majority Vote.
A TSC which has been inactive for at least 6 consecutive months may be closed with a Simple Majority Vote.
Note that closing a TSC ends any conference calls and specification editing privileges but will not automatically remove any materials.
Everyday TSC decisions will be reached by lazy consensus. Editors are empowered to implement the consensus of a TSC as they see it. The TSC chair is empowered to direct the Editor(s) to make a change reflecting a decision of the TSC.
If the chairs of a TSC determine that consensus is not possible, then the TSC will not publish any output.
Any TSC lazy consensus decision can be overturned by a
The PGB is unlikely to overturn a decision based on a single objection from a contributor who has barely participated, or an apparent "branch-stacking" (aka Room Packing) exercise.
Lazy consensus does not apply to certain decisions of the PGB, as defined elsewhere in this document.
Out of respect for other contributors, major changes should also be accompanied by a post on an email list or bulletin board (i.e., the OASIS-provided mailing list for each TSC) as appropriate. Author(s) of proposal, Pull Requests, issues, etc. will give a time period of no less than seven (7) working days for comment and remain cognizant of popular observed world holidays.
Other maintainers may chime in and request additional time for review, but should remain cognizant of blocking progress and abstain from delaying progress unless absolutely needed. The expectation is that blocking progress is accompanied by a guarantee to review and respond to the relevant action(s) (proposals, PRs, issues, etc.) in short order.
Lazy Consensus is practiced for all projects in our org, including the main project repository, community-driven sub-projects, and the community repo that includes proposals and governing documents.
Lazy consensus does not apply to some PGB decisions identified elsewhere in this document, such as:
- Appointing or Removing TSC chairs or PGB Members
- Removing TSC Members, other than for failure to abide by the formal legal obligations described below
- Moving a specification to the OASIS standards track
A Special Majority Vote is a vote in which at least 2/3 (two thirds) of the eligible voters vote "yes" and no more than 1/4 (one fourth) of the eligible voters vote "no". These numbers are based on the total number of eligible voters in the committee. Abstentions are not counted. For example, in a Committee in which there are 30 Voting Members, at least 20 Voting Members must vote "yes" for a motion to pass; but if 8 or more vote "no" then the motion fails.
Certain issues require a Special Majority Vote of the PGB, such as appointing TSC chairs or changing this governance document.
Large changes, including new features, should be preceded by a proposal. This process allows for all members of the community to weigh in on the concept (including the technical details), share their comments, ideas, and use cases, and offer to help. It also ensures that members are not duplicating work or inadvertently stepping on toes by making large conflicting changes.
The TSC's project roadmap is defined by accepted proposals. Each TSC accepts and develops proposals in a process patterned after the five development stages in the TC39 process document:
- Strawman (a description of an idea)
- Proposal (a formal request that it be considered for inclusion)
- Draft (a "specification-shaped" version of the proposal to be considered for implementation)
- Candidate (a "standard-ready" version for implementation testing before formal adoption)
- FInished (stable, in the formally published release version)
TSCs may tweak the process, and if they do so must record TSC-specific processes in a "Contributing.md" file in their project's main repository.
Each proposal should be developed in a separate GitHub repository, which is then merged into the main repository once it has been accepted into the canonical specification.
To make a feature request, document the problem and a sketch of the solution with others in the community and TSC. One place to do this is in the respective OASIS TSC mailing list or Discourse.
Your goal will be to convince others that your suggestion is a useful addition and recruit TSC members to help turn your request into a Proposal and shepherd it to Finished.
Contributors to any TSC project must abide by the OASIS Open Projects IPR Policy and Apache 2.0 License agreement as outlined in the license.md file.
All contributors are required to make these rights available by signing a Contributor License Agreement (CLA) and patent non-assert for non-trivial contributions releasing all contributions under Apache2. If you have questions about these policies, please contact the OASIS Open Project Administrator.
All participants must also abide by the terms of the OASIS Open Projects Code of Conduct.
Each TSC will probably create their own lifecycle. But as a possible default, each proposal can be marked with different status labels to represent the status of the proposal:
- New: Proposal is just created.
- Reviewing: Proposal is under review and discussion.
- Accepted: Proposal is reviewed and accepted (either by consensus or vote).
- Rejected: Proposal is reviewed and rejected (either by consensus or vote).
Each TSC specification will only be considered complete when:
- It has appropriate documentation
- It has a test suite for all normative statements in the specification
Examples of acceptable documentation:
Examples of insufficient documentation:
Substantive changes to this document may be made by a Special Majority Vote of the PGB. Changes should be made as Pull Requests on this document. Votes should be cast as reviews - approve or request changes.
If a PR is 7 days old, and there are sufficient reviews that the next vote meets the requirements for approving a change, the voter can merge the PR.