Skip to content

Add configurable team review requirements to GitHub repository policy #2107

Description

@codeforester

Goal

Add a repository-owned GitHub review-governance contract so Base can configure a team-appropriate minimum pull-request review policy instead of defaulting every repository to zero required approvals.

Background

Base configures a protected default branch and required automation checks, but the current Base default-branch ruleset requires pull requests while allowing zero approving reviews and not requiring code-owner review. That is reasonable for a solo public project, but it is not a sufficient default governance model for a startup with multiple web, mobile, backend, infrastructure, and shared-library repositories.

Without a supported contract, adopters must apply separate GitHub settings manually in every repository, which creates policy drift and weakens confidence that all repositories have equivalent review protection.

Scope

  • Define the canonical repository-owned configuration location and schema for review governance.
  • Support an explicit minimum approving-review count and code-owner-review requirement.
  • Preserve the current behavior when no team policy is declared, so existing solo repositories are not changed unexpectedly.
  • Include current and proposed review settings in basectl repo configure --dry-run output.
  • Apply the requested settings through the existing GitHub ruleset or branch-protection path.
  • Read back the effective GitHub settings after apply and fail closed when the requested protection cannot be verified.
  • Prevent ordinary reconfiguration from silently weakening an existing stronger review policy.
  • Document how a multi-repo team should select and apply one consistent review policy across repositories.

Acceptance Criteria

  • A documented, versioned configuration contract exists for minimum approving reviews and code-owner review.
  • The no-configuration compatibility behavior is explicit and tested.
  • Dry-run output shows affected repositories and current versus proposed review settings.
  • Apply mode configures the requested review policy and reads back the effective GitHub state.
  • Reconfiguration does not lower an existing stronger policy without an explicit weakening action.
  • Tests cover absent configuration, one approving review, multiple approving reviews, code-owner review, dry-run, apply, readback failure, and unsupported GitHub capability.
  • The command reference, GitHub workflow documentation, stability documentation, and changelog describe the contract.
  • A multi-repository fixture verifies that the same declared policy is planned consistently for every eligible GitHub repository.

Validation

  • Run focused repository-configuration and GitHub-ruleset tests.
  • Run the full Base validation gate: env -u BASE_HOME BASE_BASH_LIBS_DIR=/Users/rameshhp/work/base-bash-libs/lib/bash BASE_CLI_SOURCE_DIR=/Users/rameshhp/work/base-cli/lib/python BASE_CACHE_DIR=/private/tmp/base-review-cache ./bin/base-test.
  • Exercise basectl repo configure --dry-run against a representative web, mobile, backend, and infrastructure repository fixture.
  • Verify the applied policy through a separate read-only GitHub API readback.
  • Run git diff --check.

Non-Goals

  • Do not manage organization membership, teams, CODEOWNERS file contents, or reviewer assignment.
  • Do not require a review policy for every repository by default.
  • Do not replace GitHub organization rulesets or native branch protection.
  • Do not weaken existing protections to make a repository conform silently.
  • Do not change the project-specific source, build, test, or deployment contracts.

Project Fields

  • Status: Backlog
  • Priority: P1
  • Area: CI
  • Initiative: Adoption Polish
  • Size: M

Agent Assignment

Assigned to: codeforester

Human review is required for the default-preservation and no-weakening policy decisions before implementation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or product improvement

Type

No type

Projects

  • Status
    Backlog

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions