MYTHIC EARTH ISSUE COUNCIL RULES
Version: 0.1-test
Status: Draft for testing
Last updated: 3 August 2026
1. PURPOSE OF THE ISSUE COUNCIL
The Mythic Earth Issue Council provides a structured place for players, testers, community members and staff to report, investigate, discuss and track problems affecting Mythic Earth.
The Issue Council is intended to:
• collect useful game and website bug reports;
• help users identify existing reports before creating duplicates;
• allow affected users to confirm that they experienced the same problem;
• connect reports to the correct release branch and exact patch or build;
• allow staff to request additional information;
• preserve investigation and resolution history;
• communicate report status and known outcomes; and
• improve the quality, stability and accessibility of Mythic Earth.
The Issue Council is not a general discussion forum, customer-review platform, voting system for binding development decisions or unrestricted file-sharing service.
These Rules should be read together with:
• the Mythic Earth Terms of Service;
• the Mythic Earth Privacy Policy;
• the Mythic Earth Community Guidelines;
• testing, confidentiality or nondisclosure terms where applicable; and
• any additional instructions displayed for a particular build, report category or testing program.
2. WHERE THESE RULES APPLY
These Rules apply to all Issue Council participation, including:
• creating a report;
• editing a saved draft;
• publishing a report;
• adding reproduction steps;
• submitting screenshots or evidence;
• replying to a report;
• responding to a staff information request;
• confirming or removing confirmation from a report;
• participating in a report discussion;
• accessing restricted Issue Council areas;
• using report search, filtering and discovery tools; and
• interacting with Issue Council notifications.
The Community Guidelines also apply to Issue Council conduct.
3. ACCEPTANCE AND PARTICIPATION
Public Issue Council reports may generally be read without accepting these Rules.
A registered user must accept the current applicable versions of:
• the Community Guidelines; and
• the Issue Council Rules
before they can:
• open the report-submission workflow;
• publish a new report;
• publish a saved draft;
• reply to an active report;
• provide requested information;
• upload report evidence; or
• add a new confirmation to a report.
The website records the version accepted by the user and the date and time of acceptance.
When a materially revised version is published and marked as requiring reacceptance, affected users may continue reading public reports but may be prevented from further Issue Council participation until they accept the new version.
A user may be permitted to remove an existing confirmation without accepting a newer version so that they are not trapped into continuing an endorsement.
4. REPORTS MUST BE MADE IN GOOD FAITH
Reports must be submitted honestly and for the purpose of identifying or investigating a genuine problem.
Users must not knowingly submit:
• fabricated bugs;
• deliberately misleading reports;
• reports intended to harass another user or staff member;
• false security claims;
• fraudulent evidence;
• reports designed to manipulate development statistics;
• reports created only to advertise a product or service;
• repeated reports intended to disrupt staff workloads; or
• reports created to evade another moderation or support process.
A mistaken report is not automatically a rule violation.
Users are expected to correct inaccurate information when they become aware of it.
5. SEARCH BEFORE REPORTING
Before creating a new report, users should make a reasonable attempt to search for an existing report describing the same problem.
Where a matching report already exists, users should generally:
• read the existing report;
• confirm it if they experienced the same problem;
• add materially useful new information where permitted; and
• avoid creating another report unless the existing report concerns a meaningfully different issue.
A new report may still be appropriate where:
• the symptoms are materially different;
• a different system or platform is affected;
• the existing report concerns another build;
• the cause appears different;
• the existing report is restricted and unavailable to the user;
• staff have requested a separate report; or
• the existing report cannot reasonably contain the new issue.
6. ONE PRIMARY ISSUE PER REPORT
A report should normally focus on one primary problem.
Users should not combine unrelated matters such as:
• an inventory bug;
• a login problem;
• a graphical issue; and
• a balance suggestion
into one report.
Related symptoms may be included together where they appear to arise from the same underlying issue.
Staff may request that unrelated issues be separated into different reports.
7. REPORT TITLES
A report title should clearly identify the problem.
Useful titles describe:
• what happened;
• where it happened;
• which system was affected; and
• any important condition that triggers it.
Examples of useful titles include:
• Horse becomes stuck after dismounting near Castle Cornet
• Inventory item disappears after moving it into Shared Stash
• Password-reset email link returns an expired-token message immediately
• Hell Layer 1 patrol event does not award the Soul Stone
Avoid vague titles such as:
• Game broken
• Help
• Bug
• This does not work
• Fix this
• Everything crashed
Staff may edit a report title to improve clarity, searchability, privacy or consistency without changing the substance of the report.
8. REPORT DESCRIPTION
The description should explain the problem in enough detail for another person to understand what occurred.
Where possible, include:
• what you were trying to do;
• what you expected to happen;
• what actually happened;
• where the issue occurred;
• whether it happened once or repeatedly;
• when it was first noticed;
• whether restarting or reconnecting changed the result;
• whether other users were affected; and
• any relevant error message.
Avoid filling the description with unrelated complaints, speculation presented as fact or personal attacks.
9. REPRODUCTION STEPS
Reproduction steps explain how another person may trigger the same problem.
Good reproduction steps should be:
• numbered;
• ordered;
• concise;
• specific; and
• based on what was actually done.
Example:
1. Sign into the website.
2. Open Account Security.
3. Select End All Other Sessions.
4. Confirm the action with the current password.
5. Refresh the page.
6. Observe that the ended session still appears active.
Where the issue cannot be reproduced reliably, say so and describe:
• how often it occurs;
• whether it appears random;
• any suspected conditions;
• what was happening immediately beforehand; and
• what troubleshooting has already been attempted.
Do not invent reproduction steps merely to complete the field.
10. EXPECTED AND ACTUAL RESULTS
Where the report form provides separate fields, users should distinguish between:
Expected result:
What should normally have happened.
Actual result:
What happened instead.
Example:
Expected result:
The selected item should move into Shared Stash and remain available to the other character slot.
Actual result:
The item disappears from the current inventory but does not appear in Shared Stash.
Clear expected and actual results help staff determine whether the report concerns a defect, misunderstanding, design decision or feature request.
11. AFFECTED RELEASE, PATCH OR BUILD
Users should select the most accurate affected release, patch or build available.
The Issue Council distinguishes between:
• a release branch, which represents a broader roadmap or development release; and
• an exact patch or build, which represents the specific version where the issue occurred.
Where the exact build is known, select it.
Where it is not known, select:
Unknown / Not sure
Users must not guess a build merely to complete the field.
Staff may correct the affected build where investigation identifies a more accurate version.
Restricted or internal builds may only be visible to users who have the required role, group, cohort or entitlement.
12. ENVIRONMENT AND SYSTEM INFORMATION
Where relevant, include information such as:
• game mode;
• map, location or level;
• single-player, listen-server or dedicated-server context;
• operating system;
• browser;
• hardware;
• controller or input device;
• network type;
• graphics settings;
• account state;
• character or inventory state; and
• any relevant mods, plugins or test configurations.
Do not publish private credentials, licence keys, authentication tokens or identifying device information that is not reasonably required.
13. SCREENSHOTS AND EVIDENCE
Screenshots and other evidence should directly support the report.
Evidence may show:
• an error message;
• visual corruption;
• incorrect user-interface state;
• missing content;
• a comparison between expected and actual behaviour;
• reproduction context; or
• information requested by staff.
Users must not upload:
• passwords;
• authentication codes;
• recovery links;
• private email addresses;
• private conversations without justification;
• another person’s personal information;
• copyrighted content they have no right to submit;
• malicious files;
• unrelated images;
• explicit or exploitative material; or
• confidential testing material to a public report.
Before uploading a screenshot, check browser tabs, account details, desktop notifications and other visible information that may reveal private data.
Staff may remove, restrict or redact evidence to protect privacy, security, confidentiality or legal interests.
14. SECURITY VULNERABILITIES
Potential security vulnerabilities should generally be reported privately through Contact Support or another designated security-reporting route.
Do not publicly post:
• working account-bypass methods;
• authentication exploits;
• database-access details;
• private server paths;
• session tokens;
• password-reset tokens;
• instructions that materially enable account compromise;
• unpatched remote-code execution details; or
• evidence containing another user’s private data.
A public Issue Council report may be made private, restricted or removed where it presents a security risk.
Good-faith security reporting does not permit unauthorised access, destructive testing, privacy invasion or disruption of services.
15. PUBLIC AND PRIVATE REPORTS
Issue Council reports may be public or private.
A public report may be visible to:
• website visitors;
• registered users;
• search engines where indexing is allowed;
• other reporters;
• testers;
• staff; and
• other authorised participants.
A private report may be visible only to:
• the reporter;
• specifically authorised staff;
• assigned reviewers;
• authorised testing groups; or
• other users with explicit access.
Normal submitted reports may default to public where they concern publicly available builds and contain no restricted material.
Reports may remain or become private where they involve:
• restricted builds;
• internal or staff-only testing;
• NDA information;
• security vulnerabilities;
• personal information;
• account-specific evidence;
• confidential support information;
• legal concerns; or
• another reason requiring restricted access.
Public visibility does not mean every part of a report is public. Staff notes, private evidence and restricted workflow information remain protected.
16. RESTRICTED TESTING REPORTS
Reports connected to private testing may be restricted according to:
• testing role;
• cohort;
• build entitlement;
• NDA status;
• release channel;
• staff permission; or
• assignment.
Users must not disclose restricted report content outside the authorised testing area.
This includes:
• private screenshots;
• unreleased build information;
• confidential Patch Notes;
• internal server details;
• private developer comments;
• restricted attachments; and
• the existence of embargoed features where confidentiality applies.
Loss of testing access does not remove continuing confidentiality obligations.
17. REPORT DISCUSSION
Report discussion should remain relevant to investigating or understanding the issue.
Useful replies may include:
• confirmation of the same symptoms;
• different reproduction steps;
• affected hardware or software;
• additional evidence;
• clarification requested by staff;
• confirmation that a workaround helped;
• information about another affected build; or
• a report that the issue no longer occurs.
Users should not use discussions for:
• unrelated arguments;
• general game criticism unrelated to the report;
• personal attacks;
• repeated demands for updates;
• advertising;
• campaigning;
• speculation presented as confirmed fact;
• attempts to pressure staff through threats; or
• disputes about moderation that belong in support or appeals.
Staff may lock a discussion where continued replies are no longer useful or where moderation is required.
18. STAFF RESPONSES AND INFORMATION REQUESTS
Staff may add a public response to:
• acknowledge the report;
• request more information;
• clarify reproduction steps;
• identify a possible duplicate;
• explain a status change;
• provide a workaround;
• identify a target or fixed build;
• explain a closure; or
• communicate an investigation outcome.
Where staff change a report to Needs Information, the reporter should review the public response and provide the requested information where reasonably possible.
A reporter who cannot provide the requested information should say so rather than inventing details.
Failure to respond may result in the report being:
• left awaiting information;
• marked unable to reproduce;
• declined;
• closed; or
• revisited if new evidence later becomes available.
19. ASSIGNMENT AND OWNERSHIP
A report may be assigned to a QA member, staff member, developer, moderator, tester or another authorised reviewer.
Assignment means that the person has taken responsibility for reviewing or progressing that report.
Assignment does not mean:
• the assignee represents the reporter;
• the assignee manages all reports from that user;
• the assignee guarantees a fix;
• the assignee has sole authority over the issue; or
• other staff may not participate.
A report may be:
• unassigned;
• assigned to one reviewer;
• reassigned;
• returned to the general queue; or
• escalated to another team.
The current assignee may receive notifications when another person replies to an active assigned report.
Users must not harass or repeatedly contact an assignee outside the report or authorised support channels.
20. CONFIRMATIONS
A confirmation indicates that another user believes they experienced the same issue described in the report.
Before confirming, users should:
• read the report;
• compare the symptoms;
• check the affected build;
• consider whether their problem is actually the same; and
• avoid confirming only because they agree with a requested change.
A confirmation is not:
• a popularity vote;
• a demand for implementation;
• proof that every user has the same cause;
• a replacement for useful evidence; or
• a guarantee of priority.
Users must not manipulate confirmations by:
• using multiple accounts;
• coordinating false confirmations;
• confirming reports they did not experience;
• trading confirmations;
• using bots or automation; or
• pressuring others to confirm inaccurately.
A user may remove their confirmation if they later believe the issue was different or no longer wish to endorse it.
21. FEATURE REQUESTS AND DESIGN FEEDBACK
The Issue Council primarily exists for problems and defects.
Where the system permits feature requests or design feedback, users should clearly identify that the report concerns:
• a proposed feature;
• quality-of-life feedback;
• balance feedback;
• accessibility feedback;
• design preference; or
• another non-defect request.
A feature not existing is not automatically a bug.
Disagreement with a design decision is not automatically a defect.
Staff may move, relabel, decline or close feedback that does not fit the Issue Council’s current scope.
Confirmations or popularity do not create a binding obligation to implement a feature.
22. DUPLICATE REPORTS
A report may be marked as a duplicate when another report already represents the same underlying issue.
The duplicate report may remain accessible for history and search purposes while directing users to the canonical report.
A duplicate decision may consider:
• symptoms;
• reproduction steps;
• affected system;
• suspected cause;
• affected build;
• error messages;
• staff investigation; and
• whether separate tracking would provide useful information.
Two reports do not need identical wording to describe the same underlying issue.
Conversely, reports with similar symptoms may remain separate if they appear to have different causes.
Being marked duplicate is not punishment and does not mean the report was useless.
Duplicate reports may help staff understand how users describe or discover the problem.
Where available, users should move useful new evidence to the canonical report.
23. REPORT STATUSES
A report may move through statuses such as:
Draft
The report has been saved but not submitted for normal review.
Submitted
The report has been published or formally submitted and is awaiting triage.
Under Review
An authorised reviewer is investigating or evaluating the report.
Needs Information
Staff require more details before the investigation can continue.
Planned or Targeted
The issue has been associated with a future release or build target. This does not guarantee a release date.
Fixed
Staff believe the issue has been corrected in an identified build or change.
Unable to Reproduce
Staff could not reproduce the reported behaviour with the information and environment available.
Duplicate
The issue is tracked through another canonical report.
Declined
The report will not proceed in its current form or does not fall within the accepted scope.
Closed
The report is no longer active.
Reopened
A previously closed report has returned to active investigation because of new evidence, recurrence or another valid reason.
Actual status labels may evolve as the Issue Council develops.
24. PRIORITY
Report priority is an internal operational assessment.
Priority may consider:
• severity;
• number of users affected;
• data loss;
• security impact;
• progression blocking;
• frequency;
• availability of workarounds;
• affected build;
• testing stage;
• reproducibility;
• development dependencies; and
• operational capacity.
A highly confirmed report is not automatically high priority.
A report affecting only one user may still be critical where it concerns account compromise, data loss or another serious risk.
Users may explain impact, but they must not exaggerate or threaten staff to obtain a higher priority.
25. TARGET AND FIXED BUILDS
Staff may associate a report with:
• an affected build;
• a target build; or
• a fixed build.
A target build indicates current planning or expectation. It is not a legally binding promise that the issue will be fixed in that version.
A fixed build indicates that staff believe a correction is included in that build.
Users may be asked to retest the issue.
A report may be reopened if:
• the fix did not work;
• the issue returned;
• the problem affects another supported build;
• the original cause was misunderstood; or
• new evidence materially changes the investigation.
26. RESOLUTION SUMMARIES
A resolution summary records the outcome or current resolution of a report.
It may explain:
• what caused the issue;
• how it was corrected;
• which build contains the fix;
• why the report was declined;
• why the issue could not be reproduced;
• why the report was marked duplicate; or
• what workaround is available.
A resolution summary is not the same as a discussion reply.
Updating a resolution summary may not create a conversational notification unless staff also add a public response or perform another notification-triggering action.
27. REPORT CLOSURE
A report may be closed when:
• the issue is fixed;
• it is a duplicate;
• the reporter does not provide necessary information;
• it cannot be reproduced;
• it is outside scope;
• the described behaviour is intended;
• the relevant system has been replaced;
• the affected build is no longer supported;
• the report violates applicable rules; or
• continued discussion is no longer useful.
Closure is not necessarily permanent.
A report may be reopened when new, credible and materially relevant information becomes available.
Users should not create repeated replacement reports solely to evade a valid closure decision.
28. UNABLE TO REPRODUCE
Unable to Reproduce means staff could not reliably trigger the reported behaviour using the information, environment and build available.
It does not necessarily mean:
• the user was dishonest;
• the issue never happened;
• the problem is impossible;
• the report was worthless; or
• the issue cannot later be reopened.
Useful new information may include:
• clearer steps;
• logs;
• screenshots;
• hardware or browser details;
• account-state details;
• frequency information;
• another affected user;
• exact build information; or
• a reliable reproduction case.
29. DECLINED REPORTS
A report may be declined where:
• it is not a defect;
• it is outside the Issue Council’s scope;
• it requests prohibited activity;
• it contains insufficient information and cannot reasonably proceed;
• it concerns an unsupported system;
• it is abusive, fraudulent or deliberately misleading;
• it requests disclosure of restricted information;
• it concerns a design decision that is not being reconsidered through the Issue Council; or
• another process is more appropriate.
Where practical, staff may explain the reason or direct the user to a more appropriate channel.
30. REPORT EDITING
Users may be able to edit drafts before submission.
After submission, editing may be limited to preserve the historical record.
Staff may edit report content where reasonably necessary to:
• improve formatting;
• correct categorisation;
• change the title;
• remove private information;
• remove security-sensitive material;
• redact confidential evidence;
• correct build associations;
• maintain consistency; or
• comply with legal or moderation obligations.
Material operational changes should be recorded in report history or audit records where supported.
Staff should not alter a report in a way that falsely changes the reporter’s meaning.
31. REPORT HISTORY
The Issue Council may record events such as:
• report submission;
• publication;
• visibility changes;
• assignment changes;
• status changes;
• priority changes;
• comments;
• information requests;
• build updates;
• duplicate decisions;
• resolution updates;
• discussion locking;
• reopening; and
• closure.
History improves accountability and helps users understand how a report changed over time.
Some internal events or notes may remain visible only to authorised staff.
32. INTERNAL STAFF NOTES
Internal staff notes are not public report comments.
They may contain:
• investigation details;
• internal coordination;
• security information;
• legal concerns;
• moderation context;
• confidential testing information;
• staff assessments; or
• information about another user.
Users are not entitled to view internal notes merely because those notes concern their report.
Internal notes must still be used responsibly and remain subject to staff permissions, audit requirements and applicable law.
33. PERSONAL INFORMATION
Users must not include unnecessary personal information in reports or comments.
Do not post:
• passwords;
• recovery codes;
• private email addresses;
• full names where not required;
• home addresses;
• telephone numbers;
• payment details;
• government identifiers;
• exact live locations;
• another user’s private information; or
• confidential support correspondence.
Where account-specific information is required, use Contact Support or another private process.
Staff may redact, remove or restrict content containing personal information.
34. COPYRIGHT AND THIRD-PARTY CONTENT
Users must only upload material they have the right to submit.
Do not upload:
• copyrighted game files from another product;
• leaked assets;
• confidential third-party material;
• private documents;
• commercially distributed content;
• another creator’s work without permission; or
• evidence that unlawfully exposes another person.
Screenshots showing ordinary use of Mythic Earth may generally be submitted for bug-reporting purposes.
Copyright complaints should be directed through the Copyright category in Contact Support.
35. DISCUSSION CONDUCT
Users may criticise:
• a bug;
• a feature;
• an implementation;
• a status decision;
• development priorities;
• a response;
• testing quality; or
• Mythic Earth itself.
Users must not:
• harass reporters;
• insult staff;
• make threats;
• use discriminatory abuse;
• derail the discussion;
• repeatedly demand updates;
• publish private information;
• organise attacks;
• encourage false confirmations;
• impersonate staff;
• use multiple accounts to manipulate discussion; or
• continue prohibited contact after being told to stop.
Disagreement is allowed.
Abuse is not.
36. REPORTER RESPONSIBILITIES
The reporter should:
• monitor relevant notifications;
• respond to reasonable staff questions;
• correct significant mistakes;
• provide requested information where possible;
• avoid repeatedly reposting the same issue;
• disclose important new findings;
• respect confidentiality restrictions;
• avoid manipulating confirmations; and
• use support or appeals for account-enforcement disputes.
The reporter does not own or control the operational handling of the report after submission.
37. STAFF RESPONSIBILITIES
Staff and authorised reviewers should:
• use Issue Council permissions only for authorised duties;
• distinguish public replies from internal notes;
• protect private and restricted information;
• record important operational changes;
• request only information reasonably relevant to the issue;
• avoid misleading status claims;
• avoid retaliatory or abusive conduct;
• use assignment and priority controls responsibly;
• explain significant outcomes where practical;
• preserve audit and report history; and
• escalate security, privacy, legal or safety issues appropriately.
Assignment to a report does not give a staff member ownership of the reporting user.
38. MODERATION AND RESTRICTIONS
Issue Council participation may be restricted where a user:
• repeatedly submits spam;
• knowingly creates false reports;
• abuses reporters or staff;
• manipulates confirmations;
• publishes private or restricted information;
• repeatedly ignores report rules;
• evades report closures;
• distributes malicious content;
• uses the Issue Council for harassment; or
• otherwise violates the Community Guidelines or Terms of Service.
Actions may include:
• content editing;
• evidence removal;
• warning;
• comment restriction;
• Issue Council restriction;
• report locking;
• report closure;
• temporary suspension;
• account ban; or
• another proportionate action.
An Issue Council restriction may prevent new reports, replies or confirmations while leaving other account features available.
39. DISPUTING A REPORT DECISION
Users may respectfully ask for clarification or provide new evidence where a report is:
• marked duplicate;
• declined;
• closed;
• marked unable to reproduce; or
• assigned another status they believe is incorrect.
A disagreement should focus on relevant facts.
Users must not:
• threaten staff;
• create repeated duplicate reports;
• encourage harassment;
• use multiple accounts;
• knowingly misrepresent evidence; or
• abuse support channels.
Where a decision concerns account enforcement rather than report handling, the appropriate support or appeal process should be used.
Not every report-status decision has a formal appeal process.
40. NOTIFICATIONS
Users may receive Notification Centre alerts for events such as:
• staff replies;
• information requests;
• status changes;
• duplicate decisions;
• fixed-build updates;
• closures;
• reopening; and
• other important report activity.
Assigned staff may receive Staff Portal notifications when:
• a report is assigned to them;
• another person replies to an active assigned report;
• requested information is supplied; or
• another important workload event occurs.
Notifications supplement the report history.
Users remain responsible for checking their reports and account where reasonably necessary.
41. EMAIL COPIES
Users may be able to enable or disable optional Issue Council email copies.
Required security, legal or account-service messages are not controlled by an optional Issue Council email preference.
A failure to receive an optional email does not remove the corresponding in-site notification or report history.
Users should maintain access to their registered email address.
42. NO GUARANTEE OF RESPONSE OR FIX
Submitting a report does not guarantee:
• an individual staff reply;
• immediate investigation;
• assignment;
• a particular priority;
• inclusion in a roadmap;
• a target build;
• a fix;
• a release date;
• compensation; or
• continued support for the affected build.
Mythic Earth may prioritise work according to development, security, operational and resource considerations.
The Issue Council exists to improve visibility and investigation, not to create contractual development obligations.
43. NO BOUNTY OR OWNERSHIP CLAIM
Submitting a report does not automatically entitle the reporter to:
• payment;
• reward;
• employment;
• credit;
• ownership of a fix;
• ownership of a game feature;
• royalties; or
• control over development decisions.
Mythic Earth may separately offer bug bounties, rewards or recognition under published terms.
Unless those separate terms apply, no reward is promised.
44. RETENTION
Issue Council reports and related records may be retained to:
• preserve development history;
• track recurring problems;
• maintain duplicate relationships;
• support moderation;
• investigate abuse;
• preserve testing records;
• protect security;
• comply with law;
• support account-data exports; and
• maintain audit integrity.
Account deletion does not necessarily remove Issue Council history where retention is reasonably necessary.
Direct public identity may be anonymised or replaced as described in the Privacy Policy.
45. CHANGES TO THESE RULES
These Issue Council Rules are version controlled.
A new version may include:
• a new version number;
• publication and effective dates;
• a summary of changes;
• an indication of whether reacceptance is required; and
• an archived copy of the previous version.
Material changes may require users to accept the new version before further Issue Council participation.
Previous versions may remain available through the legal-document archive.
46. CONTACT
Questions about these Rules may be submitted through Contact Support.
Security vulnerabilities, private account information and confidential testing concerns should be reported privately rather than posted publicly.
Mythic Earth
Legal operator:
[INSERT LEGAL BUSINESS OR ENTITY NAME]
Support email:
support@mythicearthgame.com
Website:
mythicearthgame.com
Contact Support:
Available through the Support section of the Mythic Earth website.