Governance & voting

Once a listing ignites, the sponsors run it. Governance is funding-weighted: the more you’ve released toward a listing, the more your vote counts — like shares in how it’s built.

What needs a vote

• Governed merges — PRs that change the product in a meaningful way.
• Scope changes — edits to .roadmap/scope.toml.
• Settings changes — edits to .roadmap/governance.toml itself.
• Budget changes — adjusting caps in .roadmap/agents.toml.

Small, low-risk PRs (typo fixes, docs) can merge under normal review if the governance config allows.

How a vote works

1. A decision opens with a timeline (default 72 hours).
2. Sponsors vote — the canonical vote is a GitHub PR approval.
3. A voting bot weights each approval by the sponsor’s shares.
4. If approvals reach the threshold (default 60% of shares) before the timeline closes, the decision passes; otherwise it expires.

[governance]
vote_threshold_pct = 60
merge_timeline_hours = 72
who_votes = "sponsors"

[governance.weighting]
basis = "released_funds"   # shares = released USD

Branch protection requires the voting bot’s check on governed PRs, so a merge literally cannot land without the vote.

Self-amending settings

Governance settings change only through the process they define. To raise the threshold or shorten the timeline, you open a PR to .roadmap/governance.toml — and it goes through the same vote. The constitution amends itself.

Conditional pledges & priority

A conditional pledge ties money to a specific PR. When that PR merges, the pledge releases and its shares come online. This lets a sponsor put real weight behind the feature they want prioritized.

Who can vote

Set by who_votes: sponsors (default) or sponsors+creator. Only released shares vote — intent and unreleased conditional pledges don’t. Roles and repo permissions are detailed in the project’s ACCOUNTS_ROLES_PROFILES.md.