Governance improvements to improve

[michaelwinser]

Updated terms and roles to more accurately reflect the current working group norms and future efforts.
Updated Steering Committee Member terms and elections and responsibilities.
Changed the Steering Committee size to exactly 5 and updated rules for governance update to depend on that size

Still missing some text to encourage Maintainers of Work Streams to make decisions more quickly in a smaller setting. This probably belongs in the Work Stream lifecycle rather than governance.

[TomHennen]

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

[haydentherapper]

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 :)

[lehors]

Hah, Michael and I discussed this. It seems like "workstream" is more from the tech industry while "work stream" is grammatically correct.

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

[TomHennen]

I think the file is usually/always capitalized?

Suggested change

	**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.
	**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.

[TomHennen]

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?

[haydentherapper]

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.

[TomHennen]

What's the motivation for removing the 'Community Specification License'?

[haydentherapper]

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.

[haydentherapper]

Note for follow up:

@michaelwinser and I have reviewed https://github.com/slsa-framework/slsa-proposals/tree/main/0007 and found no major differences, but are planning to do another pass.

One difference I noted was the explicit SC requirement that an SC member be well-versed with SLSA. In our proposed changes, any Participant is able to nominate themselves. @michaelwinser, should we include more specifics on the nomination process to align with 0007, namely a requirement that you include "Evidence of performing some of the role's duties over the recent past" (from 0007)?

[lehors]

"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. :-)

[haydentherapper]

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.

[TomHennen]

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.

[lehors]

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.

[haydentherapper]

I've annotated 0007 below to note differences or similarities. We are mostly aligned. Proposed changes to incorporate from 0007 are noted immediately below.

1. Add more specifics to nomination process for SC, including a requirement for "evidence" of performing the role's duties already, requiring being well-versed in SLSA, and affiliation.
2. Explicitly state that all nominations and decisions should be publicly recorded (e.g. on GitHub issues & Slack) for transparency.
3. Note that SC members are responsible for administration of the GitHub repositories. I think we should make this explicit, otherwise it'll be up in the air who is deciding branch protection rules, configuring secrets, etc. With this distinction, Maintainers only need "write" or "maintain" permissions to merge code, and SC members can have "admin" permissions. This avoids having many admins in the same repo for slsa-framework/slsa.
4. Add a section about the layout of the GitHub organization and what governance roles map to which GitHub roles, and the usage of GitHub teams. I'd propose we just do this here rather than in a separate. Thoughts on how this should look (this is all from Sigstore):

• A team is defined for the sc, e.g. slsa-sc-members. This team is given "admin" permissions over the org (which includes all repos).
• Each workstream defines a team for maintainers, e.g slsa-build-track-spec-maintainers, slsa-build-tooling-maintainers. Each team is given a "maintain" permission for the repository.
• For a repository with multiple workstreams, a CODEOWNER file should include a line for each folder or file mapped to a workstream team. The repository settings should mandate CODEOWNER approval before merge.
• A workstream may define a team for code reviewers, e.g. slsa-build-tooling-reviewers. This team must contain only Contributors who have demonstrated knowledge of the codebase. This team is given "write" permission for a repository.
• Branch protection rules per repository should be added for the "main" branch to prevent direct pushes. Additionally, the rules must mandate that only teams with "maintain" permissions can merge changes. This means that those with "write" can only review and approve changes, but those with "maintain" can merge as well.
• Note for all teams, those added to the team should be a "member", not an "owner". "owners" can change who is in a team
• Team memberships should be updated as maintainers and SC members resign or are added.
• No one should be a member of the org that is not a Contributor, Maintainer or SC member.
• (not to be added to the governance) A one-time pass is necessary over the whole org to update this and purge outdated members. I can help with a SLSA admin implementing the changes.

5. Explicitly state that SC members should publish meeting notes for SC meetings, and decide if we want an explicit requirement for how often SC members meet.

