This document defines the Ethereum OASIS Open Project's community governance per OASIS Open Projects Governance Policy.
Our primary goal is to provide a neutral forum for diverse stakeholders to create high-quality specifications that facilitate Ethereum’s longevity, interoperability, and ease of integration. The Ethereum OASIS Open Project intend to develop clear, open standards, high-quality documentation, and shared test suites that facilitate new features and enhancements to the Ethereum protocol.
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 Open Project repository: The main repository.
- baseline
- baseline-website-v2
- L2
- TokenScript
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.
- 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 Simple Majority Vote, the PGB can
- appoint a TSC chair or co-chairs as recommended by the TSC
With a special majority, the PGB can
- overturn or confirm a TSC's declared consensus;
- replace a TSC chair, before the end of the chair's term, when the chair has previously been appointed by the PGB;
- present a complaint to OASIS staff that a participant has failed to abide by the Code of Conduct and ask that OASIS undertake corrective action;
- 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, and any Standing Rules it adopts.
The PGB is comprised of one representative from each Sponsoring organization, along with TSC representatives as follows.
The TSC may appoint one, and only one, TSC member to be its representative on the PGB and vote on the PGB, and that person does not have to be a chair. As with all PGB members, this representative's participation is governed by OASIS Open Project Rules section 15.3.
Non-voting guests are permitted at PGB meetings by advance invitation of a PGB chair.
The PGB roster is maintained here.
The PGB must have a Chair or two co-Chairs. Only members of the committee are eligible to be Chair or co-Chair. For the remainder of this section, Chair shall mean either the single Chair or each of the two co-Chairs, whichever the group has.
The Chair is elected by Full Majority Vote of the committee. If the committee does not have a Chair, then all activities, with the exception of the selection of a new Chair, are suspended.
Existing Chairs serve until they resign or are replaced in an election. Elections should be held every two years.
All PGB members, including the incumbent Chair, are eligible for nomination for the office.
In the event of a vacancy (such as a co-Chair stepping down prior to the conclusion of their term), an election should be held for a replacement to complete the term.
The process for electing the Chair shall be as follows:
-
The date for the Chair election shall be announced at least 14 days in advance on the PGB mailing list and copied to the general mailing list. The election shall take place during a regularly scheduled PGB meeting. An invitation to PGB members to nominate themselves or others for Chair must be included. PGB members may nominate themselves by sending an email to the PGB mailing list or in person during a PGB meeting. Where a member nominates a third party that nomination must be explicitly accepted by that third party, either verbally at a meeting or by email to the PGB.
-
On the day of the election, the sitting Chair shall review the nominations received and then ask for any in-person nominations from the floor.
-
If only one candidate is standing for Chair, the sitting Chair shall ask for objections to the candidate's approval. If no objections are heard, the new Chair will be declared elected by unanimous approval and the sitting Chair shall turn the meeting over to the new Chair. If an objection is heard, the sitting Chair shall take a roll call vote.
-
If two or more candidates are standing for Chair (or either Chair position, if the election is for two co-Chairs), the sitting Chair shall hold a roll call vote. The winning candidate must still reach Full Majority in order to win election.
-
If the meeting either does not or mathematically could not reach a Full Majority Vote, the sitting Chair may declare that the election will be held by 7-day electronic ballot. If only one candidate is standing, the sitting chair may state the ballot as a call for objections. If, after 7 days, no objections have been received, the new Chair will be declared elected by unanimous approval.
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:
- At least one sponsoring organization must commit to participating in the new TSC (this may be an existing sponsor)
- There is an expectation that at least one new organization commit to becoming a sponsor and participating in the new TSC, or more if the project size and resource requirements justify it
- At least 3 organziations must commit to participating in the TSC (which may include non-sponsors)
- Although it is not required, ideally a proposed TSC will have at least 5 initial participants (which may include multiple participants from some organizations)
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.
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.
Any Sponsor may provide additional funding through OASIS that is designated for a specific TSC to allocate. Non-Sponsors may contribute additional funding as described in Non-Sponsor TSC funding.
Programs designed to solicit grants may be specific to individual TSCs.
In all cases,
- Grantors must be informed, before funds are committed, of any fees that will be deducted from their grants.
- No advance vote or approval by the PGB is required to accept a grant or allocate the funds. However, the TSC must give advance notice to the PGB before disbursement of any funds.
- Either OASIS or the PGB may veto the acquisition or use of such funding at any time for any reason. A statement to this effect must be included on any grants form. The intent of this requirement is to ensure that the acquisition and use of any such funding is consistent with the overall goals of OASIS and the Ethereum OASIS Open Project.
- The TSC determines where to direct the funds collected, either directly or via a process they establish. Note that Grantors have no direct control over use of funds within a TSC and thus cannot use this funding mechanism to direct priorities within the TSC.
- The TSC and its projects may not use the OASIS or Ethereum OASIS Open Project names when seeking or using additional funding unless the PGB has been notified in advance.
If a TSC chooses to seek funding outside of the OASIS funding path, they still must not use the OASIS, Ethereum OASIS Open Project, or TSC project names when seeking or using additional funding unless the PGB has been notified in advance.
Non-Sponsors of the Ethereum OASIS Open Project may fund grants at any time and in any amount. After deducting any administration fees assessed by the transaction processor, 25% of the proceeds will be used to fund Core Services, including marketing, with the remainder available for allocation by the TSC.
Grantors must be informed, before funds are committed, of the 25% assessment for Core Services.
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 Special Majority vote 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" (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 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.