Governance

Governance

Source of truth: GOVERNANCE.md, kept in the repository and copied here.

Governance

This document describes how the hMailServer fork at Progressiverobot/hmailserver is run: who decides what, how decisions are made, and what each role is expected to do. It describes the project as it actually is today, not as an aspirational structure.

The short version

This is a single-maintainer project stewarded by Progressive Robot Ltd. Christopher Holloway is the maintainer and currently holds every role below. Decisions are made by the maintainer, in the open, on the issue tracker.

That is a real constraint rather than an embarrassment, and it is stated plainly here for the same reason it is stated in Security Policy: people relying on a mail server are entitled to know how much of it rests on one person. The Continuity section below says what is and is not currently true about that.

Roles and responsibilities

Maintainer

Currently: Christopher Holloway (@chrisholloway5).

The maintainer is accountable for the project. In practice this means:

• Accepting changes. Reviewing and merging pull requests, and deciding what does and does not belong in the fork.
• Releasing. Producing releases according to Release Process, including running the full regression suite against the exact binary being shipped, and signing every release asset.
• Security response. Receiving private vulnerability reports, triaging them, and meeting the timetable published in Security Policy.
• Direction. Keeping Roadmap.md current, and deciding what the project will deliberately not do.
• Infrastructure. Holding and protecting the credentials listed under Critical assets.

The maintainer holds admin rights on the GitHub repository and the signing and release path.

Contributor

Anyone who opens a pull request. Contributors are expected to follow Contributing: keep changes focused, keep the regression suite green, add or update regression tests for behaviour changes, use parameterised SQL exclusively, and accept that contributions are licensed under the AGPLv3.

Contributors do not need any prior status. There is no CLA to sign.

Reporter

Anyone who files an issue or a security report. Reporters are expected to follow SUPPORT.md for defects, and Security Policy for anything security-relevant — in particular, not to open a public issue for a security problem.

Reporters are credited for security findings unless they ask not to be.

How decisions are made

Ordinary changes. The maintainer decides, and the reasoning is recorded where the decision happens — in the pull request, in the issue, or in the release notes. The project's habit is to write down why rather than just what; the release notes are the clearest example of this and are the intended place to look for the reasoning behind a behavioural change.

Disagreements. Raise them on the issue in question. The maintainer will respond with a reason, not just a verdict. A closed issue is not a closed conversation — reopening it with new information (especially a reproduction) is welcome, and has changed outcomes before.

Scope. Whether something belongs in the fork is decided against one question: does it serve people running this as a mail server in production? Compatibility with existing hMailServer deployments is a standing constraint, not a preference — an upgrade must preserve configuration and mail.

Security. Security decisions are the maintainer's alone, and are made under the disclosure timetable in Security Policy rather than by consensus.

Becoming a maintainer

There is no committee and no fixed number of contributions. The path is demonstrated, sustained judgement: a track record of changes that are correct, tested, and considerate of existing deployments, plus a willingness to take on the release and security duties above rather than only the coding.

If you want to help at that level, say so on an issue. The project would benefit from it — see Continuity.

Critical assets

These are the things whose loss would stop the project, and they are listed so that a successor knows what to look for:

Asset	What it is for
GitHub repository admin	Accepting changes, managing issues, publishing releases
Release signing path	Sigstore cosign keyless signing of release assets (no long-lived private key is held)
Code-signing material	Signing the Windows installer
Build environment recipe	Visual Studio 2026 / v145 plus the external libraries under hMailServerLibs
Test environment recipe	The database, ClamAV, SpamAssassin and INI configuration the full regression suite needs

Everything needed to build, test, release and verify the product is committed to this repository and documented — in README.md, Architecture, Release Process, the scripts under build/, and the workflows under .github/workflows/. Deliberately, nothing about producing a release depends on knowledge that exists only in the maintainer's head.

Note that release signing is keyless (Sigstore, via GitHub OIDC). There is no private signing key to inherit or to lose, which removes the single most common continuity failure for a small project.

Continuity

Current status: the knowledge bus factor is 1; access continuity is arranged. One person does the work today — but the credentials and legal rights needed to continue the project do not die with them. The maintainer keeps the critical credentials in a managed arrangement that a trusted person can reach if the maintainer is confirmed unavailable, together with the legal authority to use them, so the project could create and close issues, accept changes and publish a release within days rather than being locked out.

What remains true is that no second person currently knows the codebase the way the maintainer does — that is the bus-factor gap recorded honestly above and in the badge entry. The mitigations in place for it:

• Every build, test and release step is scripted and committed, so the work is reproducible by someone else without tacit knowledge.
• Release signing requires no inherited private key.
• The repository is public, and the licence (AGPLv3) permits anyone to continue the work — a fork is always available as a last resort, which is precisely how this project itself came to exist.

Closing the gap properly requires a second person with repository admin and release rights. The project is open to that; see Becoming a maintainer.

Which document governs what

This project keeps its rules in the repository, next to the code they govern, and copies each into this wiki. If you are not sure which one applies, this is the map.

flowchart TB
    Q["What are you trying to do?"]
    Q --> C1["Send a change"]
    Q --> C2["Report a defect"]
    Q --> C3["Report a vulnerability"]
    Q --> C4["Ask a question"]
    Q --> C5["Cut a release"]
    Q --> C6["Understand a decision"]
    Q --> C7["Change how the project is run"]

    C1 --> D1["CONTRIBUTING.md<br/>focused changes, tests,<br/>parameterised SQL, DCO sign-off"]
    C2 --> D2["SUPPORT.md, then Issues"]
    C3 --> D3["SECURITY.md<br/>a private advisory - never<br/>a public issue"]
    C4 --> D4["Discussions, or the<br/>hMailServer forum for general<br/>hMailServer questions"]
    C5 --> D5["RELEASE.md<br/>thirteen ordered steps<br/>and their gates"]
    C6 --> D6["The pull request, the issue,<br/>or the release notes -<br/>whichever is where the<br/>decision happened"]
    C7 --> D7["GOVERNANCE.md<br/>by pull request, like<br/>everything else"]

    D1 --> M["The maintainer decides,<br/>with a reason recorded<br/>where the decision happens"]
    D3 --> M
    D5 --> M
    D7 --> M

Loading

The rule behind that last box is the one worth internalising: the reasoning is written down where the decision happens. The release notes are the clearest example and are the intended place to look for why a behaviour changed.

Who holds what

Right or duty	Held by	Delegated?	If it were lost
Merging pull requests	Maintainer	No — master requires a pull request, but a self-merge with no reviewer is allowed	Nothing lands
Publishing a release	Maintainer	No	No new binaries; the source stays public and buildable by the scripts in build/
Security triage and the disclosure timetable	Maintainer alone, explicitly not by consensus	No	The 5 / 10 / 90-day targets in Security Policy would slip; the policy says a slip is announced before it happens
Roadmap and scope	Maintainer	No	Roadmap.md goes stale; build/check-roadmap.ps1 would still catch it disagreeing with itself
Repository admin	Maintainer	Access continuity arranged — the credentials sit in a managed arrangement a trusted person can reach, with the legal authority to use them	Issues could not be closed nor releases published until that arrangement is invoked
The release signing key	Nobody. Signing is keyless Sigstore through GitHub OIDC	n/a	Nothing — there is no key to inherit or lose, which removes the most common continuity failure for a small project

A note on the Code-signing material row in Critical assets: since 11 September 2026 the installer is Authenticode-signed with Azure Artifact Signing (the service formerly called Trusted Signing), from 6.3.1. There is still no certificate file to inherit or lose: Microsoft holds the key and issues short-lived certificates against an organisation identity validation of Progressive Robot Ltd, and CI signs through a GitHub OIDC-authenticated app registration. What a successor would need is the Azure subscription, the signing account and the identity validation, which lapses and must be renewed - RELEASE.md records all three.

What "bus factor 1" concretely means here

The claim is deliberately split in two, because the two halves have very different mitigations:

	Status	Mitigation in place	What would actually close it
Access continuity	Arranged	Credentials in a managed arrangement plus the legal authority to use them; keyless signing means no private key to inherit	Already addressed
Knowledge continuity	Bus factor 1	Every build, test and release step is scripted and committed — build/, .github/workflows/, Release Process, Regression Test Environment — so the work is reproducible without tacit knowledge. The repository is public and AGPLv3 permits anyone to continue it; a fork is always available, which is precisely how this project came to exist	A second person with repository admin and release rights. See Becoming a maintainer

Nothing about producing a release depends on knowledge that exists only in the maintainer's head. That is a design goal of the scripts, not a happy accident: it is why build/preflight-tests.ps1 names the missing step rather than assuming you know it, and why RELEASE.md records why each of its thirteen steps exists.

Changing this document

Propose changes the same way as any other change: open a pull request. The maintainer decides, and, as everywhere else in this project, will give a reason.