WIP: Add a maintenance process

.github/workflows/test-build.yml

@@ -17,7 +17,7 @@ jobs:
         with:
             persist-credentials: false
       - name: Build content from yaml
-        run:  cd cmd && go run main.go compile --output ../docs/index.md
+        run:  cd cmd && go run main.go compile --output ../docs/versions/devel.md
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1.0.13
         with:

.github/workflows/web-publish.yml

@@ -31,7 +31,7 @@ jobs:
       - name: Setup Pages
         uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5.0.0
       - name: Build content from yaml
-        run:  cd cmd && go run main.go compile --output ../docs/index.md
+        run:  cd cmd && go run main.go compile --output ../docs/versions/devel.md
       - name: Build with Jekyll
         uses: actions/jekyll-build-pages@44a6e6beabd48582f863aeeb6cb2151cc1716697 # v1.0.13
         with:

docs/index.md

@@ -0,0 +1,17 @@
+# Open Source Security Baseline
+
+The Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to it's maturity level.
+It is maintained by the [OpenSSF Security Baseline SIG](https://github.com/ossf/security-baseline/blob/main/governance/MAINTAINERS.md) according to the [project governance documentation](https://github.com/ossf/security-baseline/blob/main/governance/GOVERNANCE.md).
+
+## Versions
+
+Previous versions are presented for historical reference.
+Downstream consumers of the OSPS Baseline should specify their compliance against a specific version.
+Only the version labeled as "current" should be used for new compliance efforts.
+
+* [In-development version](docs/development)
+* Current version: [v1.0]() released YYYY-MM-DD
+* Previous versions:
+    * [v0.1] released YYYY-MM-DD
+
+Versions are managed according to the [Baseline maintenance process](maintenance).

docs/maintenance.md

@@ -0,0 +1,20 @@
+# OSPS Baseline Maintenance Process
+
+* Normal text fixes to the criteria will be accepted via pull request and reviewed by the baseline project maintainers.
+Allowed changes are corrections to spelling/typos, grammar corrections, or enhancements to the supplementary text supporting the criteria including - Objective, Implementation, Control Mappings, and Scorecard/Insights values.
+At least two project maintainers must review and approve these changes.
+* Substantive changes to Criteria, including changes to text that alters the originally stated meaning, new Criteria proposals, or removal of Criteria will be documented in GitHub PR(s) and reviewed regularly by the Baseline project maintainers.
+These changes may reflect changes to global cybersecurity regulations and frameworks or changes in norms around application/project security practices.
+Any such substantive changes must be approved by a majority of the project's maintainers.
+* As appropriate, but at least annually, the Baseline project maintainers will publish a new version of the Baseline.
+Previous versions of the Baseline will remain avialable, but are not maintained.
+* Any changes to the Baseline will be reflected within the Compliance Matrix, with new requirements flagged where the Baseline Criteria are appropriate.
+* Downstream stakeholders will be notified via the project's mailing list on the changes and updates.
+
+## Identifiers
+
+* Identifiers for retired criteria will not be used.
+* Substantial changes to the meaning of a criterion will be treated as a new criterion, resulting in a new identifier.
+Minor changes, including a change in level, between Baseline versions will not result in a new identifier.
+* The numeric portion of identifiers are assigned sequentially per category.
+They do not carry additional meaning.