-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Governance improvements to improve #24
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -6,57 +6,55 @@ As a community effort organized within the [Supply Chain Integrity WG](https://g | |||||
|
||||||
The SLSA Project described in this document is the "Working Group" for purposes of the [Community Specification License 1.0](./1._Community_Specification_License-v1.md). | ||||||
|
||||||
The SLSA Project is comprised of multiple "Work Streams." These Work Streams represent different tracks of specification work or tools implementation. Work Streams are not strictly tied to unique repositories in the slsa-framework GitHub organization. | ||||||
|
||||||
## 1. Roles. | ||||||
|
||||||
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 (a) made Contributions to the Project subject to the Community Specification License; (b) contributed code or documentation to Project assets other than specifications; and/or (c) otherwise contributed to or participated in the SLSA community, such as by attending meetings. | ||||||
**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. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the motivation for removing the 'Community Specification License'? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We thought the current governance, where the Participant requirement could be met with any of these three, was overly precise. (a) or (b) meet the requirements for Contributor, and of course a Contributor is a Participant as well. (c) is all that is necessary to be a Participant. |
||||||
|
||||||
**1.2. Contributors.** "Contributors" are those Participants that have (a) made Contributions to the Project subject to the Community Specification License; and/or (b) contributed code or documentation to Project assets other than specifications. | ||||||
**1.2. Contributors.** "Contributors" are those Participants that have (a) made Contributions to the Project and/or (b) contributed code or documentation to Project assets other than specifications. 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 the Project within the guidelines established by the Steering Committee. The "Specification Maintainers" are the default set of Maintainers for all Project repositories, recorded in slsa.git's [MAINTAINERS.md](https://github.com/slsa-framework/slsa/blob/main/MAINTAINERS.md). Other Project repositories may have a distinct set of Maintainers, defined in their respective MAINTAINERS.md files. | ||||||
**1.3. Maintainers.** "Maintainers" are responsible for reviewing and merging all proposed changes, and they guide the overall technical direction of a Work Stream within the guidelines established by the Steering Committee. Each Work Stream will record its Maintainers in a Maintainers.md file in the appropriate repositories + path locations. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the file is usually/always capitalized?
Suggested change
|
||||||
|
||||||
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 by consistently demonstrating poor judgment. A proposed removal also requires a majority approval. A Maintainer removed for inactivity should be restored following a sustained resumption of contributions and reviews (a month or more) demonstrating a renewed commitment to the project. | ||||||
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 by 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. | ||||||
|
||||||
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. | ||||||
|
||||||
<!-- Note: The above text was copied with modification from https://github.com/hyperledger/fabric/blob/main/docs/source/CONTRIBUTING.rst --> | ||||||
|
||||||
**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 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: | ||||||
**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 | ||||||
* coordinating activities between workstreams and Maintainers | ||||||
* collectively reviewing and revising the roadmap on a biannual basis | ||||||
* collectively reviewing and revising the Project mission, vision, strategy, and roadmap on a biannual basis | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: "biannual" can be interpreted as twice a year or every two years. Can we replace with less ambiguous language? |
||||||
* 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 | ||||||
* creating or restructuring workstreams | ||||||
* managing the lifecycle of existing and proposed Work Streams within the Project with the consensus input from the community of Participants | ||||||
* creating or restructuring Work Streams | ||||||
* 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 | ||||||
|
||||||
**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. | ||||||
**1.5. Steering Committee Member Terms.** Steering Committee Members have a one year term. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this set us up for all the seats expiring at one time and then there's no steering committee members? Perhaps the old language had that problem too? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We propose to not stagger elections like in the current governance since that adds more overhead. To your point, we should note that nominations & elections should occur before the term is up, maybe a month in advance to give enough time. |
||||||
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. 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. Steering Committee Members may be removed through an extraordinary vote by current Participants. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Steering Committee Members may be removed through an extraordinary vote by current Participants." I think that's a totally reasonable provision to have but note that this very much sounds like a setup for a "coup", something people took offense with when I suggested we might need to resort to in order to refresh the current defunct SC. :-) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was meant for forced removal if a member is inactive. To remove this concern of a "coup", we could define inactive as a fixed period of time (6 months maybe? Also need to account for members who may go on personal leaves. We could state that an SC member should appoint a temporary member if on leave for more than 6 months). If an SC member is inactive for more than that period, then they are presumed resigned and a vote is held. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we leave this in I think it needs a clear definition. Is it just a simple majority? How are the total number of participants measured? I think defining the rules under which this happens can address this concern, but it also seems hard to address all the details well. Might be easier to leave this out and let the TAC handle issues like this if necessary. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think defining clear criteria would go a long way but indeed leaving it to the TAC might be simpler. We cannot have an elected member designate a proxy that hasn't been elected. This would violate the basic principles that the SC is composed of elected members. We could allow for a member to designate another delegate as their proxy if deemed necessary but I'm not sure it is. I suggest to try to keep this as simple as possible. If we try to address every possible edge case we might encounter one day it's going to become very heavy. |
||||||
|
||||||
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. Decision Making. | ||||||
|
||||||
**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 be 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.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 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. | ||||||
**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. | ||||||
|
||||||
## 3. Ways of Working. | ||||||
|
||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/optional: can we use "workstream" instead of "work stream"
https://learn.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/w/workstream
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hah, Michael and I discussed this. It seems like "workstream" is more from the tech industry while "work stream" is grammatically correct. I don't have a strong opinion though :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aren't we part of the tech industry? :-) I prefer workstream, noting that this is how it appears in various places in our repo already: https://github.com/slsa-framework/slsa/tree/main?tab=readme-ov-file#active-workstreams