Skip to content

Latest commit

 

History

History
66 lines (50 loc) · 3.68 KB

File metadata and controls

66 lines (50 loc) · 3.68 KB

Maintainers

The people with merge and release rights for firm. See GOVERNANCE.md for how maintainers are added and how decisions are made, and CONTRIBUTING.md for the workflow every change follows.

firm is today maintained by a single person in a BDFL-style model. This is an honest statement of where the project is — the design has always been to grow this group so firm does not depend on one person or one timezone.

Current maintainers

Name GitHub Areas
David Silva @davidslv Everything (lead maintainer) — see the area map below

Areas

Because firm is a small, coherent OS rather than a federation of independent packages, one maintainer currently owns every area. They are listed so a future maintainer group can divide them along real seams, and so a contributor knows which part of the system a change touches. The areas map to firm's own structure:

  • engineering-core tier — the universal role roster (Cluster A/B seams), the producer/orchestrator, the compound and blast-radius seams, the ecosystem + external-tools seams, and the driver commands (/grill-with-docs, /break-down, /epic-autopilot, …). Language-agnostic disciplines.
  • engineering-rails tier — onboarding (firm-onboard), the .firm/ sidecar and its pre-push gate, the Profile-driven Rails-way reviewers (Cluster A/C seams), the cops, and the generators.
  • The gates and CIscripts/check-roster.sh, scripts/check-why-sections.sh, scripts/run-self-tests.sh, scripts/run-evals.sh, scripts/check-strategy.sh, and the workflows under .github/. These are the machinery that makes firm hold its own standards; changing one changes what the project can prove about itself, so they get the most careful review.
  • Governance & release — the proposals in proposals/, this file, GOVERNANCE.md, CONTRIBUTING.md, the CHANGELOG, and cutting versioned plugin releases.

Ownership of specific paths is encoded, and enforced by GitHub, in .github/CODEOWNERS.

Responsibilities

A maintainer:

  • reviews and merges pull requests, keeping all four gates green (a red gate blocks merge; the fix is the cause, never a weaker gate);
  • accepts or declines proposals under the proposal-driven model, after the skeptic's adversarial read;
  • guards the roster — no change may leave a numbered seam double-owned or ownerless, and a new seam must meet the acceptance bar and fill an observed gap;
  • cuts releases (SemVer, CHANGELOG under Keep a Changelog); and
  • stewards the direction recorded in proposals/0006-firm-roadmap.md.

Becoming a maintainer

We are actively looking to grow the maintainer group so the project does not depend on one person or one timezone. If you have a track record of quality contributions and reviews, express interest in a discussion.

The path is described in full in GOVERNANCE.md § Path from contributor to maintainer: contributor (merged PRs) → reviewer (trusted to triage and approve) → maintainer (merge and release rights). What earns the invitation is not volume but judgement inside firm's discipline: changes that come with their proof, reviews that catch the real problem, and a feel for when a gap is worth a new seam and when it is not.

Emeritus maintainers

None yet.