@michaelwinser, do you agree to the above? I can either propose these changes as comments or you can incorporate them.

---

Replace “terms” / “seats” with a lightweight re-application process

• SC no longer has 7 fixed seats, but instead has a minimum of 3 and
  ideally about 5.
• Same guidelines for Maintainers, without the hard minimum.

SC is down to 5. We've proposed no guidelines for maintainer seats. I wouldn't recommend this, as this amount of churn for maintainers would make it hard to maintain velocity.

• Individuals self-nominate to become a Maintainer or SC Member by
  submitting a brief (1-2 paragraph) application consisting of:
• Evidence of performing some of the role's duties over the recent
  past.
  • For SC Member applications, this should include evidence of being
    well-versed in SLSA.
• Statement of intent to continue performing duties over the next
  year.
• Affiliation / employer.

We have specified self-nomination. We have not noted evidence as a requirement.

• SC Members decide if the individual meets the desirable properties
  (described in the next section) and respond with an official determination
  and rationale. Decisions are effective immediately.
• SC Members should attempt to reach consensus. At a minimum:
  * SC Member applications require explicit approval from at least
  50% of the existing SC Members, excluding the candidate.
  * Maintainer applications require explicit approval from at least 2
  existing SC members (possibly including the candidate).

We have made it a vote by Participants, not by SC members. I think this is a good process, as it gives the community a vote for its leadership.

• Existing SC Members and Maintainers annually re-apply for the position,
  using the same lightweight process above.
  * Purpose: to provide a natural way to remove members who are no longer
  actively performing their duties.
  * Exception: If there are only three SC Members, they remain indefinitely
  until another person applies.

This process has been noted for SC members.

• Applications and decisions are recorded publicly, such as through
  GitHub Issues, for transparency and to provide examples for future
  applicants.

We have not explicitly stated this, we should.

• OpenSSF may, at their discretion and with due process and input from
  the SCI WG:
  * appoint new SC Members to get up to the minimum three; or
  * remove an SC Member for cause.

I don't think this is necessary to state explicitly, the OSSF TAC always has oversight over its projects.

• Appeals may be made to the SC directly, and if needed, escalated to the
  OpenSSF.

Noted as a responsibility of the SC.

Clarify project roles

• Participant: no change, but clarify language (it’s a bit confusing as
  written)

We've made a change to note a Participant is just someone who adds to discussions. The current language is confusing because it includes language from being a Contributor as well.

• Contributor: no change, but clarify language
  * A Maintainer may delegate some duties to a Contributor, such as
  permission to triage issues or approve PRs

We've added an example to Contributor to note it's someone who is authoring code or specifications. A Contributor does not directly have permissions over repositories, so there is no need to delegate from a Maintainer to Contributor.

• Maintainer: an individual who is trusted and expected to regularly
  perform day-to-day duties for a specific sub-project within the
  slsa-framework organization.
  * A Core Maintainer is a maintainer of the slsa-framework/slsa repo.
  This repository is special because it contains the core specification
  and the overall project issue tracker.
  * A Subproject Maintainer is a maintainer of a different repo within
  the slsa-framework organization.

We've proposed a similar definition but without core vs subproject. We've added "workstreams" to denote between different specs and tooling efforts, and each has its own maintainer. I don't think we need a special Core Maintainer role, as that only sounds administrative and that is a responsibility of the SC.

• SC Member: a senior leader of the SLSA project who is trusted and
  expected to ensure the health of the project overall, drive the overall
  project strategy, and serve as an escalation point in the event of a
  disagreement.
  * These duties are much less frequent than those of a Maintainer.
  * We expect an SC Member to be well versed in the project. This often
  means that SC Members are also Core Maintainers, or maintainers of a
  subproject, but this is not required.

Agreed on all points, this is noted in the proposal.

• Some Core Maintainers might not be SC Members.

We don't have a Core Maintainer role, but I've noted SC members should be GitHub admins.

