Skip to content

Latest commit

 

History

History
70 lines (60 loc) · 3.57 KB

README.md

File metadata and controls

70 lines (60 loc) · 3.57 KB
Raw

SLSA Proposal Documents

This repository contains "proposal documents" that supplement larger changes to SLSA.

Proposals represent a snapshot in time. They are intended to explain a proposed change and its rationale. They are not intended to serve as long-term documentation once the change is implemented. Long-term documentation should instead live in the main SLSA repo.

Proposal index

Number Title Status
0001 Creation of proposal process IMPLEMENTED
0002 Project roadmap, May 2022 ACCEPTED
0003 SLSA v1.0 proposal IMPLEMENTED
0004 Policy Architecture for Npm Package Provenance DRAFT
0005 Conformance Program proposal ABANDONED
0006 Restructure the Versioning System for SLSA ACCEPTED
0007 Steering Commitee application, terms, and role DRAFT
0008 Common CI/CD buildType DRAFT

How to create a proposal document

See CONTRIBUTING for a description of the process. Proposal documents are not needed for all changes.

  1. Find or create a relevant GitHub Issue in the main SLSA repo to discuss this idea.
  2. Fork this repository and create a PR containing the new document:
    • Create ####/README.md using 0001/README.md as a template:
      • #### is the proposal number; use the next available integer.
      • Update metadata at the top:
        • Page title: Proposal number and title
        • Proposer: Full name with link to GitHub username, plus email
        • GitHub Issue: Link to GitHub Issue(s) that this proposal addresses
        • Status: DRAFT
        • Implementation: Point to any implementations that are ready, or (none) if none are available yet.
      • Fill out the rest of the document as appropriate. We recommend following the same document structure unless you have a reason to deviate. Delete or comment-out unused sections.
    • Update the proposal index with the new proposal.
    • Send a pull request to submit the proposal. You may gather and incorporate initial feedback in the PR, but prefer to submit it once activity subsides rather than having a long-lived PR.
  3. As needed, iterate on the proposal with more PRs.
  4. Once agreement is reached on the Issue, send a PR to update the status.

Meaning of status codes

  • DRAFT: Still being refined and/or undergoing review. All proposals start in this state.
  • ACCEPTED: Accepted as the plan of record but not yet implemented.
  • IMPLEMENTED: Implemented and final. The doc should be updated to point to the implementation PRs in the Implementation metadata field.
  • REJECTED: Will not be implemented. The doc should explain the decision.
  • ABANDONED: Proposer has stopped work on the proposal, without an explicit approval or rejection decision. The doc should explain why it was abandoned.