> Governance Purpose

The libmemalloc project uses this document to define how project decisions are made, reviewed, approved, recorded, and updated.

Governance exists to keep the project:

technically consistent;
maintainable over time;
transparent to contributors;
predictable for maintainers;
clear about who can approve changes;
clear about who owns project areas;
sustainable as the project grows.

This document is based on a lightweight open-source governance model and uses the SustainOSS Governance Readiness Checklist as a reference for reviewing whether project governance is clear, healthy, and sustainable.

It also cites the Governance.md Guide as a general reference for documenting open-source project governance.

This document does not create a legal entity, foundation, board, or formal membership structure. It defines repository-level governance for project maintenance, contributions, reviews, releases, ownership, and decision-making.

> Project Values

The libmemalloc governance model values:

technical accuracy;
respectful disagreement;
clear ownership;
transparent decisions;
maintainable and portable C code;
secure and responsible engineering;
reproducible releases;
proper attribution and licensing;
sustainable maintainer workload;
practical process over bureaucracy.

The project should avoid hidden decisions, unclear ownership, unreviewed critical changes, and silent bypasses of normal project review.

> Scope

This governance document applies to official project spaces and activities, including:

GitHub issues;
pull requests;
discussions;
code reviews;
commits and commit messages;
documentation;
release notes;
project-maintained communication channels;
public communication when representing the project.

It applies to:

maintainers;
reviewers;
contributors;
release owners;
security contacts;
documentation owners;
tooling owners;
community stewards;
anyone proposing a project-level change.

This document complements, but does not replace:

Document	Purpose
README.md	Explains what the project is and how to use it.
CONTRIBUTING.md	Explains how to contribute.
CODE_OF_CONDUCT.md	Defines expected behavior and enforcement.
SECURITY.md	Defines vulnerability reporting and handling.
CODEOWNERS	Defines path-based review ownership.

> Governance Readiness Model

The project uses the SustainOSS Governance Readiness framework as a recurring review model.

The framework is interpreted through three dimensions:

Dimension	Project interpretation
Day-to-day	How the project makes decisions, reviews pull requests, approves releases, assigns owners, and handles normal maintenance.
Barriers and Needs	What can block healthy governance, such as unclear ownership, maintainer overload, missing reviewers, unresolved conflicts, or unclear release authority.
Interventions	What the project does when normal governance is not working, such as escalation, release freeze, owner rotation, or policy update.

A governance readiness review should happen:

before a major release;
when a maintainer is added or removed;
when a maintainer becomes inactive;
after a serious release failure;
when contributors report that decision-making is unclear;
when review or release work is repeatedly blocked.

> Governance Principles

The project follows these governance principles:

Principle	Meaning
Transparency	Important decisions should be visible in issues, pull requests, discussions, or decision records.
Traceability	Significant technical and release decisions should have a durable record.
Maintainer accountability	Maintainers may make final decisions, but those decisions should be explainable and reviewable.
Least necessary process	Use the smallest process that still protects users, contributors, maintainers, quality, and security.
Clear ownership	Critical project areas should have explicit owners.
Security awareness	Security-relevant changes require explicit review.
Sustainable maintenance	Governance should reduce bottlenecks and avoid relying on unclear or unavailable ownership.

> Roles

A person may hold more than one role. In a small project, one maintainer may temporarily hold several roles, but ownership gaps should remain visible.

Role	Responsibility
Maintainer	Owns final technical direction, roadmap, merges, releases, and governance.
Reviewer	Reviews code, documentation, tests, portability, maintainability, and design.
Security Contact	Coordinates vulnerability reports, private fixes, advisories, and security releases.
Release Owner	Runs release checks, verifies release readiness, publishes release notes, and publishes artifacts.
Documentation Owner	Reviews user-facing and developer-facing documentation.
Tooling Owner	Maintains CI, linters, analyzers, scripts, and repository automation.
Community Steward	Watches for contributor friction, unclear processes, onboarding gaps, and governance barriers.

> Current Role Assignments

Role	Primary owner	Backup owner
Maintainer	Rafael V. Volkmer	TBD
Reviewer	Rafael V. Volkmer	TBD
Security Contact	Rafael V. Volkmer	TBD
Release Owner	Rafael V. Volkmer	TBD
Documentation Owner	Rafael V. Volkmer	TBD
Tooling Owner	Rafael V. Volkmer	TBD
Community Steward	Rafael V. Volkmer	TBD

> Maintainer Responsibilities

Maintainers are responsible for protecting the long-term health of the project.

Maintainers should:

define project direction and scope;
review or delegate review of pull requests;
enforce required CI and review rules;
approve releases;
approve governance changes;
approve changes to security, release, contribution, and ownership policies;
keep unresolved project risks visible;
avoid silent bypasses of review or testing;
document significant decisions;
keep the project sustainable for contributors and maintainers.

Maintainers may reject changes that are technically correct but harmful to the project's maintainability, portability, security, compatibility, or long-term direction.

> Reviewer Responsibilities

Reviewers are responsible for checking whether a change is:

technically correct;
maintainable;
portable;
consistent with project architecture;
consistent with the coding style;
covered by appropriate tests;
documented when behavior changes;
compatible with public API and ABI expectations;
free from obvious security, memory, concurrency, or portability regressions.

A reviewer may request additional review from a project owner when the change affects:

public API;
public ABI;
memory allocator behavior;
platform support;
dependency policy;
security behavior;
build or CI infrastructure;
release process;
governance policy.

> Decision Process

The default decision model is:

technical discussion
    -> rough consensus
        -> maintainer decision when needed
            -> scientific record for each engineering decision

Consensus is preferred, but unanimous agreement is not required.

A maintainer may make the final decision when:

consensus cannot be reached;
the decision is blocking progress;
the issue affects project direction;
the issue affects compatibility, maintainability, release timing, or security;
the issue requires a clear owner.

Supporting discussion and evidence may be recorded in:

an issue;
a pull request comment;
a discussion;
a decision record;
a release evidence record;
a security advisory.

Record the rationale and reviewed revision in the issue or pull request. Link supporting discussions and restricted evidence without publishing sensitive content.

> Decision Records

Use the issue or pull request to record the problem, chosen approach, alternatives, compatibility effects and verification evidence. Follow the engineering review procedure. Keep stable requirements and executable contracts in the SDDs and reference pages they govern. The reviewer assesses the evidence and the decision authority records acceptance for the reviewed revision.

> Pull Request Governance

A pull request should be classified before review.

Change type	Required review
Documentation-only	One reviewer or maintainer
Internal implementation	One reviewer or maintainer
Public API or ABI	Maintainer approval
Memory allocator internals	Maintainer approval and targeted tests
Build system or CI	Maintainer or Tooling Owner approval
Dependency update	Maintainer or Security Contact review
Security-relevant change	Security Contact review
Release process change	Release Owner and maintainer approval
Governance change	Maintainer approval and open discussion when appropriate

A pull request should not be merged when:

required CI gates fail;
required owners have not reviewed the change;
required tests are missing without an approved rationale;
a security issue is introduced without mitigation;
the change creates unclear ownership;
the change conflicts with an accepted project decision.

> CODEOWNERS Policy

CODEOWNERS defines which maintainers or teams must review changes in specific repository paths.

The project ownership map is:

*                         @RafaelVVolkmer

/.github/                 @RafaelVVolkmer
/docs/                    @RafaelVVolkmer
/LICENSES/                @RafaelVVolkmer
/readme/                  @RafaelVVolkmer

/.gitkeep                 @RafaelVVolkmer
/CHANGELOG.md             @RafaelVVolkmer
/CODE_OF_CONDUCT.md       @RafaelVVolkmer
/GOVERNANCE.md            @RafaelVVolkmer
/LICENSE                  @RafaelVVolkmer
/README.md                @RafaelVVolkmer
/SECURITY.md              @RafaelVVolkmer

Path ownership rules:

changes to owned paths require review from the listed owner;
ownership changes require maintainer approval;
unavailable owners may be bypassed only by a maintainer;
bypassed ownership should be mentioned in the pull request;
CODEOWNERS must stay consistent with this document.

> Security Governance

Security vulnerabilities are handled according to SECURITY.md.

Security-relevant changes include:

memory management;
parsing untrusted input;
dependency updates with known vulnerabilities;
build or release pipeline changes;
secret handling;
sandboxing or isolation;
vulnerability fixes;
changes to hardening flags;
changes to artifact signing.

Security issues may be handled privately when coordinated disclosure is needed.

Public discussion should avoid exposing sensitive vulnerability details before users have had a reasonable opportunity to update.

Security releases may use a shorter public discussion period when needed, but they still require maintainer approval.

> Release Process

A release may be published only after release readiness review.

Minimum release requirements:

Area	Requirement
CI	Required workflows pass
Tests	Required test suites pass
Security	No known unresolved critical issue
Documentation	Changelog and release notes updated
Ownership	Required owners reviewed release-impacting changes
Tag	Release tag created by a maintainer
Artifacts	Release artifacts published when applicable

The Release Owner records the release decision and its evidence under the release procedure.

> Governance Readiness Review

A governance readiness review checks whether the project can still operate clearly and sustainably.

Review output should be recorded as an issue or discussion and linked from any governance update pull request.

> Barriers and Needs

The project should actively watch for governance barriers.

Barrier	Risk	Intervention
Single maintainer bottleneck	Reviews and releases stall	Add reviewers, delegate ownership, reduce required synchronous approval
Unclear ownership	Critical changes get merged without the right review	Update CODEOWNERS and role table
Missing security contact	Vulnerabilities are handled inconsistently	Assign a contact or define maintainer fallback
Release authority unclear	Releases become inconsistent or risky	Define Release Owner and release evidence record
Too much process	Contributors stop participating	Simplify gates
Too little process	Decisions become unclear	Add minimal review and ownership rules
Dormant maintainers	Decisions become blocked	Apply inactivity policy and rotate owners
Unresolved conflict	Technical direction stalls	Escalate to maintainer decision with documented rationale

> Interventions

Governance interventions are allowed when normal day-to-day governance is not working.

Possible interventions:

Intervention	When to use
Release freeze	Serious security or release integrity problem
Maintainer decision	Consensus cannot be reached and progress is blocked
Temporary owner assignment	A critical owner is unavailable
Policy update	Existing governance does not cover a recurring problem
Security embargo	Coordinated disclosure is needed
Retrospective	A release, vulnerability, incident, or conflict exposed governance gaps

Each intervention should be documented with rationale and outcome.

> Inactivity Policy

A maintainer or owner may be considered inactive when they have not responded to project-critical review or governance requests for a reasonable period.

Suggested process:

Contact the person publicly in the relevant issue or pull request.
Contact privately if appropriate and available.
Wait a reasonable response period.
Reassign urgent responsibilities temporarily.
Update roles if inactivity continues.
Record the change in GOVERNANCE.md or a governance issue.

This policy should be used respectfully and only to keep the project healthy.

> Conflict Resolution

Technical disagreement is normal.

Resolution path:

discussion
    -> concrete proposal
        -> review of trade-offs
            -> maintainer decision if needed
                -> documented outcome

Conflicts should be resolved based on:

user impact;
security;
maintainability;
compatibility;
portability;
project scope;
available maintainer capacity.

Personal attacks, harassment, or bad-faith behavior should be handled under the project's Code of Conduct.

> Governance Changes

Changes to this document require maintainer approval.

A governance change should explain:

what problem it solves;
which roles or workflows are affected;
whether it adds or removes required review;
whether it changes release authority;
whether it changes ownership rules.

For major governance changes, leave the pull request open long enough for maintainers and regular contributors to review.

> Review and Updates

This governance document should be reviewed as the project evolves.

Review is expected when:

the maintainer set changes;
a new release process is adopted;
a security incident occurs;
governance barriers are reported;
contributors cannot determine who owns a decision.

Substantial changes should be reviewed like any other repository governance change.

> Attribution

This governance document is informed by the SustainOSS Governance Readiness Checklist, the Governance.md Guide, and general open-source governance practices.

The structure and visual style follow the repository documentation style used by the project's Code of Conduct template.

Maintainers own approval of specification issues and the reserved spec and SDD area labels. The versioned roster and catalog require review alongside changes to maintainer responsibility. PRs close bounded issues after their acceptance criteria pass; partial implementation references the open issue.