openshift-merge-bot · Oct 13, 2026 · Oct 12, 2026 · Oct 12, 2026 · Oct 12, 2026 · Oct 12, 2026
diff --git a/.gitignore b/.gitignore
@@ -0,0 +1,3 @@
+
+hack/owners/out/
+__pycache__/
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,7 +1,7 @@
 ---
 Status: Active
 Owner: HyperFleet Architecture Team
-Last Updated: 2026-03-25
+Last Updated: 2026-10-12
 ---
 
 # Contributing to HyperFleet Architecture
@@ -111,15 +111,13 @@ Use the scripts in `hack/` to run linting locally before pushing:
 5. **Open a PR** with a description that includes:
    - **What changed**: Which documents were added or updated
    - **Why**: The architectural context or decision being documented
-   - **Reviewers to loop in**: Tag any component owners affected by the change
+   - **Reviewers to loop in**: Prow requests reviewers from the area's `OWNERS` pool automatically; tag anyone else who should see it
 
 6. **Post the PR link** in [#hcm-hyperfleet-team](https://redhat.enterprise.slack.com/archives/hcm-hyperfleet-team) for team visibility
 
-7. **Wait 24 hours** for peer review (accounts for time zone differences between regions)
-   - For urgent changes, use judgement but ensure the rationale is well-documented in the PR
-   - For major architectural changes, strongly consider waiting for at least one Technical Leader review
+7. **Review**: reviewers aim for a substantive review within one business day. Push fixes as new commits once review has started
 
-8. **Merge** once approved with no objections
+8. **Merge**: an area approver's `/lgtm` or approving review merges the PR once CI is green. See [Repository Ownership](hyperfleet/docs/owners.md) for who approves which area. Want to become a reviewer or approver in an area? The criteria are in that document and apply to everyone
 
 ---
 

diff --git a/Makefile b/Makefile
@@ -5,3 +5,11 @@ help: ## Show available targets
 .PHONY: install-hooks
 install-hooks: ## Install pre-commit hooks
 	pre-commit install
+
+.PHONY: owners
+owners: ## Render OWNERS files and the ownership table from hyperfleet/docs/owners.yaml
+	python3 hack/owners/gen_owners.py render
+
+.PHONY: verify-owners
+verify-owners: ## Check hyperfleet/docs/owners.md is in sync with owners.yaml
+	python3 hack/owners/gen_owners.py check
diff --git a/README.md b/README.md
@@ -1,15 +1,15 @@
 ---
 Status: Active
 Owner: Architecture Team
-Last Updated: 2025-11-07
+Last Updated: 2026-10-13
 ---
 
 # HyperFleet Architecture Repository
 
 ## Table of Contents
 
 - [Overview](#overview)
-- [Repository Access & MVP Process](#repository-access--mvp-process)
+- [Repository Access and Review](#repository-access-and-review)
 - [Repository Structure](#repository-structure)
 - [Document Types](#document-types)
   - [1. Architecture Overview (`hyperfleet/README.md`)](#1-architecture-overview-hyperfleetreadmemd)
@@ -53,33 +53,21 @@ This repository serves as the **single source of truth** for all architectural d
 
 ---
 
-## Repository Access & MVP Process
-
-**Current Phase**: MVP Development
+## Repository Access and Review
 
 **Access & Permissions**:
 
-- All developers in the HyperFleet team are granted **write access** to this repository
-- To support quick iteration during MVP, developers have **approve and merge access** if there are no objections from peers
-- This temporary process enables rapid documentation of decisions and scope changes
+- All developers in the HyperFleet team have **write access** to this repository
+- A merge needs an approval from an **area approver**, as declared in the `OWNERS` files and enforced by Prow. The process is in [Review and Merge Process](#review-and-merge-process) below
+- Reviewer and approver status is earned against the criteria in [Repository Ownership](hyperfleet/docs/owners.md), and nothing else
 
 **Repository Usage**:
 
 - This repository primarily records:
   - Architectural decisions and their rationale
-  - Trade-offs we're accepting during MVP
-  - Changes to MVP scope and priorities
-  - Technical debt we're consciously incurring
-
-**Post-MVP**:
-
-- Once MVP is complete, we will establish official processes for:
-  - Repository access management
-  - PR review requirements
-  - Approval workflows
-  - Documentation governance
-
-**During MVP, prioritize speed over process while maintaining clear documentation of decisions.**
+  - Trade-offs we are accepting
+  - Changes to scope and priorities
+  - Technical debt we are consciously incurring
 
 ---
 
@@ -90,7 +78,7 @@ architecture/
 ├── README.md                      # This file - repository guide
 ├── CONTRIBUTING.md                # How to contribute to this repository
 ├── CLAUDE.md                      # Claude Code guidelines for AI-assisted workflows
-├── OWNERS                         # Repository ownership
+├── OWNERS                         # Repository ownership (generated from hyperfleet/docs/owners.yaml)
 ├── hack/                          # Utility scripts
 └── hyperfleet/                    # HyperFleet-specific architecture
     ├── README.md                  # HyperFleet system overview and architecture summary
@@ -305,25 +293,15 @@ Example of paying down technical debt:
 
 ### Review and Merge Process
 
-**MVP Process (Current)**:
-
-All HyperFleet team developers have approve and merge access. **Goal**: Move fast while keeping the team informed.
+A merge needs one approval from an approver for every path the PR touches, as declared in the `OWNERS` files and enforced by Prow. Reviewer and approver status in an area is earned against the criteria in [Repository Ownership](hyperfleet/docs/owners.md), which also holds the current area table and the path to becoming a reviewer or an approver.
 
 **How to submit and merge changes:**
 
 1. **Create a PR** with your documentation updates
 2. **Add a clear description** of what changed and why
 3. **Post the PR link** in Slack: #hcm-hyperfleet-team for team visibility
-4. **Wait 24 hours** for peer review and objections (accounts for time zone differences between regions)
-   - For urgent changes, use judgment but ensure the change is well-documented with clear rationale
-   - For major architectural changes, strongly consider waiting for at least one or two Technical Leader reviews
-5. **Merge when ready**: Once you have approval from peers and no objections after the 24-hour window, you may merge
-
-**Post-MVP Process** (to be established):
-
-- Formal approval requirements based on change type
-- Required reviewers for different document categories
-- Defined merge timelines and escalation paths
+4. Prow requests reviewers from the area's pool. Reviewers aim for a substantive review within one business day
+5. An area approver's `/lgtm` or approving review merges the PR once CI is green
 
 ---