Skip to content
This repository has been archived by the owner on Dec 11, 2024. It is now read-only.

Latest commit

 

History

History
68 lines (40 loc) · 6.98 KB

GOVERNANCE.md

File metadata and controls

68 lines (40 loc) · 6.98 KB
Raw

Governance of the EEA Community Project: Technical Specification of TokenScript Working Group

Overall Governance

The Technical Specification of TokenScript Working Group is bound by the EEA Community Project’s governance document. The vote-eligible members of this working group will also act as the Technical Steering Committee of the project as prescribed by the EEA Community Project’s governance.

License and Patent Policies

All GitHub repos in the EEA Community Projects organization, including Working Group repositories, adhere to OASIS Open Projects patent policies. Contributions to this open-source repository shall be under Apache License, Version 2.0.

In order to ensure clean IPR, OASIS rules require an Entity CLA for persons or organizations contributing on behalf of a legal entity, and an Individual CLA for community contributions. Members must sign the CLA before their pull requests to the WG repository will be merged. Check here to see if an organization has signed the ECLA.

Code of Conduct

​The TokenScript Working Group (aka TSC) has adopted the OASIS Participants Code of Conduct as the foundation for its own Code of Conduct.

The Working Group

The Working Group (WG) shall be governed by its vote-eligible members, and all meetings shall be public, and publicly announced. A vote-eligible member is an entity whose representatives have collectively worked on at least 3 GitHub Issues in the preceding quarter, made or reviewed at least 3 GitHub Pull Requests in the previous quarter, and signed the WG Charter and its Governance. To get the group started, any participant is a vote-eligible member until 2024-06-01.

The initial WG chair and vice-chair will be appointed by the PGB for a term expiring January 31st of 2024 based on a WG recommendation. Subsequently, the WG will recommend to the PGB a Chair and a Vice-Chair for a term of one year via an election during the month of January utilizing an online ranked-choice voting system and administered by the OASIS EEA Community Project’s Administrator.

A quorum of two-thirds of the vote-eligible WG members is required to conduct any vote during any given meeting. Disputes are presented to the Project Governance Board (PGB) of the EEA Community Projects for arbitration. A minimum of two vote-eligible members may raise the Dispute to the PGB.

No legal entity (or set of entities controlled by a single party) shall hold more than one vote-eligible seat on the WG during any given period.

A WG member is eligible to lose their vote-eligible status upon their representatives missing three consecutive WG meetings. Removal is completed by a simple majority vote of the remaining vote-eligible WG members that are not being considered for removal. This decision can be raised as a dispute to the PGB.

The Chair and Vice-Chair are responsible for conducting the WG meetings, preparing an agenda for each WG meeting in advance of the meeting to be shared electronically no later than two working days before the meeting, and publishing meeting minutes after a WG meeting within three business days. Agenda items can be raised to the Chair or Vice-Chair by any vote-eligible member before or during a WG meeting.

Decision-Making Process

The group will seek to work by “lazy consensus” as described in the EEA Community Project Governance Documents. Where any vote-eligible member or any two attendees of a meeting who represent different organizations, request, this formal decision process will be applied instead. Any attendee at a meeting may use this process.

  • At a WG meeting, any contributor (“the Proposer”) may make a proposal and will present their proposal to those present at the meeting. The time allotted to this presentation will be determined by the Chair.
  • After the proposal is presented, there will be a period for feedback from the group, The time allotted to feedback will be determined by the Chair but is minimally the time between two WG meetings.
    • The Proposer is encouraged to accept as much of the feedback as is possible without interfering with the intent of their proposal.
    • The feedback may be accepted at the moment; in this case, the Proposer will alter their proposal in real-time and publish these alterations following the meeting.
  • After the feedback, the Proposer may ask the group:
    • To move forward with the proposal (including alterations, if applicable);
    • For additional time to alter and resubmit the proposal at a later date; or
    • To disregard the proposal, at which point the proposal will no longer be considered for passage.
  • If the Proposer asks the group to move forward with the proposal, the Chair will ask the group if there is a strong disagreement.
    • If there is no strong disagreement, the proposal will move forward.
      • Strong Disagreement is defined as at least a third of vote-eligible members objecting to a proposal
    • If there is a strong disagreement, the Proposer will be asked whether they are willing to form a task force with the members that have raised the strong disagreement to create a new proposal incorporating the objections.
      • If yes, it will be up to the Working Group to alter and resubmit the proposal.
      • If not, the participants of the WG meeting where the strong disagreement is raised and initially discussed will determine an adequate time frame of no less than the time between two meetings when a counter-proposal has to be submitted.
  • If the working group can find a compromise proposal, the compromise proposal is submitted as a new proposal. If the working group cannot reach a rough consensus (i.e. without “strong disagreement” as defined in this document), a compromise proposal, the relevant proposals are submitted as a Dispute to the PGB.

Contributors

Anyone in the technical community that contributes code, documentation, or other technical artifacts to the codebase of the WG.

Maintainers

Contributors who have the ability to commit code and contributions to a repo's main branch of the WG. A Contributor may become a Maintainer by simple majority approval of the vote-eligible WG members.

The number of maintainers required to merge a pull request to Main in the GitHub repo shall be two.

Ratification

This Governance document and the WG Charter shall be ratified by the PGB before the public launch of the WG. Changes to this document shall require a simple majority of the PGB.

Approved by EEA Community Projects PGB, 25 July 2023