Document guiding principles for Baseline

These are a codification of things we've discussed, but not written down

Signed-off-by: Ben Cotton <[email protected]>

Author: funnelfiasco

Diff for: docs/index.md

@@ -17,3 +17,15 @@ Only the version labeled as "current" should be used for new compliance efforts.
 * [In-development version](versions/devel)
 
 Versions are managed according to the [Baseline maintenance process](maintenance).
+
+## Guiding principles
+
+The goal of the OSPS Baseline is to be useful to maintainers as a mechanism for evaluating and communicating a project's security posture.
+In addition, OSPS Baseline must help consumers of open source software more easily evaluate their compliance requirements.
+Therefore, OSPS Baseline work is:
+
+* **Focused:** Controls only contain *MUST* entries, not *SHOULD*.
+* **Realistic:** Controls are practical for project maintainers to implement at the appropriate level for their project.
+* **Actionable:** Controls provide specific recommendations.
+* **Meaningful:** Controls have an impact on a project's security posture.
+Ineffective controls add to maintainer burden.

Diff for: governance/GOVERNANCE.md

@@ -14,13 +14,7 @@ Refer to the [OpenSSF Community Calendar](https://openssf.org/getinvolved/) for
 
 - **SIG Lead:** Eddie Knight (@eddie-knight)
 
-## Guiding Governance Principles
-
-Any issues or proposals brought to the project's maintainers shall be framed in the OSPS Baseline guiding principles. Proposals not adhering to said principles shall not be considered for consensus.
-
-### Favor Simplicity
-
-The goal of OSPS Baseline is to create a minimal and efficient standard that can be quickly ingested by any project. Simple is better.
+## Release Governance Principles
 
 ### Ensure Stability