Add GOVERNANCE.md, and wire its stable-surface rules into the PR template

[graphicsMan]

Adds GOVERNANCE.md — roles, how changes get merged, what counts as the stable
surface, neutrality, and how people join and leave — and extends the pull
request template so the classification those rules turn on is collected from the
author rather than reconstructed at review.

Written now rather than later because the project is mid-transfer to a neutral
organisation, and the case for a neutral organisation over a foundation rests on
having a written governance model plus at least two maintainers who do not share
an employer. That argument is easier to evaluate against a document that exists.

Deliberately short — under a thousand words. A project this size does not need a
foundation charter, and an over-specified process nobody follows is worse than a
brief one describing what actually happens.

Worth review attention

Two routes to merging. A pull request merges either on approval from a
committer other than its author, or — if its author is a committer — after 24
hours open with no objection. The second route exists because review capacity is
uneven: for long stretches one person writes most of the changes, and demanding
a second signature on each converts a right to review into an obligation to
review. An unresolved objection blocks either route; an author cannot resolve an
objection to their own change, but the active maintainers can by consensus.

The stable surface, and what additions cost. Public API and ABI, default
behaviour, and documented concurrency guarantees are stable; undocumented
scheduling and internal threading are not, and change routinely. A compatible
addition follows the ordinary rules — this library grows by adding utilities and
gating that would be pure friction. But an addition that could reasonably be
expected to break existing documented use counts as an alteration, since in C++
a new overload can change overload resolution and a new virtual can change a
vtable. The test is reasonable expectation, not bare possibility.

72 hours, measured against a release. Altering or removing something present
in the most recent tagged release needs a maintainer as author or approver and
waits 72 hours on the notice route, because downstream builds against what a
release promised. Something added since that tag is unreleased, nobody could
have depended on it, and ordinary rules apply.

Neutrality that an independent maintainer satisfies. At least two
maintainers must not share an employer. Phrasing it as "employed by different
organisations" would have excluded an independent maintainer and left the
project failing its own test against the roster printed directly above it.

Seats belong to individuals, not employers, and do not lapse on a job
change. An organisation that depends on dispenso may propose a candidate when
its perspective goes unrepresented — a right to be heard, not a right to a seat.

Administrative access is custodial. Organisation ownership, and the Meta
infrastructure accounts that hold admin while the project sits under
facebookincubator, carry no decision-making authority. Without this the
document would describe three seats while the repository shows eleven
collaborators, and leave the difference unexplained.

On the roster

Pierre Moulon and Michael Ranieri have both agreed to take seats. Pierre is a
maintainer, which is what makes the two-employer requirement true rather than
aspirational. Michael is a committer rather than a second Meta maintainer,
deliberately: it adds review and merge capacity without putting one employer in
the majority of maintainer seats while the transfer is still being evaluated. He
can be proposed as a maintainer later by the ordinary route.

Affiliations describe the post-transfer state, and the roster is explicitly not
part of the amendment procedure — keeping it current should not require
unanimous approval.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.9%. Comparing base (68b6dc3) to head (41be92a).

Additional details and impacted files

@@           Coverage Diff           @@
##            main     #92     +/-   ##
=======================================
- Coverage   93.0%   92.9%   -0.2%     
=======================================
  Files         64      64             
  Lines       4991    4991             
  Branches     684     683      -1     
=======================================
- Hits        4643    4637      -6     
- Misses       348     354      +6     

see 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[andre-nguyen]

where is this moving to? 🤔

[graphicsMan]

Hi @andre-nguyen . I'm going to be transitioning from Meta, but I will retain maintainer rights on the repo. The goal is to move to a neutral org once we have done the Meta-side due diligence for that, perhaps in a month or two. So short term, repo is going nowhere. Long term the existing repo should continue to redirect to a new location, still TBD.

[graphicsMan]

@SeaOtocinclus @EscapeZero — flagging this rather than requesting review
formally, since GitHub will only accept review requests from accounts with
repository access and neither of you is a collaborator yet. @bigfootjon, that is
worth sorting out independently of this PR.

This is the project's first GOVERNANCE.md, and it names you both. Worth
reading before it lands rather than after, because the seats carry real
obligations:

• A change that alters or removes something in the most recent tagged release
  needs a maintainer as author or approver, and waits 72 hours on the notice
  route. Pierre, as a maintainer, that is partly you.
• Appointments are by consensus of the active maintainers; removals are by
  majority of the other active maintainers.
• An unresolved objection blocks a merge by either route, and only the active
  maintainers can resolve one by consensus.

Two things I would especially like challenged:

• Michael is listed as a committer rather than a second Meta maintainer.
  That was deliberate — it adds review and merge capacity without putting one
  employer in the majority of maintainer seats while the transfer is still being
  evaluated — but it is a judgement call, and the "Joining and leaving" table
  gives an ordinary route to change it later.
• The self-merge-after-24-hours route. It exists because for long stretches
  one person writes most of the changes, and requiring a second signature on
  each turns a right to review into an obligation to review. If that reads as
  too permissive, now is the time to say so.

Timing, so it is not a surprise: I leave Meta on Friday 2026-09-04, and my
access to this repository comes through facebookincubator org membership
rather than a personal grant, so I most likely cannot merge this afterwards.
Neither can either of you until access is sorted. @bigfootjon would be the
fallback.

No rush on my account — it is about 900 words and better reviewed than rushed.