Here are some answers to questions that you might possibly encounter.
What account do I need to log in with in order to use the bug tracker?
The bug tracker uses a separate account system to Minecraft itself. You need to create a separate account that is only used for the bug tracker. You can do that here: Sign up for a bug tracker account.
Why do I need to specify my “Full name” when I sign up for an account?
You do not need to sign up with your real name. The “Full name” field would more accurately be described as “Display name”. You can put anything you want in there, as long as you don’t use inappropriate language or try to impersonate a moderator, helper, or someone else.
Now that I have reported my bug, what should I do?
First of all, thank you! You should definitely look out for incoming emails or regularly check the bug report for updates or potential further inquiries. If there are any questions by a helper or moderator in a comment, please answer them.
Also, it’s best to check whether the bug is still in the game regularly, and update the bug report accordingly. It is not necessary to check every single version that is released, though.
What happens to my bug report after it is submitted?
A helper or moderator will review the report to make sure it follows the bug tracker guidelines. Unfortunately, a majority of new bug reports are duplicates of issues that have already been reported before, while others do not contain enough information to understand or reproduce the issue.
If the report does not follow the guidelines, it will be marked as resolved. Otherwise, if the report is accepted, the helper or moderator may then attempt to reproduce the bug using the information provided and if they are able to do so, it will be marked as confirmed. Then, Mojang will look at the bug report and decide when and how they want to fix it.
How long will it take for my bug to be fixed?
This depends on how severe the issue is, how large the risk of fixing it is, and how much effort is involved in fixing it. In some cases, Mojang may decide that a bug will not be fixed at all. These bug reports will be resolved as “Won’t Fix”.
There is no general rule for how long it will take for your bug to get fixed. Some issues get fixed within a couple of days, others may take a very long time. There’s no way to tell in advance.
On some projects, bug reports are assigned to certain developers, which can be seen in the “Assignee” field. This means that that developer is working on the issue, but it does not necessarily imply that the bug will be fixed in the near future.
For Java Edition, you might also see that a “Mojang Priority” is assigned to the bug report, which indicates how important the bug is to Mojang (more details below).
Why was my bug report resolved, but the problem still happens?
There are multiple ways in which a bug report can be resolved. On each bug report, you can find its resolution at the top of the page below the status. You can find the meanings of the different resolutions below.
Only the resolution “Fixed” implies that the bug has been fixed by the developers. If your bug report has a different resolution, please read its comments for an explanation for how and why it has been resolved.
What do the different resolutions mean?
- Awaiting Response – Someone has asked an important question about the bug which is awaiting a response. When there is a reply, the bug report will be automatically reopened.
- Cannot Reproduce – Helpers, moderators or developers were not able to reproduce the issue.
- Duplicate – Another bug report about the same issue already exists. When a bug report has been resolved this way, it is linked with a “duplicates” link (in the “Issue Links” section below the description) to that bug report (which is also called the “parent” bug report).
- Fixed – The bug has been fixed. You can check the “Fix Version/s” field to learn more.
If the fix version is a future version, it means that the bug has been fixed, but the version it has been fixed in has not been released yet. Additionally, if the bug has been fixed in a development version, the fix will only be available to all users when that version is finally fully released.
- Incomplete – The bug report does not include enough information in order to understand what the issue is.
- Invalid – The bug report does not describe a bug in the vanilla game, or violates the bug report guidelines in some way (e.g. outdated game version or modded game).
- Won’t Fix – The reported issue is a bug, but won’t be fixed. This can be for technical reasons, or it’s not viable to fix it. Note that this does not imply that the issue will never be fixed.
- Works As Intended (WAI) – The bug report describes behavior which works the way the developers intend it to work.
- Done – Only rarely used in very specific circumstances where no other resolution applies.
Do you have some more tips on how to use the search function?
There are some nifty features in the search engine that most people don’t know about:
- Search terms are reduced to word stems, so for instance if you search for “breeding”, JIRA will also return bug reports which only contain “breed”. To avoid that, you can surround a word in double quotes.
- You can use wildcards such as “enderm?n” (which will catch both “enderman” and “endermen”) or “connect*” (which will match everything starting with “connect”, so “connection”, “connectivity”, etc).
- When using the “Quick Search” bar in the top right, you can use some shortcuts for searching.
- If the search query contains a project key (e.g. “mcpe”), it only returns bug reports for that project.
- You can also filter by resolutions (e.g. “fixed”) or reporter (e.g. “r:me” returns bug reports reported by you)
- More information in the JIRA documentation.
- The “Advanced” search looks complicated, but it is very handy if you figure it out. You can read more about how it works in the JIRA documentation.
I believe my bug report was resolved incorrectly! Where can I appeal?
You can leave a comment on the resolved bug report. For extra visibility, you can also ask other players and moderators. (See community links.)
I want to discuss this issue, can I comment on it?
If you have any suggestions or extra information to improve a bug report, please do comment on it. The bug tracker is for gathering and organizing information that is helpful to the developers in replicating and fixing bugs.
However, if you want to discuss an issue, for instance whether you think it should count as a valid bug, or whether it should be fixed or not, please take the discussion outside of the bug tracker. (See community links.)
What does voting for an issue do?
By voting for an issue, you show that you are affected by the issue described by the bug report. This way we can estimate roughly how many players in total are affected. Mojang uses this metric among others in order to decide on how urgent a bug is to fix. However, this is not the only relevant statistic.
What are “Labels” for and how should I use them?
Bug reports are labeled with certain keywords in order to group them together to make them easier to find. A label can be any word or phrase, as long as it doesn’t contain a space. There are no limits as for how many labels a bug report can have.
Every user can create a new label by simply adding it to their own bug report, however this is discouraged and you should only add already existing labels to your bug report. In most cases there is no need to add labels to your own report at all.
There are certain rules which labels should follow:
- If something has an ID in the game (like blocks, entities, and items), use that ID without the “minecraft:” prefix as the label (e.g. “glowstone_dust” or “zombie_villager”)
- Prefix the label with a slash (“/”) for commands only (e.g. “/gamerule”)
- Use the “ing” suffix for verbs (e.g. “breeding” or “fishing”)
- No plurals unless it’s the actual name of the element (e.g. “statistics”)
- For everything else, connect words with a dash (e.g. “stronghold-portal”)
What does “Confirmation Status” mean?
“Confirmation Status” is used in order to document if the bug has been reproduced by someone else. There are four different confirmation statuses:
- Unconfirmed – Nobody except the reporter has experienced the issue so far.
- Plausible – A helper or moderator has reviewed the bug report but has not yet reproduced the issue.
- Community Consensus – Someone other than the reporter has experienced the issue.
- Confirmed – A helper or moderator has successfully reproduced the issue. Usually this also requires that a list of steps to replicate the bug is included in the description, and that a screenshot or video showcasing the issue is attached.
My attachment’s file size is too large, what should I do?
You can always upload your attachment somewhere else and simply link to it in your comment or your bug report description.
For videos, often reducing the resolution of your video makes a large difference in terms of the video’s file size. Also, some file formats produce smaller file sizes than others, for instance .mp4 files are almost always smaller than .avi files. For most video formats, you can reduce the bitrate as well for extra savings (for reference, YouTube videos at 1080p usually use 10000).
What do the different link types mean?
- “duplicates” – This bug report is a duplicate of the linked bug report.
- “is duplicated by” – The linked bug report is a duplicate of this bug report.
- “relates to” – This and the linked bug report are related in some way, e.g. they are very similar to each other or are about the same mechanic or feature of the game.
- “clones” – This bug report is about the same bug as the linked bug report, which has been resolved as fixed before.
- “is cloned by” – The linked bug report is a newer report about the same bug.
- “blocks” – The bug in the linked bug report cannot be tested or fixed before this bug report is resolved.
- “is blocked by” – The linked bug report needs to be resolved before this bug report can be tested or resolved.
- “discovered while testing” – This bug was discovered while testing the linked bug report.
- “testing discovered” – While testing this bug, the bug in the linked bug report was discovered.
What does “Mojang Priority” mean?
“Mojang Priority” is set by Mojang on Java Edition bug reports in order to document how important it is to them to fix the bug. This also takes into account how much effort is involved in fixing the bug.
If a bug report has “Mojang Priority” set, it is considered a valid bug by Mojang.
What is the “CHK” field used for?
CHK used to be set whenever a moderator checked a bug report. Nowadays, it is set to the date and time when the confirmation status of the bug report was initially changed by a helper or moderator. It doesn’t mean anything significant.
I found more than one unresolved bug report that seems to describe the same issue. Which one is the main report?
First, if one of the bug reports already has duplicates linked to it (i.e. if there are bug reports listed in the “is duplicated by” issue links section), that is the one that has been designated as the main report for the issue. Otherwise, the oldest (first reported) bug report is usually preferred unless a later one has more useful detail or has already been “confirmed”. Remember to only comment if you have new information to add, but definitely vote for the bug report.
Finally, thank you for taking the time to search, as this helps the moderators to have more time to replicate and confirm bug reports instead of resolving them as duplicates.
What else can I do to help?
You can take a look at other people’s bug reports, test them, or try to help improve their bug report by leaving comments with extra information about the bug at hand. Often the most useful information is a list of steps to reproduce the bug, and a screenshot or clear video if there isn’t one already.
In case a bug report has not been updated by the reporter for a very long time, you may also request ownership so you can take over updating the report.
You can also get in touch with other players who frequent the bug tracker here, where you can communicate with others who want to help.
Who are the helpers and moderators, what do they do, and how did they become helpers/moderators?
Helpers and moderators are volunteers. They are not Mojang employees and are normal players of the game, just like you. However, they have helped with organizing bug reports on the bug tracker for a long time, and as such have been chosen by Mojang and the existing moderators.
Helpers have the ability to edit any bug report as if it was their own, in order to add additional information about the bug or to clarify bad wording or an unclear description. Additionally they are able to update the “Confirmation Status”.
Moderators additionally have the ability to resolve, link, move, and delete bug reports. They can also remove comments and see private bug reports.
What does “Mojira” mean?
“Mojira” is the nickname of the Mojang bug tracker. The software that the bug tracker uses is called “JIRA” and is made by Atlassian. “Mojira” is a portmanteau of “Mojang” and “JIRA”.
I have more questions, where can I ask them?
If you still have a question that’s left unanswered, you might want to try asking other players directly in the official Minecraft Discord. There are other sites that you might find useful, too, but please remember these are external links and are not owned or moderated by the Minecraft team: