Copy GitHub Repository PowerShell migration toolkit

Project governance and ownership

This document defines the lightweight governance and decision-ownership model for Copy GitHub Repository. The model is intentionally proportional to a focused open-source PowerShell project with one primary maintainer today. It establishes clear responsibility and proposal paths without inventing committees, independent approvers, or separation of duties that do not exist.

CODEOWNERS and the ownership descriptions below are review-routing and accountability mechanisms. They do not prove that a change received independent review, security approval, organizational approval, or multi-party release authorization.

Current maintainership model

The repository is currently maintained primarily by the infoconex GitHub account. Unless another maintainer is explicitly recorded in repository documentation or GitHub configuration, that primary maintainer holds final repository decision authority for product, architecture, security-policy, documentation, and release/publishing decisions.

This concentration of authority is a current project characteristic, not a claim of independent governance. Organizations adopting the project should apply their own internal review and approval controls where separation of duties is required.

Ownership by decision area

Decision area Current owner / authority Authoritative artifacts Typical decision examples
Product scope and public behavior Primary maintainer docs/product/product-contract.md, docs/product/product-model.md, public command contracts Supported modes/hosts, public parameters, safety invariants, intentional exclusions
Public API compatibility Primary maintainer Public command help/contracts, docs/user/support-policy.md, docs/release/versioning.md Breaking changes, deprecation, parameter/output compatibility
Architecture Primary maintainer docs/product/architecture.md, docs/product/adr/ Component boundaries, durable design choices, trust/state boundaries
Security policy and security architecture Primary maintainer SECURITY.md, docs/security/security-architecture.md, docs/security/repository-security-baseline.md Vulnerability handling, threat/control model, security-sensitive design
Documentation system Primary maintainer docs/engineering/documentation-strategy.md, _data/navigation.yml Authority ownership, information architecture, contributor/reviewer journeys
Engineering quality policy Primary maintainer docs/engineering/quality-strategy.md, docs/engineering/engineering-principles.md, docs/engineering/powershell-style-guide.md Test taxonomy, quality gates, analyzer policy, evidence semantics
Release readiness decision Primary maintainer under the release-readiness model Release-readiness authority introduced by #104 Go/no-go, blocker/accepted limitation decisions for an exact release candidate
Release/publishing execution Primary maintainer and configured GitHub release automation docs/release/versioning.md, docs/release/publishing.md, runbook introduced by #106 Tagging, GitHub Release, PowerShell Gallery publication, release evidence
Repository administration Repository owner/administrator GitHub repository settings plus docs/security/repository-security-baseline.md Rulesets, Actions permissions, security features, repository access

Ownership identifies who can make or accept a project decision. It does not mean every change must be manually approved by a separate person when the project does not have one.

Decision classes

Routine implementation decisions

Changes that stay within an existing product, architecture, security, support, and documentation contract may use the normal contributor workflow. The contributor should update the implementation, tests, and affected authoritative documentation together and satisfy the repository Definition of Done.

Routine implementation work does not require an ADR merely because code changed.

Compatibility-sensitive or product-contract changes

A proposal should be treated as compatibility-sensitive when it can materially change:

  • exported commands, parameters, defaults, outputs, or supported parameter sets;
  • Snapshot/FullHistory semantics;
  • destructive-operation safeguards or confirmation behavior;
  • supported GitHub hosts, PowerShell/platform baselines, or prerequisites;
  • documented support/deprecation behavior;
  • installer/update/uninstall behavior that users depend on; or
  • a previously documented product limitation or invariant.

The proposal should identify the affected product/support authority, compatibility impact, migration implications, test/evidence changes, and release-note/versioning consequence before implementation is considered complete. Durable design consequences may also require an ADR.

Architecture-significant decisions

Use an ADR when a decision is durable, cross-cutting, difficult to reverse, or materially changes an established architecture boundary. Examples include changing publication/state-preservation strategy, moving a trust boundary, adopting a new execution abstraction, or selecting a release-integrity mechanism with long-lived consequences.

