Governance
How contributions are submitted, how practices advance through their lifecycle, how releases are approved, and how the community participates.
Principles
Five principles guide every governance decision in the 4GS framework.
Openness
All changes are proposed and discussed publicly via pull requests. No opaque committee sessions where consequential changes happen without record.
Versioning
Practices and taxonomy are versioned. Approved content is never silently modified. Every change is a new version with a clear audit trail.
Reproducibility
A numbered release pins a specific set of standard practices, ensuring compliance assessments are comparable across time.
Separability
Taxonomy relationships are stored separately from practice definitions. Practices can be reclassified without changing their criteria.
Evidence orientation
Practice criteria must describe observable, implementable characteristics — not intentions, aspirations, or stated values. Criteria are structured by evidence tier so they are actionable by role.
Roles
Maintainers
- Facilitate contribution discussion
- Advance contributions through lifecycle stages
- Approve and publish releases
- Maintain documentation quality
Maintainers are appointed by atypical. Current maintainer: Ian Howard.
Contributors
- Any person may submit a contribution or comment on an open contribution
- Contributions are governed by CONTRIBUTING.md and the project licences
- No institutional membership required
- Discussion history is permanently recorded and publicly accessible
Contribution lifecycle
Every contribution progresses through defined stages with documented criteria for advancement.
Submission
A contribution is submitted as a pull request containing a completed FGC-xxxxx.md
file. Contributions may create new practices, modify criteria, change taxonomy, or propose new domains.
Proposed
The contribution enters active discussion. Any community member may comment. Maintainers may request clarification or rewrites.
Candidate
A maintainer advances the contribution when it is complete, well-specified, no blocking objections remain, and at least one maintainer has reviewed and approved.
Standard
The Candidate stage has been open for at least 14 days with no blocking objections. A maintainer merges the pull request and the practice is included in the next release.
Release process
Candidate release
Format: FGR-<semver>C-FGC-<seed>. May include Candidate practices.
Used for evaluation purposes but not for formal compliance claims.
Standard release
Format: FGR-<semver>. References only Standard practices and a Standard
taxonomy version. Requires maintainer approval and a 7-day public review period.
Semantic versioning rules
| Change type | Version bump | Example |
|---|---|---|
| New practices added | Minor | 1.0.0 → 1.1.0 |
| Existing practice criteria revised | Minor | 1.1.0 → 1.2.0 |
| Practice retired | Major | 1.x.x → 2.0.0 |
| Taxonomy reorganisation (non-breaking) | Minor | 1.0.0 → 1.1.0 |
Amendments
This governance document is itself subject to the contribution process. Proposed amendments are submitted as pull requests and require maintainer approval.