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)
- Priority — Critical / High / Medium / Low. Critical is for blocking issues; most things are Medium or Low.
- Tags — optional, comma-separated; the autocomplete suggests existing tags (see Tags)
If your issue stems from a specific post (a bug you observed mid-game, or a feature idea sparked by something you read), the Report Issue action on a post's menu pre-fills the issue with a link back to the source.
Statuses
Filed issues move through a workflow:
| Status | Meaning |
|---|---|
| New | Filed, not yet reviewed by staff. |
| Triaged | Staff have seen it and confirmed scope. |
| In Progress | Someone is actively working on it. |
| Resolution Proposed | A fix has shipped or a decision has been made; awaiting your sign-off as reporter. |
| Resolved | You (or staff) accepted the proposed resolution. |
| Closed | Resolved or otherwise complete; not actively tracked. |
| Reopened | Was resolved, but came back; back in the active queue. |
| Awaiting Input | Staff need more information from the reporter or another stakeholder. |
As the reporter, the status that wants your attention most is Resolution Proposed — that's your moment to verify the fix or decision and either Accept (status → Resolved) or push back (returning the issue to in-progress).
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 accept votes (severity is a staff call, not a popularity contest).
Comments
Issues have a comment thread. Anyone with read access to the issue can comment. Staff can also leave internal comments visible only to other staff — for triage notes and discussion that shouldn't fill the public thread.
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.