This document provides the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group and must adhere to the requirements in this document.
Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group.
1.1. Maintainer. "Maintainers" are responsible for organizing activities around developing, maintaining, and updating the specification(s) and other assets developed by the Project. Maintainers are also responsible for determining consensus and coordinating appeals. Examples of the responsibility of a Maintainer (directly or by delegation) include:
A Contributor may become a Maintainer with the Approval of the Steering Committee. A Maintainer may be removed with the Approval of the Steering Committee. A Steering Committee Member may not deliberate or vote on their own appointment or removal as a Maintainer.
1.2. Editor. “Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. Each Working Group will designate an Editor for that Working Group. A Working Group may select a new Editor upon Approval of the Working Group Participants.
1.3. Participants. “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License.
1.4. Steering Committee Members. The "Steering Committee" is the body that is responsible for overseeing the overall activities of the Project. The Steering Committee consists of up to 7 Participants (each, a "Steering Committee Member") and will initially consist of the Steering Committee Members so designated as of the date of initial adoption of this S2C2F Governance Policy. The Steering Committee will meet regularly as needed, but no less then once per quarter. Examples of the responsibilities of the Steering Committee include:
1.5. Steering Committee Member Terms. During the initial year, the Steering Committee Members will agree on grouping themselves into two groups, one to serve an initial two-year term, and the other for an initial one-year term. Thereafter, the Steering Committee Members will serve two year terms.
At the expiration of a Steering Committee Member term, any Participant may submit a nomination to fill the seat. An individual may be nominated for and serve any number of successive terms.
If a Steering Committee Member resigns or ceases to participate for a significant period of time prior to the end of their term, the remaining Steering Committee Members may choose to remove that Steering Committee Member. If so, the remaining Steering Committee Members will determine whether and when to fill the role.
The Steering Committee may add additional Steering Committee Members as it deems necessary.
After discussion with the nominees for a vacant seat, the Steering Committee will select the new Steering Committee Members from the group of nominees taking into account such things as the nominees’ willingness to take on the role, skills, and level of participation as well as the need to maintain a balanced perspective on the Steering Committee (e.g., no more than two people from the same group of related companies should be on the Steering Committee). A Steering Committee Member nominee may not deliberate or vote on their own appointment.
2.1. Consensus-Based Decision Making. Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The Maintainer will document evidence of consensus in accordance with these requirements.
2.2. Appeal Process. Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time.
2.3. Steering Committee Appeal Process. Decisions that have been appealed to the Maintainers may in extraordinary cases be appealed to the Steering Committee for reconsideration. An appeal to the Steering Committee must specify in detail (1) the specific decision that is being appealed; (2) the basis for contending that the decision was not aligned with the purposes, goals or scope of the Project; and (3) an explanation of why the decision is extraordinary enough to warrant an appeal to the Steering Committee. The appeal will be considered by the Steering Committee in good faith, who will respond in writing within a reasonable time. The Steering Committee may decline to consider appeals that are unexceptional, unfounded or excessive, including because of their repetitive character.
2.4. Amendments to Governance Documents. The documents in this Governance repository may be amended by a two-thirds vote of the entire Steering Committee and are subject to approval by The Linux Foundation. However, entries may be added to the Notices file in this Governance repository as described therein.
Inspired by ANSI’s Essential Requirements for Due Process, Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus.
3.1. Openness. Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required.
3.2. Lack of Dominance. The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.
3.3. Balance. The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance.
3.4. Coordination and Harmonization. Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.
3.5. Consideration of Views and Objections. Prompt consideration shall be given to the written views and objections of all Participants.
3.6. Written procedures. This governance document and other materials documenting the Community Specification development process shall be available to any interested person.
4.1. Draft. During the specification development process, Participants may submit issues and pull requests to a S2C2F specification repository. Pull requests will be merged upon Approval of the applicable Maintainers. Each updated version of the specification following the merging of a pull request will be considered a "Draft Specification".
4.2. Project Approval. Upon the determination by the applicable workstream that it has achieved the objectives for its specification as described in the Scope, the applicable Maintainers will Approve that Draft Specification as a candidate for "Approved Specification" status. The following process will then be used:
4.3. Publication and Submission. Upon the designation of a Draft Specification as an Approved Specification, the Maintainers will publish the Approved Specification in a manner agreed upon by the Project Participants (i.e., Project Participant only location, publicly available location, Project maintained website, Project member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available.
4.4. Submissions to Standards Bodies. No Draft Specification or Approved Specification may be submitted to another standards development organization without Project Approval. Upon reaching Approval, the Maintainers will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. The Project Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions.
Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group.