Issue Tracker

Myth-Weavers has a built-in issue tracker for bug reports, feature requests, support questions, and the long-running epics that span months of work. This guide covers filing an issue, voting on feature requests, tracking the work, and the resolution flow.

Filing an issue

Issues in the navigation opens the tracker. New Issue opens the form:

• Type — what kind of issue:
  • Bug — something is broken or behaving wrong
  • Feature — a new capability you'd like to see
  • Question — "how do I...?"; routed for answers, not implementation
  • Support — account-related, sensitive game content, or "I need help with X that I'd rather not discuss in public"
  • Epic — a large body of related work; usually created by staff
• Title — short and scannable; treat it like a commit message
• Description — what happened, what you expected, steps to reproduce (bugs); the use case + proposed shape (features)
• Tags — optional, comma-separated; the autocomplete suggests existing tags (see Tags)

If your issue grew out of a specific post, whether it's a bug you spotted mid-game or a feature idea sparked by something you read, the Report Issue action on that post's menu pre-fills the form with a link straight back to the source.

Priority (Critical / High / Medium / Low) isn't something you set — staff assign it during triage, from the issue's own page. It shows as a badge once set, and you can filter and sort the issue list by it.

Statuses

Once filed, an issue travels through a workflow:

As the reporter, the status to keep an eye out for is Resolution Proposed. That's your cue to check the fix or decision and either Accept it (which moves the status to Resolved) or push back, sending the issue back to in-progress for another look. If you don't respond either way, the issue is automatically resolved after 7 days with no further activity — you can always reopen it if the problem resurfaces.

Voting on features

Feature-type issues accept votes. The vote count is shown on the issue card; clicking the vote button toggles your vote. Higher-voted features get attention earlier — voting is the lightweight way to signal "yes, I want this too" without writing another duplicate issue.

Bug and support issues don't take votes, since severity is a staff judgment call.

Comments

Every issue has a comment thread, open to anyone with read access to the issue. Staff can also leave internal comments that only other staff can see, which keeps triage notes and back-channel discussion from cluttering the public conversation.

Browsing and search

The issue list (the Issues page) is sortable and filterable:

• By type (bug, feature, question, support, epic)
• By status (any of the workflow states above)
• By priority
• Free-text search across titles and descriptions

Each row shows status, type, priority, title, vote count (for features), and last-activity timestamp.

Tips for filing

• Search before filing. Duplicates split the conversation and dilute votes. The tracker's search covers titles and descriptions — 30 seconds well spent.
• One issue per concern. If you find two unrelated bugs in the same session, file two issues; they triage separately.
• Be specific in bug reports. "It's broken" is hard to act on; "When I click X on Y page, I expected Z but saw W" is much easier. Include the URL and your browser if relevant.
• Feature requests benefit from use cases. "Add a dark mode" is harder to scope than "I read late at night and the bright theme strains my eyes; could there be a dark variant?" — the second framing makes the design problem concrete.

Next steps

• Community, Messages, and Social — community forums are the right venue for discussion that isn't quite an issue.
• Account Settings — notification preferences for issue updates land in the general notifications panel.