ADRs record context, decision, and consequences. They are not approval forms and do not replace product, security, or release authorities.

Security-sensitive decisions

Security-sensitive proposals should identify the threat/trust boundary affected, failure mode, secret/credential implications, negative-path testing, and residual risk. Update the security architecture or repository security baseline when their facts change.

Vulnerabilities must follow the private reporting path in SECURITY.md; do not require public design discussion before a vulnerability can be reported safely.

Release/readiness exceptions

An incomplete expected control or evidence item may only be treated as an accepted release limitation through the explicit release-readiness process, with the exact release candidate, rationale, residual risk, decision authority, and follow-up recorded. Ordinary incomplete work should remain incomplete/blocked rather than being relabeled as an exception for convenience.

How contributors raise proposals

A contributor who identifies a design or compatibility-sensitive change should normally:

  1. describe the problem, user/maintainer outcome, and affected authority;
  2. identify compatibility, safety, security, support, and release implications;
  3. propose the smallest coherent solution and meaningful alternatives when they materially differ;
  4. reference or add an ADR when the decision meets the architecture-significance threshold;
  5. update tests and authoritative documentation with the implementation; and
  6. obtain maintainer review through the normal GitHub contribution workflow when contributing through a pull request.

For repository work performed directly by the primary maintainer, self-review and the same automated evidence requirements still apply. Direct maintenance does not create independent-review evidence and must not be described as such.

CODEOWNERS policy

.github/CODEOWNERS routes repository changes to the current primary maintainer. Because the project currently has one primary maintainer, the file uses a repository-wide owner rather than pretending that separate product, security, documentation, and release teams exist.

If future maintainers develop durable area ownership, narrow path-specific owners may be added when they reflect actual responsibility. Do not add nominal owners merely to satisfy an appearance of governance.

CODEOWNERS should not be treated as a branch-protection rule. Whether code-owner review is required is a live repository-setting question governed by docs/security/repository-security-baseline.md and #79.

Maintainer and ownership changes

When maintainership changes materially:

  1. update .github/CODEOWNERS to match actual review-routing responsibility;
  2. update this document’s current-maintainership statement and ownership table where needed;
  3. update repository/security/release administration access outside the repository as appropriate;
  4. review publishing credentials, environments, package ownership, and security-reporting access;
  5. record any durable architecture or release-authority change in its authoritative document; and
  6. avoid leaving former maintainers named as active owners solely for historical attribution.

Git history remains the source for historical authorship. Governance documents should describe current responsibility rather than maintain an author/change-history ledger.

Relationship to repository administration and organizational approval

Project governance and repository administration are related but distinct. This document describes project decision ownership. docs/security/repository-security-baseline.md owns the verified state and target controls for GitHub repository settings.

Likewise, project release approval is not the same as an adopting organization’s software approval. docs/security/software-assurance.md is the organizational review evidence entry point, but each adopting organization remains responsible for its own approval authority and risk acceptance.

Contributor and maintainer expectations

All owners and contributors remain subject to the same engineering evidence expectations:

  • identify and update the authoritative contract;
  • preserve safety/security invariants;
  • add meaningful tests for behavior changes;
  • satisfy PSScriptAnalyzer and the applicable Quality Gate/documentation validation;
  • use live E2E when external behavior must be established;
  • keep current, automatically tested, E2E-capable, live-validated, planned, and unsupported states distinct; and
  • do not describe self-review or automated testing as independent assessment.

See CONTRIBUTING.md and docs/engineering/maintainer-guide.md for the normal implementation and Definition-of-Done workflow.

Future evolution

The governance model should become more formal only when project reality requires it. Signals that may justify change include multiple active maintainers with stable area ownership, a material external contributor community, multiple independent release publishers, organizational sponsorship requirements, or a need for explicit quorum/separation-of-duties controls.

Any future model should replace this proportional single-maintainer description with the actual operating structure rather than layering ceremonial process on top of it.