---
title: "Contact · tabnas"
description: "How to reach the tabnas project: GitHub Discussions for questions, repository issues for bugs, and email to the maintainer for anything private."
source: "https://tabnas.dev/contact/"
---

# Contact

_tabnas_ is maintained by [Richard Rodger](https://richardrodger.com). Most conversations belong in public on GitHub, where the answer helps the next person to ask; email is for the things that should not be public.

## Email

[richard@ricebridge.com](mailto:richard@ricebridge.com)

This is the address the project's [Code of Conduct](https://github.com/tabnas/web/blob/main/CODE_OF_CONDUCT.md) publishes, and it reaches the maintainer directly. Use it for security reports, conduct reports, sponsorship, licensing questions, and anything else you would rather not put in a public issue.

## Questions and ideas

[GitHub Discussions](https://github.com/tabnas/parser/discussions) on the engine repository. "How do I parse this", "is this the right tool for X", "here is a grammar I wrote" — all of it belongs there. Discussions are searchable, so an answer given once keeps working.

## Bugs and feature requests

File an issue on the repository that owns the behaviour: a wrong parse tree from the engine goes to [tabnas/parser](https://github.com/tabnas/parser/issues), a grammar that mis-reads a file goes to that grammar's repository, and anything about this website goes to [tabnas/web](https://github.com/tabnas/web/issues). Every repository is under [github.com/tabnas](https://github.com/tabnas).

A failing case is the most useful thing you can send: the input, the grammar, and what you expected. The fleet's fixtures are tab-separated rows of exactly that, so a good report often becomes a test unchanged.

## Security

Report a suspected vulnerability by email rather than in a public issue, and say what you did, what happened, and what you expected. The engine's threat surface is smaller than most parsers' — a grammar is data, and the MCP server refuses grammars that reach outside the built-in action set, so "validate this grammar" never becomes "run this code" — but parsers are input-handling code and input-handling code has bugs.

## Contributing

Read [CONTRIBUTING.md](https://github.com/tabnas/web/blob/main/CONTRIBUTING.md), then open a pull request. Patches written with an AI agent are welcome on the same terms as any other — [community](https://tabnas.dev/community/) explains the policy, and every repository ships an `AGENTS.md` so an agent can orient itself without guessing.

## What to expect

One maintainer, working on this alongside other things. A first contribution or a first question gets a prompt reply; a deep bug report may take longer, and an idea that does not fit the project's scope will get a straight no rather than silence. The [FAQ](https://tabnas.dev/faq/) says what is out of scope, so you can check before writing.

Development of tabnas is sponsored by Voxgig. Sponsorship enquiries are welcome at the address above; see [sponsors](https://tabnas.dev/sponsors/) for what it pays for.