The Baseline Protocol is an openly governed project and standards body.
In order to ensure clean IPR that allows the Baseline Protocol to remain an open technology, OASIS rules require an Entity CLA for persons or organizations contributing on behalf of a legal entity, and an Individual CLA for community contributions. You must sign the ICLA before your pull requests to the baseline repository will be merged. Check here to see if your company has signed the ECLA.
The Baseline Protocol shall be a project within the Ethereum-Oasis project of OASIS through at least May 31, 2020. The Project Governing Board (PGB) of the Ethereum-OASIS project, which was established in 2019 and is currently supported by the EEA and the Ethereum Foundation (EF), currently consists of Dan Burnett (ConsenSys), Tas Dienes (EF), and Chaals Neville (EEA) – supported by Jory Burson (OASIS). The Baseline Project shall be supported under the existing contract with OASIS and shall require no additional fees than those already paid by EEA/EF and the parties to the Open Ethereum Project until May 31, 2020. Negotiation to continue the Baseline Project with OASIS shall be conducted between March and May 2020.
The Baseline Protocol shall be governed by a Technical Steering Committee, with 7, 9 or 11 Members, one of whom will serve as TSC Chair or two as TSC Co-Chairs. The current number of TSC members is 11.
A quorum of two-thirds of the TSC members can conduct any vote required of the TSC during any given meeting. Disputes on whether a matter should be tabled for a different TSC meeting can be presented to the PGB of the Ethereum-OASIS project for a decision. A move to table a matter can be lodged during a TSC meeting, and it shall be tabled and submitted to the PGB with a simple majority vote. If a majority cannot be achieved during the meeting, a minimum of two members that were present at the meeting in question may dispute the matter after the fact to the PGB.
No legal entity (or set of entities controlled by a single party) shall hold more than three seats out of eleven (or two seats out of seven or nine) on the TSC during any given period.
The TSC's members are elected annually in September/October, concluding on the last day of that month, with the first elections held in September, 2020. The period for nominations will be announced no less than 30 days prior to elections. The method and management of the nominating process and the elections will be communicated to the community by the various channels in that timeframe.
TSC members who miss two consective TSC meetings without prior notice will lose their voting right at the end of the second meeting missed and will not be counted towards quorum in a TSC meeting. However, they shall retain all other rights, privileges, and obligations afforded to TSC members. A TSC member who has lost voting rights by missing two meetings may regain voting rights by (a) declaring to the Chair their desire to regain voting rights and then (b) attending two consecutive meetings of the TSC. Their rights will be restored at the end of the second meeting.
A TSC member is eligible to lose their seat for violating the Code of Conduct through a simple majority vote of TSC members that are not being considered for removal.
After removal, a special election shall be governed by Oasis for the vacant seat among contributors. The seat will be up for re-election at the next regular election cycle.
The PGB of the Ethereum-OASIS project has the option to consider extenuating circumstances and determine whether or not to remove a member, if the TSC itself cannot come to a determination.
In the event that a TSC Member resigns more than 30 days before the end of their elected term, they may nominate a replacement. The resigning member shall consider the replacement’s active participation in, contribution to, and commitment toward the Baseline Protocol community when selecting such candidate.
The position shall remain open for 30 days or until 7 days after the next steering committee meeting, whichever comes first (the open period). During that period, any other TSC member or Active Contributor to the /baseline github repo, may nominate another person.
If there is only one candidate, the TSC Chair must issue a “call for objections” to the remaining TSC members. If there is unanimous approval (no objections), then the candidate is elected. If there are one or more objections recorded, the position must be put up for a vote of the Active Contributors according to the rules of normal TSC voting as written in this document.
If more than one candidate is nominated during the open period, the position must be run through the same voting process used during normal periodic TSC elections.
The “call for objections” or the vote must be conducted during a live TSC meeting that has a quorum present or must be conducted over a seven day asynchronous voting period via any messaging or voting system approved for use by OASIS. In a “call for objections,” non-responses shall be considered assent. In a vote, non-responses must be ignored. In the event that the number of TSC Members resigning in the same open period reduces the total number of TSC members to below a quorum from the previous number, then a new full TSC must be elected following the standard procedure for periodic elections.
Baseline Maintainers have advanced code repository permissions and responsibilities.
First, one must attend at least two consecutive Baseline Core Dev meetings and contribute to the project through PRs, workgroups, or other contributions. E-mail baseline-[email protected] to be added to the Core Devs meeting invite.
If the Baseline Maintainer request is denied or poses concerns, the proposer or other Baseline Core Devs can escalate to the TSC by informing Oasis or a TSC member.
Maintainers must notify the private 'maintainer' Slack group or a community leader if unable to attend a Baseline Core Devs session.
The initial number of maintainers required to merge a pull request to the main repository in Github is three, but may be amended to no fewer than two by a simple majority of the maintainers.
To step away from being a Baseline Maintainer, notify the other Maintainers or TSC members that you would like to relinquish your Baseline Maintainer status.
If a Maintainer misses three consecutive meetings without prior notice, a community member will submit a PR to remove the member's GitHub ID from the Code Owners File. If the PR is merged through the PR approval process, the Maintainer is removed.
If a Maintainer is removed due to the attendance policy and wants to recommit, they must attend 2 consecutive Core Dev sessions, notify the group of intent to re-commit, then submit the PR to be added back to the Code Owners File.
Maintainers can also be voted for removal for violating the Code of Conduct (https://github.com/eea-oasis/baseline/blob/main/CODE_OF_CONDUCT.md) or expectations.
Two-thirds of all current Maintainers constitute a quorum for a meeting involving a question of removal. A simple majority vote from Maintainers is required to remove a Maintainer, but the TSC may be brought in to arbitrate if the Baseline Maintainer to be removed or any other community members wish to dispute the action.
Anyone in the technical community that contributes code, documentation or other technical artifacts to the Baseline codebase or Standards Specification.
The TSC shall determine the number of maintainers required to merge a contribution into the master branch of the repo. This shall be done during the first TSC meeting. Changes to this number require a simple majority of TSC members.
This document was ratified by the PGB before the public launch of the Baseline Protocol. Changes to this document shall require a simple majority of the PGB.