Skip to content

Standards Governance

These standards are a contract. This page defines who owns them, how they change, how the language is read, and how exceptions are handled - so that a change to a standard is as deliberate as a change to production code.

Ownership

Role Responsibility
Standards owners (the maintainers of this repository until the organization names them in .github/CODEOWNERS on the tenacious-standards branch) Approve every change; keep the standards consistent with each other and with the template
Page owner (one team per page) Keeps that page accurate; reviews it at least every 6 months (proposed - pending owner confirmation in #16)
Every engineer Proposes changes when a standard no longer fits how we work

Reading the standards

Requirement words follow RFC 2119:

  • MUST / MUST NOT - mandatory. Not following it needs an approved exception.
  • SHOULD / SHOULD NOT - the default. Deviating is allowed with a written reason (in the PR or README).
  • MAY - optional.

A rule the template can check is checked by the template (in CI, and early by local hooks); a rule it cannot check says so.

Changing a standard

  1. Open a PR against the tenacious-standards branch following the Pull Request Standard. Explain the problem the change solves.
  2. A standards owner must approve. A change that alters what engineers must do (a new MUST, or a removed one) needs two approvals (proposed - pending owner confirmation in #16) and is announced to engineering. This is a deliberate exception to the automated-review merge gate in the Pull Request Standard: code merges on automated review, the rules everyone follows do not. On GitHub Free the approvals are checked by whoever merges.
  3. If the change affects what the template enforces, link the matching template PR - the standard and the template change together.
  4. Record the change in the Changelog below.

Exceptions

When a project cannot meet a MUST (for example, a client mandates a different branching model):

  • Record the exception in the project's README: the rule, the reason, the approver (Tech Lead), and a review date.
  • Client-imposed rules apply on client engagements; these standards are the floor where the client has none.
  • An exception that keeps recurring is a signal to change the standard.

Changelog

Date Change
2026-10 Branch Strategy: hotfixes follow dev → staging → production; going straight to staging or production is a rare exception the Tech Lead and Project Owner must acknowledge. CI/CD: secret scan covers full history. Automation Testing: engineers own unit and integration tests. Defined the conventions record, release tracker, project channel, README sections, and roles; proposed a 90-day key rotation (pending #16). Documented that GitHub Free cannot block merges and local checks are a safety net.
2026-10 New standards: Documentation & ADRs, Observability, Data Privacy, Engineering Metrics, Standards Governance.
2026-10 Repository Management: the template ships no license (added per engagement). Code Review: CODEOWNERS is an optional template; code-owner review is advice by default, and a project may require it.
2026-10 Branch Strategy: exception hotfixes are cut from the deployed production commit; promotion PRs are exempt from "up to date".
2026-10 Proposed values (key rotation, page review, MUST approvals, release watch, make doctor cadence) marked as pending owner confirmation. Per-PR merge-gate measures added.

A standard nobody can follow is a bug

Report it - do not quietly ignore it.