# THIS DOCUMENT IS OBSOLETE See https://github.com/ethereum-oasis/oasis-open-project/blob/master/GOVERNANCE.md ---- . . [ToC] # Ethereum OASIS Project Governance This document defines the Ethereum OASIS project's community governance per [OASIS Open Projects Governance Policy](https://github.com/oasis-open-projects/documentation/blob/master/policy/project-governance.md). # Our Goal 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. ## Overview The **Ethereum OASIS Project** community is governed by this document and in accordance with [OASIS Open Project Rules](../board-docs/open-projects-rules.md). The purpose of this document is to definine how community should work together to achieve its technical goals. The Ethereum OASIS Project aims to work by lazy consensus within each TSC, as described under [Decision Making](#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. ## Code Repositories The following code repositories are governed by the **Ethereum OASIS Open Project** community and maintained under the project namespace: * **[Ethereum OASIS Project repository](https://github.com/ethereum/oasis-open-project):** The main repository. ## Community Roles All members of the community must complete and abide by the [Required Legal Agreements](#Required-Legal-Agreements), which includes abiding by the [OASIS Open Projects Code of Conduct](https://github.com/oasis-open-projects/documentation/blob/master/CODE_OF_CONDUCT.md). 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. ## Project Leadership 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](https://www.jobhero.com/technical-program-manager-job-description/). ### Project Governance Board The **Project Governance Board** (**PGB**)'s responsibility is to ensure that every TSC is running reasonably well. With a [special majority](#Special-Majority-Vote), 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](https://github.com/oasis-open-projects/documentation/blob/master/board-docs/open-projects-rules.md). ### List of PGB Members * Daniel Burnett (@burnburn) - ConsenSys * Chaals Nevile (@chaals) - EEA * Tas Dienes - EF * Jory Burson (@jorydotcom / @OASIS-OP-Admin) - OASIS Staff ### Becoming an Editor 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](#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. ## Starting and maintaining a TSC ### Initial requirements 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. ### Maintenance requirements 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. ## Closing a TSC 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. ## Decision Making Everyday TSC decisions will be reached by [lazy consensus](https://communitymgt.fandom.com/wiki/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 $\geq 2/3$ majority of the PGB at the request of a TSC contributor. 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](https://en.wikipedia.org/wiki/Branch_stacking)" (aka Room Packing) exercise. Lazy consensus does _not_ apply to certain decisions of the **PGB**, as defined elsewhere in this document. ### Lazy Consensus 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 ### Special Majority Vote 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. ## Proposal Process 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](https://tc39.es/process-document/): * Strawman (a decription 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. #### Creating a new proposal 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. ## Required Legal Agreements Contributors to any TSC project must abide by the [OASIS Open Projects IPR Policy](https://github.com/oasis-open-projects/documentation/blob/master/policy/clas-and-special-covenant.md) 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)](https://github.com/oasis-open-projects/documentation/blob/master/templates/individual-cla.md) 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]([email protected]). All participants must also abide by the terms of the [OASIS Open Projects Code of Conduct](https://github.com/oasis-open-projects/documentation/blob/master/CODE_OF_CONDUCT.md). ### Proposal Lifecycle 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). ## Required conditions for acceptable complete specifications 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: * [The MDN JavaScript specs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse) * W3C's [Generic Sensor API](https://www.w3.org/TR/generic-sensor/) * [The Jello Paper](https://jellopaper.org) Examples of insufficient documentation: * [The Yellow Paper](https://gavwood.com/paper.pdf) * [webpack](https://webpack.js.org/concepts/manifest/) ## Updating Governance Substantive changes to this document may be made by a Special Majority Vote of the PGB.