Reporting Issues & Requesting Features
How to file a GitHub issue, which template to use, and when to email us instead
TIXFIN tracks bugs, feature requests, and support questions in a dedicated GitHub repository: tixfin/tixfin-issues. This page explains how to open a good issue, which template to pick, and the (few) situations where you should email us instead of opening an issue.
TL;DR: Public bug/feature/question ā open a GitHub issue with the matching template. Security vulnerability, account/billing/personal data, or an active-event emergency ā email us directly (see When to Email Instead).
Before You Open an Issue
- Search first. Use the search bar on tixfin-issues to check whether your bug or idea has already been reported. If it has, add a š reaction or a comment with new details instead of opening a duplicate.
- Check the FAQ and the relevant feature docs ā your question may already be answered.
- Check status.tixfin.com if something looks broken ā it may be a known incident already being worked on.
Choosing the Right Template
Click New Issue on tixfin-issues and pick the template that matches your report. Blank issues are disabled ā every report goes through one of these four templates so the team gets the fields it needs to triage quickly.
š Bug / Error Report
Something broke ā crashes, error messages, incorrect behavior
āØ Feature Request
Suggest a new feature or improvement
š ļø Staff / Internal Report
TixFin staff reporting internal or operational issues
ā Support / Question
General questions or help requests
š Bug / Error Report
Use this when the platform does something wrong: a crash, an error message, a page that won't load, a scan that fails, a payment that doesn't go through, incorrect numbers on a report, etc.
The template asks for:
| Field | Why it matters |
|---|---|
| What happened? | A clear one- or two-sentence description of the bug |
| Steps to reproduce | The exact clicks/actions needed to trigger it ā this is the single most useful field for us |
| Expected behavior | What you thought would happen instead |
| Error message / stack trace | Paste the exact text, not a paraphrase |
| Severity | Critical (blocks payments/ticket delivery/core functionality) ā Low (cosmetic) |
| Environment | Browser/OS, app version, or prod vs. staging |
The more precise your steps to reproduce, the faster we can fix it. "It doesn't work" without steps usually bounces back with a request for more detail, which slows everyone down.
āØ Feature Request
Use this to suggest something that doesn't exist yet or an improvement to something that does (e.g. "let me bulk-edit ticket prices", "add a WooCommerce plugin", "support Apple Pay in the shop").
Fill in:
- What problem does this solve? ā describe the pain point, not just the solution. This lets us evaluate whether there's a simpler fix.
- Proposed solution ā what you'd like to happen.
- Alternatives considered ā anything you tried as a workaround.
- Additional context ā links, mockups, examples from other tools.
š ļø Staff / Internal Report
Reserved for TixFin staff reporting internal, operational, or escalated issues (e.g. a payment provider outage, an internal admin-dashboard bug, an issue escalated from a customer support conversation). Includes fields for team/department, affected system, urgency, and a reference to the related ticket/order/event.
ā Support / Question
For general "how do Iā¦" questions that aren't bugs or feature requests. If you need a fast answer and can't wait for issue triage, use email or live chat instead ā GitHub issues are triaged on a best-effort basis, not guaranteed response times.
What Happens After You Open an Issue
All issues land in Backlog on the project board and move through:
Backlog ā Triage ā In Progress ā In Review ā Done- Triage ā the team confirms severity/validity and applies labels.
- In Progress ā someone is actively working on it.
- In Review ā a fix or feature is implemented and being verified.
- Done ā shipped. Bug fixes and features are announced in the Changelog.
You'll be notified via GitHub whenever someone comments, labels, or closes your issue. Please respond if we ask a follow-up question ā issues waiting on reporter feedback for a long time may be closed as stale.
Writing a Good Issue
One issue, one topic. Don't bundle three unrelated bugs into a single report ā open three issues so each can be triaged and closed independently.
Show, don't just tell. Attach a screenshot, screen recording, or copy-pasted error text. For visual bugs, a screenshot is worth more than a paragraph of description.
Include identifiers. Order/ticket number, event ID or slug, project name, username ā anything that lets us look up your exact record instead of guessing.
Say what you expected. "The total should be ā¬45, but it shows ā¬54" is more actionable than "the price is wrong."
When to Email Instead
Not everything belongs in a public GitHub issue. Email us directly (see the Support page for all addresses) instead of opening an issue when:
Security vulnerabilities
Never file a public issue for a security bug ā email security@tixfin.com so it isn't disclosed before it's fixed
Account, billing, or personal data
Anything containing payment details, personal data, or account-specific info belongs in a private email, not a public issue
- Security vulnerabilities ā email security@tixfin.com. Public GitHub issues are visible to everyone, so a reported vulnerability could be exploited before it's patched. See our responsible disclosure guidance for details.
- Account, billing, or payment problems ā these usually involve personal data (card details, invoices, payout account info) that shouldn't be posted publicly. Email support@tixfin.com with your account/order details.
- Active-event emergencies ā scanning down, checkout down, or another critical issue during a live event needs an immediate human, not a queued GitHub issue. Email emergency@tixfin.com with "URGENT" in the subject (see Emergency Support).
- Anything containing customer personal data ā never paste attendee names, emails, card numbers, or other PII into a public issue. Redact it, or email it privately instead.
For everything else ā bugs, features, general "how do I" questions that aren't urgent ā a GitHub issue is the right, trackable place to report it.