Trevon 72647bbaf7

chore: stabilize CI, faiss, metadata, docker, and simeon (#25 )

- CI warm: ccache dep, continue-on-error, 60min timeout, YAMS_DISABLE_FAISS
- Faiss: YAMS_HAS_FAISS guard, Apple Clang disable, OpenMP detection
- Metadata: retry constraint failures, deduplicate batch UPSERT entries
- Docker: wget for Zig, gfortran, YAMS_DISABLE_FAISS=1
- CI config: free-disk-space v1.3.1, libomp-18-dev, experimental trigger
- Weekly benchmarks: faiss disable, ccache, diagnostics capture
- Simeon: bump to 7763a97, EntropyRouter, concept_count
- CorpusStats: extraction readiness fields
- Remove committed artifacts (.wrangler, .artifacts, dispatcher_external)
- Fix .vscode/settings.json hardcoded path

Signed-off-by: trvon <git@trevon.dev>

2026-05-07 21:07:59 -04:00

2.1 KiB

Raw Permalink Blame History

Project Governance

This document defines how decisions are made for the YAMS project and who is responsible for them.

Scope and Principles

The goal is to keep decision-making lightweight, transparent, and oriented around stability and user value.
Decisions favor lazy consensus when risk is low and repeatability is high.

Roles

Maintainer: Responsible for overall direction, release approvals, resolving conflicts, and final decisions.
Committer: May merge changes in scoped areas, upholds standards and CI gates.
Reviewer: Reviews and recommends changes.
Contributor: Contributes via pull requests.
Security Team: Handles private disclosures and coordinates fixes (see SECURITY.md).
Release Manager: Leads a release cycle (may rotate).

At present, the sole Maintainer and Owner is: @trvon.

Decision Process

Lazy consensus: If no substantive objections are raised within 72 hours of a proposal/PR, it is considered approved, provided CI and required reviews pass.
RFCs: Required for material/architectural changes, public interfaces, storage formats, and CI gates. RFCs are opened under docs/rfcs and discussed via PR.
Voting: When needed, Maintainer(s) vote. With a single Maintainer, decisions default to @trvon.
Conflict resolution: The Maintainer adjudicates. If a Technical Steering Committee (TSC) is created in the future, deadlocks escalate to the TSC.

Ownership and Reviews

Code ownership is defined by CODEOWNERS. Changes require review from owners of affected areas.
All PRs must pass CI, follow style rules, and include tests/documentation as applicable.
DCO sign-off is required for all commits.

Release Process

Versioning follows SemVer. User-visible or interface changes require CHANGELOG updates and, when applicable, stability notes.
Release cadence: monthly minor releases, ad-hoc patch releases as needed.
A Release Manager (default: @trvon) coordinates tagging, artifacts, and notes.

Security

Private disclosure only. See SECURITY.md for reporting and handling SLAs.

Amendments

Amendments to this governance require Maintainer approval via PR.

2.1 KiB Raw Permalink Blame History