This document provides the governance policy for specifications and other documents developed using the Community Specification process, as well as related source code, in repositories in the slsa-framework GitHub organization (the "Project"). The Project and its participants will adhere to the requirements in this document. This document is derived from the Community Specifications Governance Policy 1.0.
As a community effort organized within the Supply Chain Integrity WG of the OpenSSF Technical Advisory Council ("TAC"), the SLSA Project operates in accordance with the Open Source Security Foundation Charter. The SLSA Governance Policy below describes the manner in which the SLSA Project will operate in the development of its specifications.
The SLSA Project described in this document is the "Working Group" for purposes of the Community Specification License 1.0.
The SLSA Project is comprised of multiple "Workstreams." These Workstreams represent different tracks of specification work or tools implementation. Workstreams are not strictly tied to unique repositories in the slsa-framework GitHub organization.
The Project includes the following roles. Additional roles may be adopted and documented by the Steering Committee.
1.1. Participants. "Participants" are those that have contributed to or participated in the SLSA community, such as by attending meetings, engaging in conversations on Slack, or commenting on documents.
1.2. Contributors. "Contributors" are those Participants that have (a) made Contributions to the Project (E.g. specification changes) and/or (b) contributed code or documentation to Project assets. E.g. creating a PR, reviewing a PR, and editing a specification in a document.
1.3. Maintainers. "Maintainers" are responsible for reviewing and merging all proposed changes, and they guide the overall technical direction of a Workstream within the guidelines established by the Steering Committee. Each Workstream will record its Maintainers in a MAINTAINERS.md file in the appropriate repositories + path locations.
Maintainers may be added through majority approval of existing Maintainers, based on the following criteria:
- Demonstrated track record of PR reviews (both quality and quantity of reviews)
- Demonstrated thought leadership in the project
- Demonstrated shepherding of project work and contributors
Maintainers may be removed by explicit resignation, for prolonged inactivity (e.g. 3 or more months with no review comments), for some infraction of the code of conduct, or for consistently demonstrating poor judgment. A proposed removal also requires a majority approval. A Maintainer removed for inactivity may be restored following a sustained resumption of contributions and reviews (a month or more) demonstrating a renewed commitment to the project.
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 5 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 SLSA 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:
- enabling the smooth running of the Project
- active participation within the community
- collectively reviewing and revising the Project mission, vision, strategy, and roadmap every 6 months or more frequently if needed, and publishing Steering Committee meetings notes
- publishing quarterly updates suitable for OpenSSF TAC and other working groups' consumption
- participating in strategic planning, such as coordinating face-to-face meetings or suggesting and approving changes to the governance model
- managing the lifecycle of existing and proposed Workstreams within the Project with the consensus input from the community of Participants
- creating or restructuring Workstreams
- responding to specific issues or concerns above and beyond the domain of the various workstreams
- making decisions when community consensus cannot be reached, pursuant to the appeal process documented below
- holding Maintainers accountable to the standards of what makes SLSA an effective Project and representative of a diverse community of Participants and Contributors. In the extreme event that a majority of existing Maintainers are unavailable to approve additions or removals for an extended period of time, the Steering Committee may add or remove Maintainers to bring the Project back to a functioning state
- administration of slsa-framework GitHub organization, including maintaining team memberships for Maintainers, setting security defaults such as branch protection for the organization, managing secrets, etc.
The Steering Committee will be comprised of Members from a diverse set of affiliations. An affiliation must not be represented more than once on the Steering Committee. If affiliation changes during a Steering Committee Member's term which would cause overrepresentation, a Steering Committee Member from that affiliation must resign.
1.5. Steering Committee Member Terms. Steering Committee Members have a one year term. One month before the expiration of a Steering Committee Member term, any Participant may submit a nomination to fill the seat. A Participant must include the following documentation in their nomination:
- Statement of intent to perform the duties of a Steering Committee Member during the next term
- Evidence of active participation in the community and being well-versed in SLSA
- Affiliation / employer
The nomination period should last two weeks. After the nomination period, the voting period should begin and last one week. Participants are eligible to vote for Steering Committee members. The Steering Committee Members will then tally the votes and announce the new Steering Committee Members.
An individual may be nominated for and serve any number of successive terms. However, Steering Committee Members are encouraged to allow other longstanding Participants to contribute as Steering Committee Members. Steering Committee Members are elected by current Participants. Steering Committee Members must resign if they become inactive, by not performing the duties as stated in 1.4. Steering Committee Members may be removed in extraordinary circumstances with an escalation to the OpenSSF TAC.
When a Steering Committee Member resigns or is removed, an election must be held to replace the Member, following the procedure for nominations and elections as discussed above.
Nominations and decisions must be publicly recorded, e.g. on GitHub issues or Slack, for transparency.
2.1. Consensus-Based Decision Making. The Project makes decisions through a consensus process ("Approval" or "Approved"). While the agreement of all applicable Participants is preferred, it is not required for consensus. Rather, the Maintainers or Steering Committee (as applicable) will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the applicable Project Participants and nature of support and objections. The Maintainers or Steering Committee (as applicable) will document evidence of consensus in accordance with these requirements.
2.2. Appeal Process. Decisions may be appealed via a pull request or an issue, and that appeal will be considered by the applicable Maintainers 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 four of the five Steering Committee Members 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 Projects 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 Project'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 Project 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 SLSA 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:
- The Maintainers will distribute that version of the Draft Specification to the Project's primary mailing list.
- The Maintainers will state in the distribution that the Draft Specification is a candidate for "Approved Specification" status, and will announce the start of a two-week review period (the "Review Period").
- During the Review Period, Participants may raise any issues regarding the Draft Specification. Such issues will be considered and resolved in the ordinary course.
- The Maintainers may, in their discretion, extend the Review Period for a longer period of time, but will not shorten it to be less than the initial two-week period.
- After the completion of the Review Period and upon the Approval of the Project (which may include the absence of, or resolution in the ordinary course of, any issues raised during the Review Period), the Draft Specification will be progressed to be an "Approved Specification".
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 Project activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Steering Committee meeting minutes will be published in summary form, as appropriate (e.g., sensitive matters may not be made public). Notwithstanding the foregoing, if the Project 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 Project.