Community

Termin is an open-source project and welcomes contribution. This page describes how the project is governed, how to participate, and who to contact.

# Maintainers

Primary maintainer: Jamie-Leigh Blake — author of the compiler, the reference runtime, the conformance suite, and the IR (intermediate representation) specification.

The project is open to co-maintainers. The process for adding a co-maintainer is described in the governance model below: sustained contribution, demonstrated judgment on the project's scope and guarantees, and agreement from the existing maintainer set.

# Governance

# Decisions

Technical decisions are made in public on GitHub — in issues, pull requests, and the design-discussion process under docs/design-decisions/ in the compiler repository. The maintainer set is the final decision-maker on scope, guarantees, and release contents. Where multiple maintainers exist, disagreement is resolved by discussion; if discussion does not converge, the primary maintainer decides. The goal is to keep decision-making transparent and reversible, not to construct a heavyweight process.

The guarantees document is the authoritative specification of what the project promises. Any change that affects Tier 1 guarantees requires an explicit public design proposal and a corresponding change to the conformance suite.

# Conflict resolution

Disagreements that cannot be resolved through normal discussion are escalated to the maintainer set for a decision. For issues involving conduct rather than technical scope, the code of conduct's enforcement process applies.

# Succession

If the primary maintainer steps back, the project is Apache 2.0 — a motivated community can fork and continue at any time. The IR schema, the package format, and the conformance suite are the contract; the reference implementation is one conforming implementation among possible others.

A formal succession plan (named successor, transition procedure) will be published when a co-maintainer is in place. Until then, the fork-safety of the project stands in for one. See /license for the licensing guarantees that make this credible.

# Contributing

The short version:

1. Read CONTRIBUTING.md in the compiler repository for the current contribution flow.
2. File an issue before a large change. Small fixes can go straight to a pull request. Large changes benefit from alignment first.
3. Sign off on your commits. Contributions are accepted under the Developer Certificate of Origin. Each commit must carry a Signed-off-by: trailer (git commit -s). There is no contributor license agreement.
4. Write the test alongside the change. For compiler or runtime changes, this usually means an update to the conformance suite. For bug fixes, a failing test that the fix makes pass.
5. Open a pull request. CI runs the full test suite and the conformance suite. Review is in public on the pull request itself.

# Who is welcome to contribute

The project explicitly welcomes:

• Individual contributors writing under their own name.
• Organizational contributors whose legal setup permits contribution under the DCO (Developer Certificate of Origin — a lightweight contribution attestation; see /license for details).
• AI-agent contributors acting on behalf of either, where the human or organization on whose behalf the agent is acting takes responsibility for the contribution under the DCO. An AI-authored pull request is held to the same standards as any other — quality, test coverage, agreement with the project's scope.

The guarantees of the project depend on the quality of the contributions that touch the guarantee-bearing code paths. That is the standard, regardless of who or what wrote the patch.

# What makes a good contribution

• Scope-aligned. Changes that expand what Termin structurally guarantees are welcome. Changes that make Termin into a general-purpose programming language are not — the narrow expressive surface is the point.
• Evidence-linked. A claim in documentation is matched by a conformance test. A change to the runtime is matched by a test in the runtime suite. A change to the DSL is matched by an update to the grammar and an IR round-trip test.
• Readable. The project optimises for clarity over cleverness. A simple patch that is obviously correct is preferred over a clever one that requires archaeology to review.

# Where to go

• Bugs and feature requests — compiler issue tracker.
• Conformance-suite or IR-spec issues — conformance issue tracker.
• Security issues — see /security. Do not file security reports in the public issue tracker.
• Design discussion — GitHub Discussions on the compiler repository, and the design-decision documents under docs/design-decisions/.
• Questions about using Termin — GitHub Discussions. If a question is asked often enough that an answer would help others, it becomes documentation.

# Code of conduct

The project adopts the Contributor Covenant as its code of conduct. The current version is reproduced in CODE_OF_CONDUCT.md in the compiler repository.

Reports of conduct concerns should be sent to conduct@termin.dev. Reports are handled privately; the reporter's identity is not shared without their consent.

# Contributors

A full contributor list is maintained in the compiler repository's CONTRIBUTORS.md and is regenerated on each release. Credit is also given in the changelog for the release a contribution landed in.

# What the project is not asking for

• Money. The project has no donation mechanism. GitHub Sponsors is not enabled. There is no Patreon, no Open Collective, no "buy me a coffee" link. See /license for the reasoning.
• Your email address. The site does not have a newsletter or email capture. Follow the changelog RSS feed or watch the GitHub repository for release notifications.
• Marketing help. The project's credibility comes from the precision of its claims and the reproducibility of its conformance tests, not from external promotion. The best thing a supporter can do is run the conformance suite, file issues on what is wrong, and publish honest evaluations.