• The SC, as a group, are responsible for maintaining the relationship
  with the SCI WG, which includes:
  * Facilitating input from SCI WG into SLSA during significant
  developments, including: adding tracks and establishing roadmaps.
  * Periodically reporting progress and developments to SCI WG.
  * Sharing relevant information from the SCI WG with the SLSA community.
  * As community leaders, SC Members are also responsible for maintaining
  the slsa-framework/governance repository.
  * SC Members share updates on their activities in the Community Meeting.

We've noted this as a requirement for an SC member.

Clarify GitHub roles and how they maps to project roles

Currently it’s unclear how the GitHub org and repo membership and roles
correspond to the roles defined in the governance document. The proposal here
attempts to clarify.

• GitHub Organization:
  * Member:
  * Used for Maintainers to allow them to be added to a team.
  * Used as needed for Participants and Contributors who would like to
  set up [custom notification routing] and issue assignment across
  multiple repos.
  * Does not grant any special repository permissions, i.e. Base
  permissions = “No permission”
  * Owner:
  * Used for SC Members, OpenSSF administrators, and (as needed)
  Maintainers
  * Teams: (all with public visibility)
  * [SLSA Steering Committee][SLSA Steering Committee Team]
  * Core Maintainers
  * <subproject> Maintainers
  * Other teams as needed
  * GitHub Repositories
  * Read: may be granted to Participants and Contributors as needed,
  usually to allow the person to set up custom notification routing
  and/or be assigned issues
  * Triage/Write: may be granted to Contributors who have been
  delegated this responsibility by a Maintainer
  * Write permission grants ability to approve PRs
  * Admin: granted to every Maintainer via the <subproject>
  Maintainers team
  * These permissions should be reviewed and cleaned up regularly (e.g.
  annually)

This whole section was not explicitly added to the proposal. I've noted our need to add it.

Once this proposal is accepted, the following changes will be made to the
GitHub organisation:

• Set up Maintainers teams and add Maintainers as members if needed
• Change the org member base permissions to “No permissions” (from “Admin”)
  and check that everyone still has necessary access
• Purge unnecessary permissions in the org and in each repo
  * Purging of unnecessary permissions should happen on a regular cadence. At minimum
  after each SC Member nomination cycle.

Added as a follow up.

Other clarifications

• Add SC Member duty: "selecting Maintainers and Steering Committee Members"

Our proposal differs, SC members are added by vote, maintainers approve new maintainers.

• Add SC Member duty: "representing SLSA in the OpenSSF SCI WG"

Added already.

• Remove requirement for SC members to meet "no less then [sic] once per
  quarter".

We can remove this.

• Add requirement to publish minutes for every SC meeting.

We can add.

• State explicitly that SLSA lives within and takes broad direction from the
  OpenSSF SCI WG.

This is already in governance.

• Document a tie-breaking method for SC votes, should they be deadlocked, i.e
  when the SC has an even number of members.

This was not added, and I think we should be OK based on the new rules that SC members are voted in immediately and there is an odd number always.

[TomHennen]

I've annotated 0007 below to note differences or similarities. We are mostly aligned. Proposed changes to incorporate from 0007 are noted immediately below.

...

Do you need any feedback on this from anyone in particular right now?

[haydentherapper]

I've annotated 0007 below to note differences or similarities. We are mostly aligned. Proposed changes to incorporate from 0007 are noted immediately below.
...

Do you need any feedback on this from anyone in particular right now?

No, just wanted to note my thoughts publicly. You can wait until we’ve integrated my suggested changes.

[trishankatdatadog]

No, just wanted to note my thoughts publicly. You can wait until we’ve integrated my suggested changes.

Please tag me (and others) specifically when ready to review. Thanks!

[MarkLodato]

LGTM, pending the open discussions, particularly around referring to the TAC for extraordinary removals.

[MarkLodato]

nit: "biannual" can be interpreted as twice a year or every two years. Can we replace with less ambiguous language?