Skip to content

[Docs] Define downstream override policy for org defaults #71

@ashleyshaw

Description

@ashleyshaw

title: "[Docs] Define downstream override policy for org defaults"
type: "documentation"
labels:

  • "area:docs"
  • "v0.2.0"
  • "governance"
    owner: "Docs"
    summary: "Create an explicit policy describing which org-level defaults are mandatory vs optionally overridden by repos."
    impact_risk: "Without this, downstream repos drift or block adoption."
    dependencies:
  • "Part-1 audit"
    telemetry: "Count downstream repos acknowledging policy via a checkbox in the PR template."

What documentation is needed?

Create a new policy document at docs/override-policy.md that explains how downstream repositories may adopt, inherit, or override organisation defaults.

The document should clearly define:

  • which org-level defaults are mandatory
  • which defaults may be overridden locally
  • how exceptions are requested
  • how the policy is versioned and promoted over time

Why is this documentation important?

Without an explicit downstream override policy, repositories either drift from organisation standards or delay adoption because the boundaries are unclear.

This documentation will reduce ambiguity, support more consistent governance, and make repo-level implementation decisions easier for maintainers.

Acceptance Criteria

  • docs/override-policy.md created
  • Includes the following sections:
    • Scope
    • Mandatory vs Optional
    • Requesting Exceptions
    • Versioning & Promotion
  • Links added in CONTRIBUTING.md
  • Links added in docs/index.md
  • Accessibility pass completed
  • Link-hygiene pass completed
  • Documentation is clear, accurate, and up-to-date
  • Follows WordPress documentation standards
  • Documentation is accessible and easy to find

Additional Context

  • Dependency: Part-1 audit
  • Owner: Docs
  • Telemetry: Track downstream repositories acknowledging the policy via a checkbox in the PR template
  • Risk if not delivered: downstream repos may drift from org defaults or block rollout/adoption

Definition of Ready (DoR)

  • Documentation need is clear and well-defined
  • Related docs/issues or files linked
  • Acceptance criteria listed
  • Milestone assigned (v0.2.0)

Definition of Done (DoD)

  • Policy document added and reviewed
  • CONTRIBUTING.md updated
  • docs/index.md updated
  • Accessibility and link-hygiene checks passed
  • PR uses correct branch prefix (docs/)

Metadata

Metadata

Assignees

No one assigned

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions